From owner-freebsd-hackers Sat Sep 28 12:19:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80C7937B401 for ; Sat, 28 Sep 2002 12:19:27 -0700 (PDT) Received: from ip24-56-36-25.ph.ph.cox.net (ip24-56-36-25.ph.ph.cox.net [24.56.36.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1622E43EA3 for ; Sat, 28 Sep 2002 12:19:27 -0700 (PDT) (envelope-from ian351c@cox.net) Received: from iansxp (iansxp.iansponderosa.org [192.168.0.102]) by ip24-56-36-25.ph.ph.cox.net (8.12.3/8.11.4) with ESMTP id g8SJJWSP000179; Sat, 28 Sep 2002 12:19:32 -0700 (MST) (envelope-from ian351c@cox.net) From: "Ian Cartwright" To: "'Lars Eggert'" Cc: Subject: RE: VPN Routing through gif (4) tunnel Date: Sat, 28 Sep 2002 12:19:29 -0700 Message-ID: <006001c26723$f80775f0$6600a8c0@iansxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3D95F282.8020009@isi.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Lars, The 200.200.201.1 is the external IP address of the remote gateway. The 200.200.200.0/16 is the internal (remote) network. In real life the networks do not overlap (my sample seems to suggest that they do. Oops...). As I understand it, so long as the local tunnel endpoint is the external interface of the local gateway, the encapsulated traffic should already look like it is coming from the external interface and should not be NATed (while the traffic inside the tunnel looks like it is coming from my local RFC1918 network). It is also my understanding that IPFILTER sees the traffic before the rest of the kernel (i.e. KAME) and may do the NATing before it enters the IPSec tunnel, thus munging the works entirely. This does not bode well. Was my original assumption correct, that as long as the tunnel is specified correctly in the SPD, that the routing will happen automgically? I can try disabling IPFILTER and trying this to see what happens, though I have not had any luck with this in the past, unless I used the gif tunnel. Maybe I am missing something. Assuming I am not tunneling another packet filtering software (like IPFILTER) and the kernel is otherwise configured correctly, all I should need are: correct entries in the SPD specifying the endpoints and networks for the tunnel; and a valid racoon config. Does this sound right? Thanks again! Ian -----Original Message----- From: Lars Eggert [mailto:larse@ISI.EDU] Sent: Saturday, September 28, 2002 11:19 AM To: Ian Cartwright Cc: freebsd-hackers@freebsd.org Subject: Re: VPN Routing through gif (4) tunnel Ian, this stuff is definitly tricky to get into... :-) Ian Cartwright wrote: > > Thank you very much for the document, it was very informative. So what > you are sayng is that I am running two tunnels in parallel? I had > suspected this, but since it was the only way I was able to make it > work and all the examples I could find fro FreeBSD involved a gif > tunnel, I thought therer might be some "special" inbteraction with the > kernel that required a gif tunnel for tunnel mode IPSec. I sent email to a bunch of tutorial authors that do the two-tunnel-in-parallel-thing when this came up on the list before. Two at least said they were going to modify their tutorials ("when I wrote this I was still learning about this stuff", etc.), but I don't think they did yet. > So, continuing with my configuration from my original message "setkey > -DP" would shouw: > > 200.200.200.0/16[any] 192.168.0.0/24[any] any > in ipsec > esp/tunnel/200.200.201.1-100.100.100.1/require > spid=8 seq=1 pid=8125 > refcnt=1 > 192.168.0.0/24[any] 200.200.200.0/16[any] any > out ipsec > esp/tunnel/100.100.100.1-200.200.201.1/require > spid=7 seq=0 pid=8125 > refcnt=1 This has the same issues as your gif tunnel setup. You want the tunnel headers (i.e. what gets slapped onto as the outer header of your packets after IPsec processing) to go between your local gatway's external IP address (100.100.100.1) and the external interface of the VPN-1 box at the remote location (don't think that IP address was in your earlier email.) The selector (i.e. the pattern that decides which packets should go into the tunnel) would NORMALLY match the local and remote subnetworks. HOWEVER, since you're doing NAT, this is getting very tricky. One option is to select on the RFC1918 private addresses on both sides, i.e. grab the packets and IPsec-process them BEFORE they get NAT'ed. I'm pretty sure this could be made to work if both sides were using FreeBSD, but I'm not a fan of VPN-1 (see below). Another possibility would be to select the packets after they have been NAT'ed, but then negotioate a TRANSPORT mode SA. (Since NATs look like hosts to the network, transport mode betweenm them is valid.) Lars [The reason I'm sceptical about VPN-1 is that Checkpoint was using a range of ports that were registered to others - some to us - for their VPN-1 thing. When we contacted them about it, they seemed clueless about IANA and registered ports. Not the most confidence-inspiring behavior for a firewall vendor.] -- Lars Eggert USC Information Sciences Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message