Routing traffic between WAN (static address) and LAN

Hi Guys,

I'm running 2 Asus routers with OpenWRT 22.03.3 in my home network. The topography is shown below:

Router AX53U connects to ADSL model and provides LAN/Wifi access. All Wifi clients connect to this router, as also do a few wired devices. Router N18U connects to AX53U through UTP cable, and offers connectivity to a few more wired devices (for instance, Desktop Linux).

N18U's WAN port is connected to a 8-port switch, and belongs to a different network. In the picture you can see all the address ranges. My plan is to user N18U as gateway between networks 10.250.131.0/26 and 10.250.50.0/27, and as a switch in network 10.250.131.0/26.

Asus RT-N18U Wifi and OpenWRT are not compatible. It means that this route wouldn't provide Wifi connectivity when running OpenWRT. It's perfectly fine for me as I don't want to have another station providing Wifi for network 10.250.131.0/26.

The things is, when I connect from the Desktop Linux to the Raspberry PI 2, I see traffic in RT-AX53U. The following command is executed in a SSH session in AX53U, in order to capture the traffic:

# tcpdump -i br-lan host 10.250.50.10

This is a sample output:

14:22:58.352229 IP 10.250.131.2.56080 > 10.250.50.10.22: Flags [.], ack 7622, win 501, options [nop,nop,TS val 496723701 ecr 96001750], length 0
14:22:58.352352 IP 10.250.131.2.56080 > 10.250.50.10.22: Flags [.], ack 7622, win 501, options [nop,nop,TS val 496723701 ecr 96001750], length 0

Please observe that only packets from 10.250.131.1 to 10.250.50.10 are shown. On the other hand, when I try to connect from Laptop to Raspberry PI 2, I can see bi-direction traffic between both nodes (the same tcpdump command as shown above are used for capturing traffic):

17:00:06.868496 IP 10.250.131.15.62061 > 10.250.50.10.22: Flags [F.], seq 3210, ack 6797, win 2048, options [nop,nop,TS val 1625453265 ecr 1727385969], length 0
17:00:06.868600 IP 10.250.131.15.62061 > 10.250.50.10.22: Flags [F.], seq 3210, ack 6797, win 2048, options [nop,nop,TS val 1625453265 ecr 1727385969], length 0
17:00:06.879843 IP 10.250.50.10.22 > 10.250.131.15.62061: Flags [.], ack 3210, win 501, options [nop,nop,TS val 1727385977 ecr 1625453263], length 0
17:00:06.883314 IP 10.250.50.10.22 > 10.250.131.15.62061: Flags [F.], seq 6797, ack 3211, win 501, options [nop,nop,TS val 1727385985 ecr 1625453265], length 0

In the first case I wouldn't expect no traffic being capture in AX53U, given that N18U would be sending traffic directly to the WAN port. In the second case everything is fine because for reaching Raspberry PI 2, Laptop's traffic really must goes through AX53U.

Did you detect some misconfiguration here?

Thanks!

Thanks.

The output is a little bit different (given the flags passed to tcpdump). Actually, I didn't mention in the original post, but at the beginning I was not filtering by interface. I used -i any, and after some debugging I could realized that traffic is being captured passing through interface br-lan. Then, I decided to filter by interface.

18:39:25.163958  In 2c:4d:54:52:6e:2a ethertype IPv4 (0x0800), length 112: (tos 0x48, ttl 64, id 15723, offset 0, flags [DF], proto TCP (6), length 96)
    10.250.131.2.52246 > 10.250.50.10.22: Flags [P.], cksum 0xef29 (correct), seq 2064022686:2064022730, ack 3590911492, win 501, options [nop,nop,TS val 512110520 ecr 111377901], length 44
18:39:25.163997  In 2c:4d:54:52:6e:2a ethertype IPv4 (0x0800), length 112: (tos 0x48, ttl 64, id 15723, offset 0, flags [DF], proto TCP (6), length 96)
    10.250.131.2.52246 > 10.250.50.10.22: Flags [P.], cksum 0xef29 (correct), seq 0:44, ack 1, win 501, options [nop,nop,TS val 512110520 ecr 111377901], length 44

Once again, only traffic from 10.250.131.2 to 10.250.50.10 is captured. Maybe I was not so clear in the previous post. Seeing only traffic in one way makes me think that the router RT-N18U is sending traffic both to 10.250.50.10 (through the WAN port, as expected), and to the router AX53U. Returning traffic from 10.250.50.10 to 10.250.131.2 is not seen (also, as expected) in AX53U because this router is not connected directly to the network 10.250.50.0/27.

What I would expected is to not see such traffic at all in AX53U. In this case, router N18U would send all the traffic sent to 10.250.50.10 only to this node.

I thought that maybe I had a mistake in the routing tables or routing IPv4 rules. I have not added static routes, neither created IPv4 rules. Here is the current routes set in the router N18U:

# ip route show
default via 10.250.131.1 dev br-lan 
10.250.50.0/27 dev wan scope link  src 10.250.50.1 
10.250.131.0/26 dev br-lan scope link  src 10.250.131.8 
1 Like

I know that. I completely agree with you. My apologies if the comment "this router is not connected directly to the network 10.250.50.0/27" was not that clear, regarding the broadcast domain.

1 Like

This is probably a bit more complicated, assuming that R1/R2 are your upstream/downstream routers:

  • SSH requests/replies from/to the laptop need to pass through both R1 and R2 where they can be captured.
  • SSH requests from the desktop are targeting a host in a different subnet and thus should be sent to its default gateway R1 which is apparently using ICMP redirect to advise the desktop to send its requests directly to the R2 that is in the same subnet and holds the target route.
  • SSH replies to the desktop can reach it directly from the R2 since its MAC is mapped to a specific port on the built-in switch of the R2.

I agree with you in all 3 points. All of them together explains the behaviour I'm experiencing.

Before using the current network topography, the very same Desktop Linux machine was working as gateway for the network 10.250.50.0/27, instead of router N18U. In this case, connections from the Desktop machine to the Raspberry PI 2 (10.250.50.10) weren't captured by router AX53U; and it's perfect, given that both machines were in the same network.

I'm still researching a little bit more about this situation. Maybe everything is fine, and there's no problem. I'll try to explore more about the routing tables.

1 Like

I will mark this reply as the solution, given that it brings a complete explanation of what is happening. Thanks.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.