Date: Wed, 14 Mar 2007 14:06:45 -0500 (CDT) From: Robert Johannes <rjohanne@piper.hamline.edu> To: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> Cc: freebsd-security@freebsd.org Subject: Re: freebsd vpn server behind nat dsl router Message-ID: <Pine.LNX.4.64.0703141353250.3246@wnk.hamline.edu> In-Reply-To: <20070307212442.GA1384@jayce.zen.inc> References: <Pine.LNX.4.64.0703061251310.15938@wnk.hamline.edu> <20070307170617.GA2799@zen.inc> <Pine.LNX.4.64.0703071146580.3635@wnk.hamline.edu> <20070307212442.GA1384@jayce.zen.inc>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Mar 2007, VANHULLEBUS Yvan wrote: > On Wed, Mar 07, 2007 at 12:04:17PM -0600, Robert Johannes wrote: >> Thanks for your response. My freebsd vpn servers are behind the dsl >> routers at each site which. The modems have firewall and NAT turned on. >> The vpn servers are part of the local LANs, and I have port-forwarding >> setup between the dsl modems and the vpn servers. E.g, when traffic comes >> from the internet destined for port 500, I forward that traffic to the vpn >> servers (192.168.x.254 on the diagram). > > If your redirection only works for port 500, it won't be enough, as it > will only allow IKE negociations, not encrypted traffic. > > You'll have to add forwarding for ESP protocol, or use NAT-T patch and > also forward UDP 4500 port. > > >> The freebsd servers are not running a firewall or NAT at this point. I >> don't think they need to run NAT, but I haven't decided on the firewall >> yet. >> >> So, given that situation, I don't know if the NAT changes to the kernel >> you are suggesting below would help, since NAT is happening on the dsl >> routers. I am guessing my problem is between the vpn server and the dsl >> router's NAT capability. I have done a tcpdump on the gif interface, and >> I can see the ping requests being made across it, but there's no response. >> I don't even know if the traffic is making it beyond the vpn box, let >> alone beyond the dsl modem. > > The NAT-T patch I was talking about adds the kernel part of an *IPSec* > feature: support for NAT-Traversal extension (RFCs 3947 and 3948), > which allows IPSec tunnels to be established if there is some NAT > between IPSec gates. > > This is exactly your setup. Ok, I have done quite a bit of work since my last email, but I still don't see visible progress. I did rebuild world and the kernel with the NAT-T patches/support that you recommended. I have been playing around with ipsec e.t.c. I have created an esp tunnel between my two sites, and I am sending some ping traffic to the remote end, but the packets don't seem to get through. Here's a snippet of what I see on tcpdump: 14:06:53.594241 IP 190.41.95.135 > client-201.240.165.191.speedy.net.pe: \ IP 192.168.1.254 > 192.168.0.254: ICMP echo request, id 5784, seq 1519, \ length 64 (ipip-proto-4) 14:06:54.595071 IP 190.41.95.135 > client-201.240.165.191.speedy.net.pe: \ IP 192.168.1.254 > 192.168.0.254: ICMP echo request, id 5784, seq 1520, \ length 64 (ipip-proto-4) >From what I can tell, the kernel knows that it is to send the ping request from 192.168.1.254 to 192.168.0.254 through the tunnel mouths 190.41.95.135 and 201.240.165.191. But, there's no request from the other end. Doing a tcpdump on the other side (192.168.0.254), nothing is coming in. I have also done a ping from the latter machine to the former, but with exactly the same problem. Nothing seems to get to the other end. The tunnel is not using racoon yet. I figure that I should be able to see some traffic going back and forth before I use racoon to manage keys. The tunnel was created by the following lines on one host, and reversed on the other: spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec esp/tunnel/190.41.95.135-201.240.151.15/require; spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec esp/tunnel/201.240.151.15-190.41.95.135/require; If any one can shed some more light on this, I would appreciate it. thanks robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.64.0703141353250.3246>