On Sat, May 26, 2007 at 02:49:07PM -0400, Andreas Wrede wrote:
> 
> 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, 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.

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
suggestion.

> 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  
> 0x5
> 
> 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 hack.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24