Subject: Re: NAT/GRE and IPsec transport interaction
To: David Young <email@example.com>
From: Andreas Wrede <firstname.lastname@example.org>
Date: 05/26/2007 14:49:07
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On May 25, 2007, at 20:16 , David Young wrote:
> I suspect that NAT happens after IPSec processing. Your IPSec
> rules do
> not match the packets w/ source in 10.99/16 when they enter your
> After PF translates the packets, it is too late for IPSec processing.
> Perhaps you can avoid NAT altogether by both adding a route on .
> to 10.99/16 with nexthop .14.216 and addressing .14.216 by its address
> on the tunnel, 192.168.6.10. In that way, the traffic from
> 10.99/16 to
> .14.216 will go through the tunnel, and the encapsulated packets will
> be transported in ESP packets as you expect.
While that would probably work, it's impractical in my case because
there are many gre tunnels (60+) in a fully-meshed VPN, with a multi-
area OSPF network running on top. But your routing idea got me to
find a solution:
given the gre(4) tunnel:
gre91: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
tunnel inet xx.xx.178.223 --> yy.yy.14.216
inet 10.99.1.1 -> 192.168.6.10 netmask 0xffffffff
inet6 fe80::211:2fff:fe87:ff1%gre91 -> prefixlen 64 scopeid
adding a host route like this
route add yy.yy.14.216 192.168.6.10
(ie. pointing the tunnel's destination to it's endpoint) worked.
According to gre(4), "gre device needs a route to the destination
that is less specific than the one over the tunnel", so this should
work even though it looks like a hack. Still have to test tunnel
setup and teardown...
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
-----END PGP SIGNATURE-----