On Mon, 2 Aug 2004, sietze wrote:

> According to the logs racoon happily and quickly completes phase 1 and 2
> when trying to build a IPsec tunnel. But after that no traffic passes
> through the tunnel. Nothing shows in the firewall log though I have checked
> logging for the ESP rule.
> 
> In the archives I find similar cases. In one case it is suggested to run
> "netstat -rn".
> But there is no follow up there.

For "normal" VPN tunnels, looking at the routing tables is the right
thing.  Unfortunately, FreeBSD's IPsec support is done in a really kludgy
way that bypasses normal routing mecahnisms, normal filtering mechanisms,
normal packet capture mechanisms, etc., etc.  It acts like it was
originally designed for transport mode and then had tunnel mode added as
an afterthought.

IPsec traffic is diverted by "policy" entries, provided that the necessary
SAs are set up, and "policy" trumps "routing".  So what you need to look
at for IPsec is the SA and SP databases, which can be viewed under
Diagnostics->IPsec.  The SP entries are only a function of the
configuration, while the SA entries are dynamically created by racoon's
IKE exchanges.  (Theoretically, IPsec could be used without IKE if the SAs
were also configured manually, but that would be a nightmare, hence IKE).

Unfortunately, the mere existence of ostensibly correct entries isn't
always sufficient to get traffic to pass.  This *might* be due to a
mismatch on the SPI values, or it might just be some general poisoning in
the kernel.  The next time I see this state, I'll check the SPIs on both
ends to see if they agree.  I have found that the racoon restarts caused
by "applying" IPsec changes don't necessarily clean up bad state in the
kernel, but disabling and reenabling IPsec seems to.

Complicating things further is that, for IPsec tunnels, pinging the remote
end from the m0n0wall itself doesn't work even when the tunnel is actually
working.  This is yet another artifact of "policy-based routing".  The
problem is that the wrong local IP address is chosen for any "connection"
going through the tunnel, due to the tunnel's not looking like an
interface.

There's a kludgy workaround for this - add a static route to the remote
end of the tunnel, with the m0n0wall's own IP in the local-end range
(typically its LAN IP) specified as the "gateway".  This causes the
routing code to think it's going to send the packet over the internal
interface (e.g. LAN) and use that to determine the local IP, only to have
the IPsec code snatch the traffic away and send it through the tunnel via
the tunnel's interface.  Ugly, but it works.

> When entering "netstat -rn" only the normal routes show, as when there is no
> tunnel. Nothing regarding the other LAN.
> Should "netstat -rn" show any information regarding the route to the other
> side of the tunnel?

Not in FreeBSD.  See above.

					Fred Wright