From owner-freebsd-questions@FreeBSD.ORG Thu Jul 24 12:36:04 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13D8A813 for ; Thu, 24 Jul 2014 12:36:04 +0000 (UTC) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF64F2B64 for ; Thu, 24 Jul 2014 12:36:03 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id la4so4768577vcb.9 for ; Thu, 24 Jul 2014 05:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:date:message-id:subject:from:to:content-type; bh=acocERr50MKxRRwdjg2RScRbsUHXK8FMpIYfKdaIJ7A=; b=AteconmloG0z1BwIsIaVh685sC7PQJWIaYIYD0VENFeBRHZzhs8XofjnABTLlawf0F Fq9WIRkzTylV/iE8QGJV2M5qK3jb8mjxKdI6Vn5S33ISKJ2/i5PDwEzarntkjUeS7ShA +kfXxEf1teeM17lm2sJhv/aUP/R7cQISOiT70= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=acocERr50MKxRRwdjg2RScRbsUHXK8FMpIYfKdaIJ7A=; b=Q08jBAo2F5qMcqXzYNqSSFM2ElrFpZ8XqAQn50nfN59KIzp+OrcHo72YvOwXuJ5Ap3 Kcf8w717Kc016pHfmSJ81vDclnutDHQgF2Xn+O07Et/R8WeSBo5tI7dhFJOx1nndLzty TZse9jEAv+O1dSuCL44xQOPtbk3hbobcRmzekwUFxYkNrA+/Uy0MG+wosRvPJI7qsbTA dgCUVaGD1NbqkImzhXYEg8D3fbITRBOZjX3nyPh7OM5P8W0wOA5bZNweHLtMr+ONfuvH 407QQ2lR8WeuUmVo5LbvKl+fnouunxsVHr5KGDgjOKWp3Yv6me8hfSLbwva0flIZqbun uzAg== X-Gm-Message-State: ALoCoQn7mKRWFwUOcnyC89pRfdqfCxdQ1MfuaH4gkdV83z2u5+utqNw0afAcIOKVP32u0kw/4yHB MIME-Version: 1.0 X-Received: by 10.52.53.135 with SMTP id b7mr9676138vdp.67.1406205362478; Thu, 24 Jul 2014 05:36:02 -0700 (PDT) Received: by 10.58.185.162 with HTTP; Thu, 24 Jul 2014 05:36:02 -0700 (PDT) Date: Thu, 24 Jul 2014 09:36:02 -0300 Message-ID: Subject: Openvpn problem From: Mario Lobo To: freebsd-questions Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 12:36:04 -0000 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 metric 0 mtu 1500 options=80000 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)