Re: *STUPID* IPSEC Routing Bug - No Default Gateway?!

2005-12-06 Thread HÃ¥kan Olsson

On 6 dec 2005, at 06.14, Brian A. Seklecki wrote:


OpenBSD requires that gateway A and gateway B have a default route  
declared


*EVEN THOUGH ONE IS NOT REQUIRED IN THE LAB CONFIGURATION*
...
So why in the world would a default gateway be required?  A default  
gateway is only required to reach subnets for which routes do not  
exist.


There is a test pretty early in the routing code that checks 'is the  
destination reachable?', i.e do we have a route to the destination  
IP? If not then there's no need to process this packet further, that  
would just be a waste of time. Currently the above test only looks at  
IP routes, and it needs to be extended to also check for IPsec SPD  
(flows), if such are present.


The default route matches all destinations, so it will work as a  
catch-all. However you only require a route to the actual network you  
are tunneling to.


I've started to look at this a while ago, but either got sidetracked  
or ran into problems. I can't remember which at the moment. I'll have  
to look at it again.


/H



Re: *STUPID* IPSEC Routing Bug - No Default Gateway?!

2005-12-06 Thread Markus Friedl
On Tue, Dec 06, 2005 at 12:14:20AM -0500, Brian A. Seklecki wrote:
 OpenBSD requires that gateway A and gateway B have a default route 
 declared

no, you just need a route to the destination, this is a known
but and there's no simple fix.  however, just create a network
route for the peer that points back to the sender. this way
you avoid sending out unencrypted traffic if the ipsec tunnels
are down.

-m



Re: *STUPID* IPSEC Routing Bug - No Default Gateway?!

2005-12-06 Thread Brian A. Seklecki
 no, you just need a route to the destination, this is a known

a route to the destination of the tunnel...(that overlaps with the encap
route...)...

 but and there's no simple fix.  however, just create a network
 route for the peer that points back to the sender. this way

...or a route to the isakmpd peer?  because techncially one gets added
to the route table by ARP:

192.168.1.50  0:11:43:e8:2b:c6   UHLc 0   679672  -   vlan30

...this of course would differ if there were multiple hops between the
isakmpd peers.

~BAS

 you avoid sending out unencrypted traffic if the ipsec tunnels
 are down.
 
 -m