VR400 static route doesn't work properly

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

VR400 static route doesn't work properly

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
VR400 static route doesn't work properly
VR400 static route doesn't work properly
2020-10-25 14:44:32 - last edited 2020-10-26 07:49:48
Model: Archer VR400  
Hardware Version: V2
Firmware Version: 0.6.0 0.9.1 v0070.0 Build 200713 Beta.34548n


I'm fighting with static routes on this router and I believe it doesn't work properly. I used 2019 firmware (don't remember its number) and upgraded to the latest one but still same result.


Problem is as follows - I have following setup:    --------|------ router ----- VR400 ( ------ [DSL] ------ internet|                                                       ||                                                    rPI (


VR400 connects via LAN cable couple of devices including raspberry PI (rPI). 

I have static routes on the VR400 to the networks behind  configured in VR400 via, interface LAN. All looks fine, there is no possibility for other complext configuration.


Symptoms (supported by tcpdump traces on rPI and my .1.30 router):

- when I do ping from raspberryPI to my network device, it passes through. MAC address of source is rPI, dest MAC address is MAC address of LAN interface of my VR400. Then it sends it where needed and then communications flies between IP and MAC address of my .1.30 router and rPI

- when however I initiate communication from my then request comes into rPI (with source MAC of .1.30) and dest of rPI, then rPI responds with MAC address of VR400 (as it does have as default gw) and then VR400 doesn't know what to do with it. I don't see anything in tcpdump coming into my router (seems not leaving VR400) but certainly rPI responds (and then retries). Since there is very limited logging on VR400, neither tcpdump or similar I don't know what happens.


the only solution to fix it with VR400 is either use SNAT on my .1.30 router to rewrite all communication to .1.30 address or add static route on rPI (which doesn't make sense as I have multiple devices in my network and don't want to put it everywhere). In my opinin it is a bug. I will be happy to send tcpdump traces if needed. Definitely it's something with VR400 as I had another device there for some time and all worked properly.

Cable for the LAN connection is in LAN/WAN port (and I don't want to change it as it's the only port with 1Gbps speed). 


Please help or tell me where I can fill in bug against this firmware

2 Reply
Re:VR400 static route doesn't work properly
2020-10-29 09:42:17


Hey,  I always like finding interesting post on this community and learn new stuff.

Bump, I see your post.

There is not so much detailed instruction of static routing the DSL modem and I find one useful FAQ here, not about the instruction, but the whole network diagram which is quite like yours, am I right?


While I was quite ignorance about the SNAT things that you mentioned on the post.

Forgive me if I am stupid, if you want to initiate communication from then request comes into rPI, I supposed that you need to open the ports on the router first, then configure the static routes on the router as well, such as destination IP, gateway


A very curious user!cool


Re:VR400 static route doesn't work properly
2020-10-29 10:07:39 - last edited 2020-10-29 10:08:43

@Lawrence-C It is all there. The problem is not about target gw not accepting it but about VR400 not being able to send the packets further down to LAN when directed to it's MAC address in response to ping. Interestingly it can forward it properly if the connection is initiated from a device directly connected to its ports. In other words:

- it knows how to forward e.g. ICMP request

- it doesn't know how to forward ICMP response


other router put in that place works perfectly, this is undoubtedly bug in VR400 static routing behaviour. It is exactly the same behaviour as described here:




Helpful: 2

Views: 421

Replies: 2

Related Articles