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 17:03:43
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On May 26, 2007, at 15:18 , David Young wrote:
> On Sat, May 26, 2007 at 02:49:07PM -0400, Andreas Wrede wrote:
>> 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
>>> 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
>>> 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
>>> 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
>> area OSPF network running on top.
> To my mind, it does not follow from the number and configuration of
> tunnels that my suggestion is impractical. Maybe if you explain more
> about what you are trying to accomplish, then I can give a more useful
Ok. I need to connect multiple private networks (currently 8) with
each other in a secure fashion. At least 2 of these networks have
multiple connections to the Internet. Two of the gateways are Cisco
routers, the remaining 6 are NetBSD machines. There is a secondary
requirement to connect distant private networks, ie. networks that
have no Internet connection, only a private link to another private
My solution currently is to create a full mesh of tunnels between all
nodes, create IPsec transport encryption "underneath" each tunnel and
run OSPF on top to manage the routing.
>> 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...
> What version of NetBSD are you running? I removed that hack from
> -current, both because it is untenable to preserve it, and because it
> leads to an obscure router configuration. 5.0 will not contain the
Hmm.. pity. After thinking about my "..looks like a hack" comment
some more, I now actually like the solution. Yes, it can make router
config more obscure but the moment I understood the routing problem,
I saw the beauty of the solution. It's been part of gre(4) from the
Right now, I am running 4.0_BETA2 on the NetBSD nodes.
BTW, gre(4) in -current still has the less specific clause.
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-----