Date: Sat, 28 Sep 2002 12:19:29 -0700 From: "Ian Cartwright" <ian351c@cox.net> To: "'Lars Eggert'" <larse@ISI.EDU> Cc: <freebsd-hackers@freebsd.org> Subject: RE: VPN Routing through gif (4) tunnel Message-ID: <006001c26723$f80775f0$6600a8c0@iansxp> In-Reply-To: <3D95F282.8020009@isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <larse@isi.edu> USC Information Sciences Institute
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006001c26723$f80775f0$6600a8c0>