Date: Thu, 24 Jul 2014 09:36:02 -0300 From: Mario Lobo <lobo@bsd.com.br> To: freebsd-questions <freebsd-questions@freebsd.org> Subject: Openvpn problem Message-ID: <CA%2ByoEx-O_fCV5i8479-gOV2L6YVZCHy7eu2Mvd5xzKW-tS1Ttw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2ByoEx-O_fCV5i8479-gOV2L6YVZCHy7eu2Mvd5xzKW-tS1Ttw>