From: Sam Sgro (sam_at_freeswan.org)
Date: Fri Oct 11 2002 - 21:33:39 CEST
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 10 Oct 2002, Ian Morgan wrote:
> On host A (192.168.1.1):
>
> # ipsec eroute
> 0 0.0.0.0/0 -> 192.168.1.130/32 => tun0x100a_at_192.168.1.130
> 10 192.168.1.0/24 -> 192.168.0.0/16 => tun0x1004_at_66.x.x.x
You have overlapping eroutes; don't expect consistency, just a gateway into
madness. Can you narrow down that 192.168.0.0/16 eroute into something that
doesn't overlap with the 192.168.1.x 'net? I've got some additional thoughts
below.
> # route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> 192.168.1.130 192.168.1.130 255.255.255.255 UGH 0 0 0 ipsec2
> 24.43.40.0 * 255.255.255.128 U 0 0 0 eth0
> 24.43.40.0 * 255.255.255.128 U 0 0 0 ipsec0
> 192.168.1.0 * 255.255.255.128 U 0 0 0 eth1
> 192.168.1.0 * 255.255.255.128 U 0 0 0 ipsec1
> 192.168.1.128 * 255.255.255.128 U 0 0 0 eth2
> 192.168.1.128 * 255.255.255.128 U 0 0 0 ipsec2
> 192.168.0.0 router 255.255.0.0 UG 0 0 0 ipsec0
> 127.0.0.0 * 255.0.0.0 U 0 0 0 lo
> default router 0.0.0.0 UG 0 0 0 eth0
> Trying to ping host B (192.168.1.130) from Host A 192.168.1.129)
So, 192.168.1.129 is another one of host A's aliases. A network diagram would
be handy, outlining your tunnels and how you intend for traffic to flow.
Config files also help in that regard.
> debugging tells me that ipsec_findroute thinks that tun0x1004 is correct,
> when it is obviously not.
Log excerpts would be handy, here, to confirm that.
Actually, it is correct, in a sense. Host A is a member of the 192.168.1.0/24
subnet, trying to communicate with a member of the 192.168.0.0/16 subnet.
Depending on how you weigh Source and Destination addresses in the decision
making process, the second eroute is a valid contender for the best route.
Have you tried revising your tunnel definitions to add another eroute:
192.168.1.0/24 -> 192.168.1.130/32
or
192.168.1.129/32 -> 192.168.1.130/32
You've probably config'd your tunnel to 192.168.1.130/32 with 192.168.1.129/32
protecting the 0.0.0.0 subnet somehow? You could try making a formal
gateway-to-subnet tunnel to produce the second eroute.
> Yet, ipsec_tunnel_start_xmit still calls
> "ip_send() on device:eth2" (the correct route for the tun0x100a),
> when the route to tun0x1004 is eth0!
Again, overlapping routes can cause confusion, and its possible KLIPS is being
consistent, here. Showing us the "klipsdebug=all" will help in diagnosis.
- --
Sam Sgro
sam_at_freeswan.org
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.
iQCVAwUBPacnlUOSC4btEQUtAQGYnwP+PtD3jd45X7twqInZE+R456eRloKrF6p9
PU10vNmpE1VQWNb3aImAKK2omRztrbarZAguhoexbnhkYI2G55mcL55/YEu2pPu8
pSAafprBlqQXymZw8kZBGdwPJvnRoA+XPCZFwzoSloqcPpCIERYiFvpCdKhSLKpk
+PwcqFkuiTI=
=v5d4
-----END PGP SIGNATURE-----
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.5 : Sat Oct 12 2002 - 05:20:25 CEST