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 <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
