What's new

Asus RT-AC86U - NAT Loopback / Hairpin not working ?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

cw-kid

Regular Contributor
Hi

I cannot access my IP cameras and some other services hosted on my LAN, by using their WAN IP or Domain address, from within side the LAN.

I have an Asus RT-AC86U router with Merlin Firmware version 384.14_2

If I use their local LAN IP addresses instead I can access them OK.

Any way to fix this ?

Thanks

EDIT: Actually this only seems to be the case when my OpenVPN client is connected on the router.

If I drop the VPN tunnel then I can access those services using either the WAN IP or Domain name address OK.

If my phone is remote only on 4G for example and the routers VPN tunnel is up, I can access the IP cameras OK.

But if the phone is only connected to the routers WIFI and the routers VPN tunnel is up, then I can no longer access the IP cameras.

EDIT 2:

If I exclude an IP camera from the OpenVPN client tunnel using policy rules and then use my Asus routers DDNS domain address to access the camera, it then works both when my phone is only connected to the LAN WIFI or only connected to the 4G mobile data.

So its certainly the VPN connection on the router that it doesn't work with.
 
Last edited:
The reason this is happening is the same reason *any* remote access over the WAN will fail to connect when the target of the port forward is simultaneously using the OpenVPN client; the incoming traffic from the WAN has its outgoing traffic directed to the VPN, which is a violation of the routing rules, specifically reverse path filtering.

Whenever you deal w/ a network interface where connection tracking is active, the routing rules require the incoming and outgoing traffic to use the *same* network interface (normally the WAN). But once the OpenVPN client becomes active, the change in the default gateway to the VPN causes that rule to be violated for any client accessed over the WAN but routed over the VPN, hence remote access over the WAN (even if only simulated via NAT loopback) doesn't work. The packets are simply dropped.

Frankly, you'd have the exact same problem if you were actually remotely accessing those same port forwards over the WAN. It's just you've discovered a secondary fallout of this situation; NAT loopback doesn't work either.

So your *first* problem is NOT w/ NAT loopback. That's just an inconvenience at the moment. You need to correct the more fundamental problem of not being able to access devices over the WAN (i.e., port forwards) to targets that are simultaneously bound to the OpenVPN client.

There are numerous ways to deal w/ the situation. Which makes the most sense will vary from user to user. I explain your options in the following link.


Note, the user in the above link is specifically trying to access their OpenVPN server while simultaneously the home router has an active OpenVPN client, and is NOT using PBR (policy based routing). So in his case, even the router itself is bound to the OpenVPN client, and NOT just those clients on the network behind the router bound to the OpenVPN client thanks to PBR. But the principles are the same. *ANYTHING* bound to the OpenVPN client is unreachable over the WAN unless you take special steps to correct it (as outlined in that link). There may be other ways as well, but those are the most common.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top