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
