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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Brian A. Seklecki
All:

I'm CC'ing everyone who has previously posted the "destination host
unreachable" behavior when setting up a generic 4-host IPSec VPN tunnel
config per the template in vpn(8) / isakmpd.conf(5).

NOTE: This is not the "I can't ping the other side of the tunnel from the
remote gateway because I forgot to specify the source IP flag to ping(8)"
bug.

In the template, gateway A and B share a "WAN" circuit, normally an
ethernet segment (a /30 for example).  Each has a CIDR of RFC1918 Space on
a second interface (a /24 for example)

The tunnel(s) comes up, netstat -rn -f encap shows the ipsec routes,
ipsecadm(8) shows the flows.

However:

If gateway A sends an ICMP packet using ping(8)'s "-I" with a source
address of the private subnet on its second interface to the IP on the
private/second interface on gateway B, the packet gets properly
encapsualted and transmitted per pflog0.

However, if the destination of the ICMP ping is an IP in the subnet
assigned to the Ethernet segment on Gateway B's private/second interface,
the packet:
- crosses the tunnel
- leaves the private interface, hits host X
- host X returns the packet to Gateway B
- Gateway B drops the packet, and returns Host X an ICMP "host
unreachable" for Gateway A !!!!

As crazy as that sounds, it happens?

And after hours of troubleshooting, the problem turns out to be??!?!

[*drumroll*]

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

*EVEN THOUGH ONE IS NOT REQUIRED IN THE LAB CONFIGURATION*

1) If gateway A and gateway B have "WAN" interfaces on an ethernet segment
such as a /30, they know the route to their respective WAN networks via
"directly connected route".

2) isakmpd/ipsec traffic can flow across that WAN network with no
addtional routing assistance.

3) Once the phase 2 negotiation is complete, both boxes know a new special
"ipsec route" for a /24 "via the ipsec peer".

4) TRAFFIC EGRESSING THE TUNNEL MUST HAVE A SOURCE ADDRESS THAT MATCHES
THE ACL.

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.

Try it.  >:}

This is the second time I've been bitten by these "psuedo" routes .

See PR 4314/system.

~BAS

Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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

Markus Friedl
In reply to this post by Brian A. Seklecki
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

Reply | Threaded
Open this post in threaded view
|

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

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