[ previous ] [ next ] [ threads ]
 
 From:  "sietze" <m0n0wall at sistemaseuropeos dot com>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] netstat and vpn
 Date:  Fri, 13 Aug 2004 11:43:03 +0200
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.

 > 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.

 > 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 :(

 > > 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.

In another thread on IPsec Fred mentioned:
 > Fixing something that almost works is likely to be easier than
implementing something
 > entirely new.
I think that m0n0 is great. Almost all the other functions I had working in
minutes. It makes one wonder why firewalling and routing ever were
difficult.
The only issue I find is IPsec. And that is not beacuse of m0n0 but because
of racoon and FreeBSD.
And IPsec also almost works. I hope that the pending issue with IPsec and
m0n0/FreeBSD will be sorted out as well.

(Excuses for the delayed follow up. Going through all the steps with IPsec
in different setups took some time)