On Tue, 8 Jul 2003, Tomaso Scarsi wrote:
> I've setup an m0n0wall <-> m0n0wall ipsec tunnel
> in the log file I can see:
> Jul 7 19:04:06
> racoon: INFO: pfkey.c:1110:pk_recvupdate(): IPsec-SA established:
> ESP/Tunnel aaa.bbb.ccc.ddd->eee.fff.ggg.hhh spi=34240748(0x20a78ec)
> Jul 7 19:04:06
> racoon: INFO: pfkey.c:1322:pk_recvadd(): IPsec-SA established:
> ESP/Tunnel eee.fff.ggg.hhh->aaa.bbb.ccc.ddd spi=70969143(0x43ae737)
> where aaa.bbb.ccc.ddd and eee.fff.ggg.hhh are the public ip of the two
> the two lan's connected are 192.168.1.0/24 and 10.0.0.0/24
> the lan ip of the m0n0wall are 192.168.1.254 and 10.0.0.254
> Now if I try to ping from a lan to the other I can ping only the
> gateway, for example from the 192.168.1.x I receive an answer only from
> the m0n0wall gateway 10.0.0.254 but not from any other host;
> it seems like a routing problem.
Yup. For full LAN<->LAN connectivity (without NAT):
1) Each m0n0wall needs to know that the other LAN is reachable via the
tunnel. You can check for this with "netstat -rn" in /exec.php. If the
tunnel is configured as a point-to-point link, the route to the remote
m0n0wall's IP should be established automatically, but that doesn't cover
the rest of its LAN.
2) Each other machine of interest needs to know that the m0n0wall is the
gateway for the other LAN. If the m0n0wall is the default gateway for the
LAN, this should be automatic (assuming #1). If not, then you may need
static routing entries on each other machine, although it's often
sufficient just to add a static routing entry to the default gateway, and
let it either forward the traffic (with an extra LAN trip) or inform the
other machines via ICMP Redirect.
Using NAT on the tunnel simplifies the routing, but it's usually
preferable to avoid that if possible.