[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  RE: [m0n0wall] netstat and vpn
 Date:  Tue, 17 Aug 2004 01:10:46 -0700 (PDT)
On Fri, 13 Aug 2004, sietze wrote:

> Thanks for a very complete answer. Could be added to the IPsec chapter in
> the manual.
> 
>  > It acts like it was originally designed for transport mode and then had
> tunnel mode added as
>  > an afterthought.
> I am not familiar witht he history of racoon, However when reading up on it
> I found some references
> to "transport mode". It looks like this behaviour of racoon might be by
> design.

Transport mode is for adding IPsec at *connection* endpoint (i.e. host),
by simply inserting the IPsec header between the IP header and the
transport-layer header (TCP, UDP, etc.).  Since there's no concept of a
"tunnel" in that case, the "policy" approach makes sense.  But there are
numerous drawbacks to using "policy" rather than routing for tunnel mode.

It's not a racoon issue, it's a kernel issue, since it relates to how
packets get diverted to IPsec processing in the kernel, and how they turn
back into input at the receiving end.

>  > Unfortunately, the mere existence of ostensibly correct entries isn't
>  > always sufficient to get traffic to pass.
> Indeed. According to the logs and the IPsec diagnostics in the the m0n0
> webgui the tunnels build without any problem. Good SPI's, good SA's.
> Stopping and starting tunnels, IPsec or restarting m0n0 causes the
> identifiers to be different. But this is noted instantly and in no time a
> good tunnel is established again. I have been unable to find any
> discrepancy.

My current opinion is that almost all problems with traffic not passing in
spite of good SAs are caused by "orphaned" send SAs whose twins have
dsappeared from the receiving end.  Depending on the SA selection priority
at teh sender, these can be problematic even when properly paired SAs are
also available.

>  > 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.
> Since the tunnels seem to build correctly is looks like routing is the
> problem indeed.
> This workaround Frank mentions does get around this routing problem, in some
> cases.
> Regrettably not in all :(

The above is a workaround for the particular case of trying to originate
tunnel traffic on the m0n0wall itself.  Of course this includes any pings
that one might be trying to use to make the tunnel come up.

>  > > Should "netstat -rn" show any information regarding the route
>  > > to the other side of the tunnel?
>  > Not in FreeBSD.  See above.
> That is good to now. With other operating systems one sees something like
> virtual interfaces. Much like the PPTP interface in m0n0. And we come to
> expect to find it in the routing table as well.

There has been discussion about whether "netstat -rn" should show IPsec
SPs even though they're not really "routes".  The prevailing opinion
(which I agree with) is that lying about the routing tables would cause
even more confusion.

					Fred Wright