Solved Weird destination ip when connecting to a subnet

[matt_e]

I currently have 2 RT-AC68U routers both running Merlin 386.11, and I configured them them to form 2 subnets as follows

ROUTER 1:
Wan ip: Public ip
Lan ip: 192.168.1.1
Subnet mask: 255.255.255.0
Static routing rule: 192.168.2.0/24 via 192.168.1.2

ROUTER 2 (connected to ROUTER 1 lan port)
Wan ip: 192.168.1.2
Lan ip: 192.168.2.1
Subnet mask: 255.255.255.0

Firewall and NAT on ROUTER 2 are disabled using the webgui.
However, I get weird behaviour when trying to ssh a server (192.168.2.2) on the lan of ROUTER 2.

This is wireshark on my laptop monitoring ssh packet:
When my computer is connected to ROUTER 1 wifi (connection fails, dst ip 0.0.0.0):

When my computer is connected to ROUTER 2 wifi (connection success, dst ip is my computer ip):

I have also verified using tcpdump on my server, the outgoing packets originally have dst ip 192.168.1.125 (my client ip), but when they arrive to my computer, they all become 0.0.0.0.

Not just ssh, but same with http (tested using python -m http.server), the recurring phenomenon is that after the first few packets exchange, the destination ip suddenly becomes 0.0.0.0 if my client computer is connected to ROUTER 1 wifi.

Any idea what causes this to happen, and how should I fix it?

 

[drinkingbird]

I currently have 2 RT-AC68U routers both running Merlin 386.11, and I configured them them to form 2 subnets as follows

ROUTER 1:
Wan ip: Public ip
Lan ip: 192.168.1.1
Subnet mask: 255.255.255.0
Static routing rule: 192.168.2.0/24 via 192.168.1.2

ROUTER 2 (connected to ROUTER 1 lan port)
Wan ip: 192.168.1.2
Lan ip: 192.168.2.1
Subnet mask: 255.255.255.0

Firewall and NAT on ROUTER 2 are disabled using the webgui.
However, I get weird behaviour when trying to ssh a server (192.168.2.2) on the lan of ROUTER 2.

This is wireshark on my laptop monitoring ssh packet:
When my computer is connected to ROUTER 1 wifi (connection fails, dst ip 0.0.0.0):
View attachment 52878

When my computer is connected to ROUTER 2 wifi (connection success, dst ip is my computer ip):
View attachment 52879

I have also verified using tcpdump on my server, the outgoing packets originally have dst ip 192.168.1.125 (my client ip), but when they arrive to my computer, they all become 0.0.0.0.

Not just ssh, but same with http (tested using python -m http.server), the recurring phenomenon is that after the first few packets exchange, the destination ip suddenly becomes 0.0.0.0 if my client computer is connected to ROUTER 1 wifi.

Any idea what causes this to happen, and how should I fix it?

If on the server you're seeing a destination IP of 0.0.0.0 in wireshark, there is some issue on the server, packets are making it to it (which means they have the correct destination) then it is changing it to "unreachable".

Without seeing all of the specifics of your situation I'd say the first things to check are to make sure router 1's static route has the "LAN" interface selected, and the server has the correct default gateway of 192.168.2.1 and correct subnet mask. Obviously make sure it has a 192.168.2.x IP also.

Ensure router 2 WAN is connected to router 1 LAN.

Other than that, need to investigate if some firewall or something on the server is blocking it.

 

[matt_e]

Thanks for the advice.

After playing with the settings in ROUTER 2, I figured out disabling Lan -> Switch Control -> NAT Acceleration solves the problem. However, I just don't understand why disabling Wan -> Internet Connection -> Enable NAT isn't enough despite that the iptables looks clean. Anyway, it now works.

 

[drinkingbird]

Thanks for the advice.

After playing with the settings in ROUTER 2, I figured out disabling Lan -> Switch Control -> NAT Acceleration solves the problem. However, I just don't understand why disabling Wan -> Internet Connection -> Enable NAT isn't enough despite that the iptables looks clean. Anyway, it now works.

Not surprising, NAT acceleration changes the way interfaces are mapped and impacts some of the nested iptables rules. It must be impacting something in the TCP header to where the server NIC driver is injecting the unreachable IP when it comes into the NIC.

You do have to disable both to disable NAT completely, at least on the 68U, not sure about others.

Though if you have firewall and NAT disabled with routes to permit full communication, not really sure the point of having two routers and not just AP mode. Unless you have tons of devices.