Or am I guessing wrong here? You've left out the details of the cosmos setup, so I'm trying to infer them from what you did say.
If this is right, I see two possible problems with what you've done.
First, the routing table on the Bering router says that 172.25.0.0/16 is a netwotrk *locally* available to eth0. I *think* you want it to say that 192.1.1.d (the cosmos' router's LAN address) is its route to 172.25.0.0/16. The approach you're taking will work only if the cosmos is doing something fancy like proxy-arp'ing the 172.25.0.0/16 addresses on the LAN.
Second, since 172.25.0.0/16 is a private-range network (isn't it? I don't use the Class-B private block much), the RFC1918 filtering in Bering/Shorewall will block (DENY, I think) packets to those destinations. You don't say if you've turned off this filtering.
It iss also just barely possible that your NAT'ing is causing a problem. Since you don't describe that part of your setup, I can note it as a (remote, I think) possibility but not suggest details.
Another option is to set up your hosts to use the cosmos directly. In their routing tables, install an entry telling them that 192.1.1.d (the cosmos' LAN IP address) is their route to network 172.25.0.0/16 . Since you don't describe the clients, I can't even begin to suggest the details of how to do it, but this approach would bypass the LEAF router (for this specfic traffic) completely.
A final option is to implement an icmp redirect on the Bering router, so it tells clients to use 192.1.1.d as their route to 172.25.0.0/16, without your having to update the routing tables by hand. I've never implemented one of these, though., and I don't even know if the Linux kernel can do it. icmp redirects also raise some security problems, so I don't know how widely this approach is used these days.
At 05:04 PM 5/30/2003 +0100, Pete Jewell wrote:
Hi
I'm banging my head against a brick wall trying to work out why some simple routes I have setup on our newly installed uClib-Bering system aren't working. I'm hoping that someone will be able to point me in the right direction, based on the details I lay out here.
We have a very simple network setup. One subnet 192.1.1.0 (yeah, I know it should be 192.168 but it was setup before I arrived). Two systems on this subnet can make connections to the outside world. The Bering system, which provides a firewalled internet connection via ppp over isdn (connected via serial port), and our support system (called cosmos) which is used to connect to our customer's networks as required (using ppp and dialback to hook up to a M$ system running RAS).
Everything used to work fine when we just had the one box (cosmos) handling both the network connections to customers, and our connection to the internet. I decided to split out the internet connection to make use of a better firewalling system (shorewall) over our variously edited ipchains script.
Consequently I changed the default gateway on all the PC's here to point at the Bering box, instead of cosmos as they had done before. Internet connection still works fine. However, I've been unable to come up with the magic required to persuade the Bering box to forward on packets for our customers networks onto cosmos.
Here's some config details from the Bering box -
# ip addr show 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:02:b3:a1:38:ef brd ff:ff:ff:ff:ff:ff inet 192.1.1.254/24 brd 192.1.1.255 scope global eth0 4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 3 link/ppp inet 194.153.10.200 peer 194.153.0.46/32 scope global ppp0 5: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 3 link/ppp
# ip route show 194.153.0.46 dev ppp0 proto kernel scope link src 194.153.10.200 192.1.1.230 dev eth0 proto static scope host 192.1.1.0/24 dev eth0 proto kernel scope link src 192.1.1.254 172.25.0.0/16 via 192.1.1.230 dev eth0 proto static default via 194.153.0.46 dev ppp0
# lines from /etc/network/interfaces auto lo iface lo inet loopback
auto ppp0 iface ppp0 inet ppp provider provider
auto eth0 iface eth0 inet static address 192.1.1.254 masklen 24 broadcast 192.1.1.255
up ip route add 192.1.1.230 dev eth0 proto static scope host || true up ip route add 172.25.0.0/16 via 192.1.1.230 proto static || true
Here's the routing table on cosmos when the link is up to a customer who's network is 172.25.0.0/16 -
[EMAIL PROTECTED] /root]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.1.1.254 * 255.255.255.255 UH 0 0 0 eth0 172.25.150.71 * 255.255.255.255 UH 0 0 0 ppp0 192.1.1.230 * 255.255.255.255 UH 0 0 0 eth0 192.1.1.210 * 255.255.255.255 UH 0 0 0 eth0 192.1.1.0 * 255.255.255.0 U 0 0 0 eth0 172.25.0.0 172.25.150.71 255.255.0.0 UG 0 0 0 ppp0 172.16.0.0 192.1.1.210 255.255.0.0 UG 0 0 0 eth0 10.136.0.0 192.1.1.210 255.255.0.0 UG 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 192.1.1.254 0.0.0.0 UG 0 0 0 eth0
And here's the output of a traceroute run on cosmos to prove that from cosmos I can find a route to a particular box on the customers network -
[EMAIL PROTECTED] /root]# traceroute 172.25.150.70 traceroute to 172.25.150.70 (172.25.150.70), 30 hops max, 40 byte packets 1 172.25.151.252 (172.25.151.252) 158.992 ms 158.315 ms 159.864 ms 2 172.25.150.70 (172.25.150.70) 159.834 ms 158.860 ms 149.907 ms
However, if I run the same traceroute command from another machine on the network which has it's default gateway as the Bering box, this is what I get - (the Bering box is called 'firewall' - imaginative no?)
[EMAIL PROTECTED] /root]# traceroute uvdirector traceroute to uvdirector (172.25.150.70), 30 hops max, 38 byte packets 1 firewall (192.1.1.254) 0.627 ms 0.427 ms 0.448 ms
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
