Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: Sterling on October 21, 2003, 10:57:58 PM
-
I'm absolutely desperate here... I'll send a check (very serious here) to someone who can help me. I've been beating my head on my desk for several days trying to make this work.
I need to route traffic over an ipsec tunnel to a second gateway behind a remote SME box. Everything's working fine between the two LANs behind the SME boxes. The trouble is I can't seem to route traffic from the "P LAN" to a second gateway behind the remote (L) SME box. See the URL below for a diagram on what I'm trying to do here. I can ping the 172.20.106.126 gateway from the P SME box and from the P LAN. I can't ping 172.20.1.12 from the P SME box or from the P LAN but I can from the L SME Box.
Basically I need to know how to route 172.20.1.0/25 traffic from the P SME box to the L SME box, then to the 172.20.106.126 gateway so I can access 172.20.1.12 from the P LAN.
Clear as mud I'll bet :) Please let me know if you need more info here.
I've included the current routing tables on the diagram here:
http://www.abacustechnology.net/files/BOL(Obscured).pdf
Thanks,
Sterling
-
In P sme G/W router why is the network 172.20.2.x there and where is the route entry for 172.20.1.x network in P SME G/W ?
Also can you ping from the 172.20.1.12 server to 172.20.106.125 and visa-versa ?
Bill
-
Also have you tried to trace route between the problemsome lans and what were the results of the trace route ?
Bill
-
172.20.2.x was there as a leftover. I’ve added the following route before but I've added it again just now to the P SME box.:
Destination Gateway Genmask Flags Metric Ref Use Iface
172.20.1.0 P-P-P-1.cl 255.255.255.128 UG 0 0 0 ipsec0
Still can't ping from P SME or P LAN to 172.20.1.12.
Traceroute from P SME box and P LAN to 172.20.1.12 is dead as follows:
traceroute to 172.20.1.12 (172.20.1.12), 30 hops max, 38 byte packets
1 * * *
2 * * *
but traceroute from P SME to 172.20.106.126 returns:
traceroute to 172.20.106.126 (172.20.106.126), 30 hops max, 38 byte packets
1 L.L.L.L (L.L.L.L) 138.493 ms 136.123 ms 135.381 ms
2 172.20.106.126 (172.20.106.126) 138.577 ms 140.151 ms 135.710 ms
Pings from L SME are successful to both 172.20.106.126 and 172.20.1.12.
One last note, P LAN can be pinged successfully from 172.20.1.12.
Thanks,
Sterling
-
By adding the last entry into the P SME should have fixed the routing problem. Being able to ping one way but not the other bothers me. Post an update of the routing tables of all three SME servers. Is the 'second gateway an SME box or just a router ?
bill
-
Also to clarify
172.20.1.0 /25 = Network Address 172.20.1.127 = Broadcast
172.20.160.128 /25 = Network Address 172.20.160.255 = Broadcast
172.20.106.0 /25 = Network Address 172.20.106.127 = Broadcast
All addresses between network and broadcast addresses are hos machines ?
Bill
-
P SME's routing table:
Destination Gateway Genmask Flags Metric Ref Use Iface
L.L.L.L P-P-P-1.cl 255.255.255.255 UGH 0 0 0 ipsec0
172.20.160.128 * 255.255.255.128 U 0 0 0 eth0
172.20.1.0 P-P-P-1.cl 255.255.255.128 UG 0 0 0 ipsec0
172.20.106.0 P-P-P-1.cl 255.255.255.128 UG 0 0 0 ipsec0
P.P.P.0 * 255.255.255.0 U 0 0 0 eth1
P.P.P.0 * 255.255.255.0 U 0 0 0 ipsec0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default P-P-P-1.cl 0.0.0.0 UG 0 0 0 eth1
L SME's routing table:
Destination Gateway Genmask Flags Metric Ref Use Iface
P-P-P-P.cl L.L.L.1 255.255.255.255 UGH 0 0 0 ipsec0
172.20.160.128 L.L.L.1 255.255.255.128 UG 0 0 0 ipsec0
172.20.2.128 172.20.106.126 255.255.255.128 UG 0 0 0 eth0
172.20.1.0 172.20.106.126 255.255.255.128 UG 0 0 0 eth0
172.20.106.0 * 255.255.255.128 U 0 0 0 eth0
L.L.L.0 * 255.255.255.0 U 0 0 0 eth1
L.L.L.0 * 255.255.255.0 U 0 0 0 ipsec0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default L.L.L.1 0.0.0.0 UG 0 0 0 eth1
The 172.20.106.126 gateway is just a router but it apparently has been configured to accept traffic from P.P.P.P which seems to be true since it's accepting pings from that address. The problem seems to lie in the P SME box because a traceroute to 172.20.1.12 from P LAN returns the first hop as the internal address (172.20.160.253) of the P SME box but dies (* * *) on the second hop and further. Also, a traceroute to 172.20.1.12 directly from the P SME box returns nothing, just "* * *" for all hops, but completes the route successfully when tracerouting to 172.20.106.126.
It's like the P SME box won't even try route 172.20.1.0/25 traffic at all even though it's in the routing table and added to the local networks panel in server-manager. I have also tried it with 172.20.1.0/25 not added to the local networks. The local networks panel seems to have no effect on the routing table on that machine as I had stated in a previous unanswered post. I have to add the route using 'route add' from the command line.
Thanks for your help thus far,
Sterling
-
Yep, all host addresses are between, but don't include, the network and broadcast addresses.
-
I studied the tables of the SME boxes which look correct. Your able to 'knock at the front door" of the router with trace route from the P lan. You are also able to ping from 172.20.1.12 to the P Lan successfully, so whats going on !! What type of system in on 172.20.1.12 ? Can U trace route from 172.20.1.12 to P LAN ? What type of router is it ? Can U replace the system at 172.20.1.12 with a windows PC for testing ? Have U tried usings a Packet sniffer like Ethereal (www.ethereal.org) ? What version are each of the SME boxes ?
I do agree the problem points to the P Lan, but I'm not 100% sure.
Bill
-
Sterling
I need to know the settings placed in both SME boxes IP-Mask-Router
Bill
-
Sterling
In the previous post I was refering to the local network settings
Bill
-
I have no control of 172.20.106.126 router or anything behind it. They're actually in a different state. The people who administer the out-of-state router and network are positive that they have their end configured correctly and don't want to be bothered any more about it.
172.20.1.12 is just a pingable system that allows one to test access to their 172.20.1.0/25 network.
The P and L SME boxes are 5.6 with the 5.6 FreeSWAN contrib as the ipsec tunnel.
-
Not sure where to find that, sorry.
Bill Pflaumer wrote:
>
> Sterling
> I need to know the settings placed in both SME boxes
> IP-Mask-Router
>
>
> Bill
-
When to goto the server-manager of each box, there is a local network applet. click on it to find the cuurent settings
bill
-
P SME's Local Networks:
Network Subnet mask Number of hosts Router
172.20.1.0 255.255.255.128 128 default
172.20.106.0 255.255.255.128 128 default
172.20.2.128 255.255.255.128 128 default
L SME's Local Networks:
Network Subnet mask Number of hosts Router
172.20.1.0 255.255.255.128 128 172.20.106.126
172.20.160.0 255.255.255.128 128 default
172.20.2.128 255.255.255.128 128 172.20.106.126
They told me to set up for a 172.20.2.128/25 route for future expansion, but that probably has no bearing on the problem at hand.
-
for the hell of it change the 172.20.1.0 network to 172.20.106.126 on the P lan
bill
-
Sterling
I meant to say change the 172.20.1.0 network route to 172.20.106.126 on the P lan instead of default.
Sorry getting tired
Bill
-
I looked a little further and noticed the local network router settings will not allow what I stated in the previos post. Sorry
bill
-
It gives me "Error: router address is not accessible from local network. Did not add network." when trying to do that.
It also gives me a similar "Network unreachable" error when I try to use the remote router (172.20.106.126) as a gateway using the route command. I assume this is because 172.20.106.126 isn't considered to be physically connected.
It seems the P SME box takes the packet destined for the 172.20.1.0/25 network and just drops it somewhere instead of forwarding it through the ipsec0 interface. Could this be freeswan eating the the packets because the tunnel was only configured to speak directly to the 172.20.106.0/25 network from the P SME side? I think I'll try to set up a phony local network on the L SME box and see if it even tries to forward to the P SME side through the ipsec0 interface. It should fail when it hits the P SME box, but it should try to get there anyway shouldn't it?
here we go...
OK, tried it and have the same situation with the L box. It won't even forward packets that are not on the network that the ipsec tunnel is configured to see, even though it's added to the local networks panel in server-manager and to the routing table.
If I don't put it in the routing table it tries to go out eth1 instead of ipsec0 and I can get a couple of hops out of it (from my isp I assume) so at least it tries if it's not configured to go out of ipsec0. Seems I need to tweak the freeswan settings if possible to allow the addidional network's traffic to flow through the ipsec tunnel. Do you know if this is a possible solution?
Thanks again,
Sterling
-
I finally figured it out. In reading the Freeswan docs I learned that each ipsec tunnel will pass trafic for its pre-defined networks only so trying to route other traffic through the ipsec tunnel is pointless.
----------------------------------------
From the Freeswan FAQ:
Q: I send packets to the tunnel with route(8) but they vanish
A: IPsec connections are designed to carry only packets travelling between pre-defined connection endpoints. As project technical lead Henry Spencer put it:
"IPsec tunnels are not just virtual wires; they are virtual wires with built-in access controls. Negotiation of an IPsec tunnel includes negotiation of access rights for it, which don't include packets to/from other IP addresses. (The protocols themselves are quite inflexible about this, so there are limits to what we can do about it.)"
----------------------------------------
Therefore I had to add another ipsec tunnel defined as 172.20.160.128/25 <-> 172.20.1.0/25 and add it to my templates-custom area. That allowed the traffic to go via the ipsec0 interface.
Many thanks to Bill for trying to help me troubleshoot this.
-Sterling
-
Sterling,
Good for you, we both learned something today. I know you won't be reading this post soon, since your last post shows 3:45 in the morning ! One thing that still bothers me, how were you able to ping from the 172.20.1.12 host through the ipsec tunnel to the P Lan, but not visa versa ??
BTW,
I like the network diagram you made, what program did you use to design it ??
Bill
-
Sterling,
I really like the way you modified the Lophty indexer. Want to share your mods?
-jeff
-
Jeff, thanks for the compliment. I wish I could remember how I even modified it :) As soon as I get time I will check it out and post it.
Regards,
Sterling
Jeff C wrote:
>
> Sterling,
>
> I really like the way you modified the Lophty indexer. Want
> to share your mods?
>
> -jeff
-
I assume it worked like that was because when pinging from 172.20.1.12 the destination address was 172.20.106.130 which qualified as an allowable destination address on the first tunnel (172.20.160.128/25 <-> 172.20.106.0/25) because it was within the 172.20.160.128/25 network. But when I tried pinging the other way (from 172.20.106.130 to 172.20.1.12) the destination address was 172.20.1.12 which didn't qualify as being part of the two pre-defined tunnel networks and was therefore dropped.
As for the diagram I just used MS Publisher and printed it to my PaperPort 9.0 PDF Printer to make the .pdf file
Sterling
Bill Pflaumer wrote:
>
> Sterling,
> Good for you, we both learned something today. I know you
> won't be reading this post soon, since your last post shows
> 3:45 in the morning ! One thing that still bothers me, how
> were you able to ping from the 172.20.1.12 host through the
> ipsec tunnel to the P Lan, but not visa versa ??
>
> BTW,
> I like the network diagram you made, what program did you use
> to design it ??
>
>
> Bill
-
Here's the link to the lophty indexer I modified:
http://www.abacustechnology.net/files/public/
I think (hope) everything you need is in the tarball there.
Sterling
Jeff C wrote:
>
> Sterling,
>
> I really like the way you modified the Lophty indexer. Want
> to share your mods?
>
> -jeff
-
Thanks Sterling!
-jeff
-
Sterling ,
When you get the problem resolved, can you share a howto with the rest of us ?
Thanks,
Bill
-
As soon as I completely understand what I did to make it work I will try and generate a how-to :)
Regards,
Sterling
Bill Pflaumer wrote:
>
> Sterling ,
> When you get the problem resolved, can you share a howto with
> the rest of us ?
>
> Thanks,
>
> Bill