Incoming Static Route issue

[Dixit]

I have this very weird problem, and its been racking my brain. Let me try to explain this the best I can.

I have two houses, about 650feet apart. HouseA is on the 192.168.0.x/24 network. HouseB is on the 192.168.1.x/24 network. They are connected to each other with the use of a pair of Mikrotik SXT AC wireless antennas. We get about 250-300Mbps between the two.

So HouseA has a SXT that has say a 192.168.0.50 address, HouseB has an SXT that has a 192.168.1.50. I have a Netgear R7000 at HouseA and it has a static route configured for destination of 192.168.1.0/24 to go to the gateway of 192.168.0.50 (The local SXT). So basically it sends the data to its local SXT which is just bridges to the other SXT, so essentially it gets the packet headed for HouseB and then sends to the final destination. And same in reverse HouseB has the Asus AC66R, has a static route for 192.168.0.0/24 going to the gateway of 192.168.1.50 (its local SXT).

Now anything can be pinged or connected from HouseB to HouseA, no issues. Again anything on the 1.x network has no issues pinging, connecting, talking to the 0.x network. So this is going from technically the AC66R to the R7000 side, so the static route there is clearly setup right.

Issue seems to be the other way, HouseA to B has random issues connecting. Some IPs are pingable some are not. Which makes no sense as the route is setup to accept anything that is destined to the 192.168.1.x/24 network to be send there. I can ping say random PCs on the other side, even wifi thermostats. But cannot ping say a server on the other side. Ive run packet traces on the SXT (RouterOS allows you to see it). And Im definitely seeing the pings from A to B houses, but B side never replies. So its being sent technically to the AC66R. I test ones where it does respond, say a Wifi thermostat on the HouseB side, it replies just fine and see the packet sniff on the SXT.

Here is where it gets interesting. If I simply set the AC66R to a LAN subnet to say a /23 (255.255.254.0) then it all works. But then you are sort of bypassing the route (I think). All this worked just fine with standard /24 on each side and static routes when I had an R7000 (which is on A house) and an old Linksys E2000 on the B house, but that died.

Anyway to see live packets or packet sniffing on the AC66R? I need to see if its getting them and randomly deciding not to forward it to the PC/Server or what. I just don't get why some IPs go through. Rebooting all 4 devices (routers on both sides, and SXTs on both sides) doesn't solve anything.

Any suggestions? Sorry for the long post, only way to clearly explain it.

Dixit

 

[Dixit]

Here is some more info that seems to somewhat narrow it down some more. I feel the entire R7000 static route side is fine. Here is why.

Example:
HouseA PC, 192.168.0.123 (in this example) pings 192.168.1.10 (server on HouseB side). I ran a Wireshark on the HouseB server I was pinging. Ran the ping. Im actually seeing the Ping request AND reply in the wireshark, showing clearly 192.168.1.10 replied back to 192.168.0.123. However on the 192.168.0.123 PC, it never shows any replies, shows them all as request timed out.

So seems like the AC66R is sending the packets through to the end device, but not sending the reply back to the HouseA side, doesn't make sense why it would do that, especially when other devices say a thermostat on HouseB like 192.168.1.20 can be pinged, and you will receive a reply back.

Anyway to see say a live capture on the AC66R side to see in that example above that it send/fwded the packet to the server, but I want to see why it decided to drop that reply back from the server to the HouseA PC.

Dixit

 

[Dixit]

Sorry for more replies, but just digging more into this. Just out of curiosity, I decided to ping from 192.168.1.10 to 192.168.0.123 (basically in reverse of post 2 example), it pinged and replied fine. While it was pinging I decided to try the ping example again from post 2, so from 0.123 to 1.10. It started receiving REPLIES, but after 2 replies it starts failing. So it seems like by me pinging from B to A on the same device, its like it opens a temporary allow for an A to B ping, that temporary window seems to be like 5-10secs. But after trying it about 10 times, it seems to have blocked it now and doesn't seem to work anymore.

This is one weird issue Ive seen.

Dixit

 

[john9527]

See this thread....
http://www.snbforums.com/posts/178985/

To test if this is the problem....telnet/ssh to the AC66R and delete the INVALID rule.
iptables -D FORWARD -m state --state INVALID -j DROP

 

[Dixit]

I believe that cmd you gave me fixed it. I attempted to ping the 192.168.1.10 from the HouseA side, failed as usual. Issued that cmd via SSH on the Asus AC66R. Redid the ping, and it works. Can seem to ping all my devices on the HouseB side.

I don't fully understand that thread (sorry this is where my networking skills are not great when we start talking about the IPtables and forward, drop, invalid states). Do I have to put this command in a startup script now? Or is it permanently in there as long as I don't reset to defaults?

What example is the problem on this that that cmd fixed it? Is this a bug in the firmware because this same issue happened even with the stock firmware.

Dixit

 

[Dixit]

I googled this and seems like this is a standard rule for Linux based firewalls (I believe based on my googling) and this is basically dropping INVALID packets because the firewall thinks its a device spoofing. The cmd above was deleting rule. So some believe its not an issue but some do. I find it interesting that the DDWRT based Linksys E2000 that I had on there before the Asus AC66R replaced it didn't have this issue, its a Linux based router so I would assume they would have that rule, but then again that community probably thought the rule is not good and by default don't use it.

And from reading I need to put this in a script for a startup because if the router reboots it will put the rule back.

Do I have all that right?

Dixit

 

[john9527]

So some believe its not an issue but some do. I find it interesting that the DDWRT based Linksys E2000 that I had on there before the Asus AC66R replaced it didn't have this issue

As Merlin indicated in the thread I referenced, there apparently was a lot of discussion on this a while back. I'm not sure which side of the argument DD-WRT ended up on or if there are other code factors which could influence the results (kernel level for example).

And from reading I need to put this in a script for a startup because if the router reboots it will put the rule back.
Do I have all that right?

Right on needing to put it in a script running at startup. I'd grab the script posted by coldwizard in the first post in the thread I referenced and copy that to /jffs/scripts as 'firewall-start'. His script finds the INVALID rule and changes it to just be active on the WAN port, so it stays in place for the internet side of things. You can find instructions on setting up scripts in either the README included with Merlin's code download or the asuswrt-merlin wiki on github.

EDIT: I'm assuming you are running Merlin's release with the above. As an FYI, I've implemented the change from the referenced thread as a firewall option in my latest fork release (Update-11 or later).

 

[Dixit]

Thank you john9527, appreciate it. That script worked as well, Im running the latest Merlin release 378.53. I used the script from post 1.

Dixit