Subject: Re: NAT/GRE and IPsec transport interaction
To: David Young <>
From: Andreas Wrede <>
List: current-users
Date: 05/26/2007 14:49:07
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On May 25, 2007, at 20:16 , David Young wrote:

> Andreas,
> 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  
> router.
> After PF translates the packets, it is too late for IPSec processing.
> Perhaps you can avoid NAT altogether by both adding a route on . 
> 178.223
> to 10.99/16 with nexthop .14.216 and addressing .14.216 by its address
> on the tunnel,  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 -> netmask 0xffffffff
         inet6 fe80::211:2fff:fe87:ff1%gre91 ->  prefixlen 64 scopeid  

adding a host route like this
route add yy.yy.14.216
(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
content-transfer-encoding: 7bit

Version: GnuPG v1.4.1 (Darwin)