This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-11-42761002
Content-Transfer-Encoding: 7bit
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:
>>
>>>
>>> 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.

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

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

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

Right now, I am running 4.0_BETA2 on the NetBSD nodes.

BTW, gre(4) in -current still has the less specific clause.

-- 
     aew


--Apple-Mail-11-42761002
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFGWKCyEh/h9J/TQyERAlKzAJ9ve8xQAKtzrcHkkCsPEFmfBvGiagCgiuvm
dTrcCvYjPXmdLBRxpYm3pLU=
=da0L
-----END PGP SIGNATURE-----

--Apple-Mail-11-42761002--