Openvpn problem
Mario Lobo
lobo at bsd.com.br
Thu Jul 24 12:36:04 UTC 2014
Hi there.
I have the following scenario:
LANa <--> FBSD-GW/FW <--> INTERNET <--> OPENVPN SRV <--> LANb
Using an openvpn client on either any LAN WS or on FBSD-GW works fine.
My idea is to start the openvpn client on FBSD-GW and use the created
tun0 as a gateway for LANa to LANb.
Log from FBSD-GW's openvpn:
Thu Jul 24 08:37:47 2014 TUN/TAP device /dev/tun0 opened
Thu Jul 24 08:37:47 2014 do_ifconfig, tt->ipv6=0,
tt->did_ifconfig_ipv6_setup=0
Thu Jul 24 08:37:47 2014 /sbin/ifconfig tun0 172.10.5.229 172.10.5.230 mtu
1500 netmask 255.255.255.255 up
Thu Jul 24 08:37:49 2014 /sbin/route add -net 10.10.0.0 172.10.5.230
255.255.252.0
add net 10.10.0.0: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.2.44 172.10.5.230
255.255.255.255
add net 172.10.2.44: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.5.1 172.10.5.230
255.255.255.255
add net 172.10.5.1: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.3.0 172.10.5.230
255.255.255.240
add net 172.10.3.0: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.2.0 172.10.5.230
255.255.255.192
add net 172.10.2.0: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.1.0 172.10.5.230
255.255.255.240
add net 172.10.1.0: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 Initialization Sequence Completed
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 172.10.5.229 --> 172.10.5.230 netmask 0xffffffff
Opened by PID 51795
Routing tables (what is relevant)
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 187.23.102.129 UGS 0 23469757 sk0
10.10.0.0/22 172.10.5.230 UGS 0 0 tun0
10.10.1.0/24 link#6 U 0 5158857 re1
10.10.1.254 link#6 UHS 0 0 lo0
172.10.1.0/28 172.10.5.230 UGS 0 11 tun0
172.10.2.0/26 172.10.5.230 UGS 0 29 tun0
172.10.2.44/32 172.10.5.230 UGS 0 0 tun0
172.10.3.0/28 172.10.5.230 UGS 0 0 tun0
172.10.5.1/32 172.10.5.230 UGS 0 0 tun0
172.10.5.229 link#11 UHS 0 0 lo0
172.10.5.230 link#11 UH 0 0 tun0
172.16.3.0/24 link#2 U 0 42161366 re0
172.16.3.1 link#2 UHS 0 0 lo0
fib 1
192.168.0.0/24 link#5 U 0 1 sk1
192.168.0.20 link#5 UHS 0 0 lo0
fib 0
187.23.102.128/29 link#4 U 0 0 sk0
187.23.102.130 link#4 UHS 0 3621 lo0
OBS - The FBSD-GW has two fibs and the openbsd client is running on fib0,
which is the default fib, and why the pass rule has no route-to. It also
has 2
LANs.
Ping from FBSD-GW to a LANb server:
[~]>ping 172.10.2.28
PING 172.10.2.28 (172.10.2.28): 56 data bytes
64 bytes from 172.10.2.28: icmp_seq=0 ttl=127 time=201.900 ms
64 bytes from 172.10.2.28: icmp_seq=1 ttl=127 time=499.521 ms
64 bytes from 172.10.2.28: icmp_seq=2 ttl=127 time=259.940 ms
Connection from FBSD-GW to a LANb server:
[~]>telnet 172.10.1.7 3389
Trying 172.10.1.7...
Connected to adsl-172-10-1-7.dsl.sndg02.sbcglobal.net.
Escape character is '^]'.
To accomplish that, I added the following to pf.conf:
nat on tun0 from ! (tun0) to any -> (tun0) port 1024:65535
pass log quick on tun0 all
OBS -- This pass rule is rule number 0 !!
Now this is a ping from a LANa WS to 2 LANb servers:
[~]>ping 172.10.1.7
PING 172.10.1.7 (172.10.1.7): 56 data bytes
64 bytes from 172.10.1.7: icmp_seq=0 ttl=126 time=138.295 ms
64 bytes from 172.10.1.7: icmp_seq=1 ttl=126 time=108.962 ms
64 bytes from 172.10.1.7: icmp_seq=2 ttl=126 time=284.854 ms
PING 172.10.2.28 (172.10.2.28): 56 data bytes
64 bytes from 172.10.2.28: icmp_seq=0 ttl=126 time=280.377 ms
64 bytes from 172.10.2.28: icmp_seq=1 ttl=126 time=207.054 ms
64 bytes from 172.10.2.28: icmp_seq=2 ttl=126 time=397.242 ms
And a tcpdump from FBSD-GW:
[~]>tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
08:48:09.470985 IP 172.10.5.229 > 172.10.1.7: ICMP echo request, id 56407,
seq 0, length 64
08:48:09.609126 IP 172.10.1.7 > 172.10.5.229: ICMP echo reply, id 56407,
seq 0, length 64
08:48:10.484599 IP 172.10.5.229 > 172.10.1.7: ICMP echo request, id 56407,
seq 1, length 64
08:48:10.593410 IP 172.10.1.7 > 172.10.5.229: ICMP echo reply, id 56407,
seq 1, length 64
08:48:11.486604 IP 172.10.5.229 > 172.10.1.7: ICMP echo request, id 56407,
seq 2, length 64
08:48:11.771323 IP 172.10.1.7 > 172.10.5.229: ICMP echo reply, id 56407,
seq 2, length 64
08:50:36.861807 IP 172.10.5.229 > 172.10.2.28: ICMP echo request, id 52398,
seq 0, length 64
08:50:37.142004 IP 172.10.2.28 > 172.10.5.229: ICMP echo reply, id 52398,
seq 0, length 64
08:50:37.880531 IP 172.10.5.229 > 172.10.2.28: ICMP echo request, id 52398,
seq 1, length 64
08:50:38.087434 IP 172.10.2.28 > 172.10.5.229: ICMP echo reply, id 52398,
seq 1, length 64
08:50:38.882218 IP 172.10.5.229 > 172.10.2.28: ICMP echo request, id 52398,
seq 2, length 64
08:50:39.279326 IP 172.10.2.28 > 172.10.5.229: ICMP echo reply, id 52398,
seq 2, length 64
As you can see, nat is working properly and the packet finds its way back
to LANa WS.
Now, THE PROBLEM:
Ping is the only thing that works!
Any other type of connection doesn't even hit FBSD-GW tun0 !!
Connection attempt on a LANa WS (172.16.3.40) to LANb server:
[~]>telnet 172.10.1.7 3389
Trying 172.10.1.7...
Dump on FBSD-GW LANa iface:
[~]>tcpdump -i re0 -n host 172.16.3.40 and port 3389
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes
08:58:13.945180 IP 172.16.3.40.11942 > 172.10.1.7.3389: Flags [S], seq
2976879078, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3358365
ecr 0], length 0
08:58:16.952340 IP 172.16.3.40.11942 > 172.10.1.7.3389: Flags [S], seq
2976879078, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3361373
ecr 0], length 0
08:58:20.155346 IP 172.16.3.40.11942 > 172.10.1.7.3389: Flags [S], seq
2976879078, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3364576
ecr 0], length 0
Dump on FBSD-GW tun0 iface:
[~]>tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
DEAD Silence !!
I can't understand why a ping packet can find its way back to the LANa WS
but no other (tcp/udp) can't !!
I've been (re)searching for 3 days without success. I've tried every
combination I could think of nat and reply-to/route-to forms. but none
other than the following keeps ping working (at least).
nat on tun0 from ! (tun0) to any -> (tun0)
pass log quick on tun0 all
I don't have the knowledge to solve this any further.
Could anyone shed a light on this?
Thanks,
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winfoes FREE)
More information about the freebsd-questions
mailing list