OpenWrt Forum Archive

Topic: LAN to LAN Routing on WRT54G

The content of this topic has been archived on 26 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I previously posted a similar message in the Whiterussian area, but I received no responses and I upgraded to Kamikaze 7.09.  I have two LANs each with their own internet connection -- cable internet and dsl internet each on their own LAN with their own computers.  I want to connect the two LANs so I can share resources between them (i.e. a network printer).  I happened to have a WRT54G around and it seemed like that and OpenWrt would be a good match for what I wanted to do. 

One LAN is 192.168.1.0/24 and the other is 10.1.10.0/24.  The interfaces on the router are 192.168.1.5 and 10.1.10.5 respectively. The router is connected to both LANs and I can ping it from either side.  If example,

$ ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
64 bytes from 192.168.1.5: icmp_seq=0 ttl=64 time=1.05 ms

If I traceroute from the 192.168.1.0 network to the 10.1.10.0 network, the packets seem to go to the default router for the network where the request originates:  For example, from a computer on 192.168.1.0

$ traceroute -n 10.1.10.1
traceroute to 10.1.10.1 (10.1.10.1), 30 hops max, 38 byte packets
 1  192.168.1.1  0.250 ms  0.216 ms  0.202 ms
 2  *
^C

Do I need setup static routes on all my computers or is there something I need to configure (RIP?) that advertises the route to 10.1.10.0 through 192.168.1.5?

If I add a static route for 10.1.10.0 through 192.1.168.5, the packets seem to get to the to the correct router (I see the packet count increasing in iptables), but they don't seem to get forwarded through it.  Here are my iptable rules:

root@OpenWrt:~# iptables -L -v
Chain INPUT (policy ACCEPT 154K packets, 43M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 103 packets, 9476 bytes)
 pkts bytes target     prot opt in     out     source               destination
   96  8832            all  --  br-lan eth0.1  192.168.1.0/24       10.1.10.0/24
    7   644            all  --  eth0.1 br-lan  10.1.10.0/24         192.168.1.0/24

Chain OUTPUT (policy ACCEPT 15260 packets, 4766K bytes)
 pkts bytes target     prot opt in     out     source               destination

seems pretty straightforward but I really have no idea what I am doing -- just feeling my way through it.  Am I missing something here?

For completeness, here are my interfaces:

root@OpenWrt:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr 00:14:BF:0F:8D:4E
          inet addr:192.168.1.5  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:280045 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15187 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16466439 (15.7 MiB)  TX bytes:4978896 (4.7 MiB)

eth0      Link encap:Ethernet  HWaddr 00:14:BF:0F:8D:4E
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:417158 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18047 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:65966334 (62.9 MiB)  TX bytes:5298986 (5.0 MiB)
          Interrupt:4

eth0.0    Link encap:Ethernet  HWaddr 00:14:BF:0F:8D:4E
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:280052 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15187 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:17587019 (16.7 MiB)  TX bytes:5039644 (4.8 MiB)

eth0.1    Link encap:Ethernet  HWaddr 00:14:BF:0F:8D:4E
          inet addr:10.1.10.5  Bcast:10.1.10.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:137116 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2864 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:40871181 (38.9 MiB)  TX bytes:139234 (135.9 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1082 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1082 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:75758 (73.9 KiB)  TX bytes:75758 (73.9 KiB)

and routes

root@OpenWrt:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
10.1.10.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0.1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 br-lan
0.0.0.0         10.1.10.1       0.0.0.0         UG    0      0        0 eth0.1

Thanks for any help.  -- Bud

Just a further note, I tried to enable proxy arp and forwarding on both of my interfaces but I haven't noticed much difference:

echo 1 > /proc/sys/net/ipv4/conf/br-lan/forwarding
echo 1 > /proc/sys/net/ipv4/conf/br-lan/proxy_arp 

echo 1 > /proc/sys/net/ipv4/conf/eth0.1/forwarding
echo 1 > /proc/sys/net/ipv4/conf/eth0.1/proxy_arp

I also tried adding a static route for 10.1.10.0 through 192.168.1.5 to my monowall router (not sure this is the right thing to do) that handles the DSL LAN and that seems to have an effect but packets are still not getting through the router and back.

# ping 10.1.10.1
PING 10.1.10.1 (10.1.10.1) 56(84) bytes of data.
From 192.168.1.1: icmp_seq=0 Redirect Host(New nexthop: 192.168.1.5)
From 192.168.1.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.1.5)

--- 10.1.10.1 ping statistics ---
25 packets transmitted, 0 received, 100% packet loss, time 23996ms

using tcpdump on the openwrt router showed...

09:39:36.100442 arp who-has 192.168.1.1 tell 192.168.1.26
09:39:36.100723 arp who-has 192.168.1.5 tell 192.168.1.1
09:39:36.100895 arp reply 192.168.1.5 is-at 00:14:bf:0f:8d:4e
09:39:36.101098 IP 192.168.1.26 > 10.1.10.1: ICMP echo request, id 64048, seq 0, length 64
09:39:36.101551 arp who-has 192.168.1.5 tell 192.168.1.26
09:39:36.101737 arp reply 192.168.1.5 is-at 00:14:bf:0f:8d:4e
09:39:37.100544 IP 192.168.1.26 > 10.1.10.1: ICMP echo request, id 64048, seq 1, length 64
09:39:38.100315 IP 192.168.1.26 > 10.1.10.1: ICMP echo request, id 64048, seq 2, length 64
09:39:39.100202 IP 192.168.1.26 > 10.1.10.1: ICMP echo request, id 64048, seq 3, length 64
09:39:40.100084 IP 192.168.1.26 > 10.1.10.1: ICMP echo request, id 64048, seq 4, length 64
09:39:41.099981 IP 192.168.1.26 > 10.1.10.1: ICMP echo request, id 64048, seq 5, length 64
09:39:42.099893 IP 192.168.1.26 > 10.1.10.1: ICMP echo request, id 64048, seq 6, length 64
09:39:43.099781 IP 192.168.1.26 > 10.1.10.1: ICMP echo request, id 64048, seq 7, length 64

I know the final solution is going to be something simple.  -- Bud

Do I need setup static routes on all my computers or is there something I need to configure (RIP?) that advertises the route to 10.1.10.0 through 192.168.1.5?

No.  If you have access to the default gateways (192.168.1.1 and 10.1.10.1, I assume), you can add routes there, and they should forward the packets to the OpenWRT box.  Manually adding routes to every client isn't a very good solution.

I also tried adding a static route for 10.1.10.0 through 192.168.1.5 to my monowall router (not sure this is the right thing to do) that handles the DSL LAN and that seems to have an effect but packets are still not getting through the router and back.

This is the right thing to do, but you need a route on the other router to get packets back.  For every ping, there's a pong.

(Last edited by exobyte on 8 Jan 2008, 19:54)

Thanks exobyte!  That did the trick.  I was banging my head against the wall.  Now to cleanup all the little messes I made trying to get it working.

-- Bud

I may have been too quick on the trigger.  I can ping the 10.1.10.0 network from the 192.168.1.0 network but not the other way around.  Any thoughts on how to debug or what to check?  Thanks again.  -- Bud

It seems like packets on the 192.168.1.0 can not find their way back to 10.1.10.0.  I can ping from 192.168.1.0 to 10.1.10.0 though.

Using tcpdump on the 192.168.1.5 interface of the openwrt router, I can see the ICMP echo requests going out to say 192.168.1.1 from the 10.1.10.0 network but there are no ICMP echo replies.  If I ping 192.168.1.1 directly from the openwrt router, I see the replies.  I also tried other addresses to ensure that it wasn't something with 192.168.1.1 with the same results.  I double checked that 192.168.1.1 had a static route for 10.1.10.0:

System: Static routes
Interface        Network         Gateway              Description     
LAN           10.1.10.0/24    192.168.1.5

192.168.1.1 is a monowall router if that makes a difference. 

-- Bud

(Last edited by bbach on 8 Jan 2008, 23:25)

what's tracert/traceroute say when you run it on a 10.1.10.0 machine and ask it to get the route to a 192.168.1.0 machine?

Do you want all traffic on either lan to be visible on the other ? In that case the wrt54g would just be a hub, replicating traffic between two of its 4 lan ports, and its OpenWrt firmware should not interfere with that traffic.

More effective from a congestion/collision point of view is to only send from one lan to the other what really has to go there. I guess that is what you want to achieve. In that case the wrt54g should be routing between the two lans, but you have not defined two lans on the wrt54g.

If you don't want to get too far from the default set-up you could use the wrt's WAN as lanA interface with proto static and its LAN as lanB interface, also proto static.
The radio is bridged to lan but not used and you can disable it.
Give WAN an address on lanA, e.g. 192.168.1.5, and tell lanA's router that the gateway to the 10.1.10.0 net is 192.168.1.5.
Give LAN an address on lanB, e.g.  10.1.10.5, and tell lanB's router that the gateway to the 192.168.1.0 net is 10.1.10.5.
Make sure that the firewall on the wrt is inactive and all traffic between its wan and lan is allowed.
It's the FORWARD chain that is traversed in iptables when traffic is routed that does not originate locally in the wrt. So that should have an accept default policy and no rule, or an ACCEPT anything to anywhere rule before other rules.

(Last edited by doddel on 9 Jan 2008, 14:55)

doddel wrote:

Do you want all traffic on either lan to be visible on the other ? In that case the wrt54g would just be a hub, replicating traffic between two of its 4 lan ports, and its OpenWrt firmware should not interfere with that traffic.

More effective from a congestion/collision point of view is to only send from one lan to the other what really has to go there. I guess that is what you want to achieve. In that case the wrt54g should be routing between the two lans, but you have not defined two lans on the wrt54g.

If you don't want to get too far from the default set-up you could use the wrt's WAN as lanA interface with proto static and its LAN as lanB interface, also proto static.
The radio is bridged to lan but not used and you can disable it.
Give WAN an address on lanA, e.g. 192.168.1.5, and tell lanA's router that the gateway to the 10.1.10.0 net is 192.168.1.5.
Give LAN an address on lanB, e.g.  10.1.10.5, and tell lanB's router that the gateway to the 192.168.1.0 net is 10.1.10.5.
Make sure that the firewall on the wrt is inactive and all traffic between its wan and lan is allowed.
It's the FORWARD chain that is traversed in iptables when traffic is routed that does not originate locally in the wrt. So that should have an accept default policy and no rule, or an ACCEPT anything to anywhere rule before other rules.

Even if it's a hub, it still has to do routing, since the networks are on very different subnets.  Get the routing to work, then make sure you set up two vlans correctly (which is probably the case, since the device has two IP addresses).

I definitely want it to route.  Unfortunately I filled the jffs2 partition and can't seem to recover so I need to deal with that.  Argh!

Ok, back to where I was.  Here is a traceroute from a 10.1.10.x node:

$ /usr/sbin/traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 38 byte packets
 1  10.1.10.5 (10.1.10.5)  1.121 ms  0.906 ms  0.801 ms
 2  * * *
 3  * * *

Notice that if I run tcpdump on the lan interface (192.168.1.5), i do see the echo requests going out, but I don't see a response. 

04:43:36.025864 IP 10.1.10.140 > 192.168.1.1: ICMP echo request, id 60426, seq 1, length 64
04:43:37.021149 IP 10.1.10.140 > 192.168.1.1: ICMP echo request, id 60426, seq 2, length 64
04:43:38.021162 IP 10.1.10.140 > 192.168.1.1: ICMP echo request, id 60426, seq 3, length 64
04:43:39.021161 IP 10.1.10.140 > 192.168.1.1: ICMP echo request, id 60426, seq 4, length 64
04:43:40.021179 IP 10.1.10.140 > 192.168.1.1: ICMP echo request, id 60426, seq 5, length 64

It seems like the packet goes through the router but can't find its way back to the router.

-- Bud

OK.  I figured some of it out.  I noticed in my monowall router's (192.168.1.1) firewall log, the pings from the 10.1.10.0 network were getting blocked.  The default only allowed traffic from the local network not just everything on the local network's interface.  I added a rule to allow traffic from the 10.1.10.0 network and pings started working.

Unfortunately, I'm not out of the woods yet as I still can't get to other nodes on 192.168.1.0 from 10.1.10.0.  My guess is that the static route I have setup in the monowall router only applies to the network and not the interface sort of like the firewall rule.  I guess I need to jump over to the monowall forums unless you have any other ideas.  -- Bud

Does the OpenWRT box have routing rules like this?

iptables -A FORWARD -i $LAN1 -o $LAN2 -j ACCEPT
iptables -A FORWARD -i $LAN2 -o $LAN1 -j ACCEPT

Oh, and if possible, run tcpdump (or other packet dump tool) on a 10.x.x.x box, the OpenWRT box, and a 192.168.1.x box.  It makes tracing these things easier to see where things stop

exobyte, Yes, my iptables looks exactly (almost) like that.

On the monowall forums, I found this post

http://forum.m0n0.ch/index.php/topic,10 … ml#msg3343

Which lead me to turn on Static route filtering / Bypass firewall rules for traffic on the same interface under "System -> Advanced"

I need to do a bit more testing but I think that has fixed it!  Thanks for the help.  -- Bud

(Last edited by bbach on 10 Jan 2008, 05:20)

The discussion might have continued from here.