ER707-M2 router is not using the expect DNS servers?
I am troubleshooting a strange issue where whenever I try to access a local domain I end up going through my WAN IP instead of my LAN IP. Despite having that domain name as an A record on my local DNS servers. The domain has a public A record as well, and is reachable over the internet.
When using Tools > Network Check, I can indeed confirm that the Router does not appear to be using the correct DNS servers.
Example:
On my local computer, I can do a ping, dig, nslookup, or traceroute to the domain name.
As you can see, it is correctly resolving to a LAN IP 192.168.68.3. My default gateway is indeed 192.168.10.1.
However, looking at the access log from nginx, I can see that I am accessing this host via web browser not via my LAN IP, but rather via my WAN IP 94.1****
My web browser is NOT configured to use DOH or DOT and is using my local DNS. This also can be reproduced by various other browser and devices, ruling out a local configuration problem.
When using the Network Check tool on one of my EAPs, You can see that it gets correctly resolved to the LAN IP:
However, when I test this on my Gateway:
Even when using a local VLAN INTERFACE, I am ending up on my public IP address rather than my LAN IP address.
Is this expected behavior? And if so: What else could cause my HTTP requests going outside to my WAN rather than staying in my LAN?
Hi @MatvAxxes
As you are an expert on the NAT loopback in the previous conversation you said you understand how NAT loopback works. I think some explanation would enlight you.
NAT Loopback allows devices within the same local network to access other devices in the same network using the external (WAN) IP address. It does not affect DNS resolution results. NAT loopback is handled by the NAT rules on the router or firewall and operates separately from DNS resolution. Its purpose is to handle situations where internal devices use a public IP address to access internal services, ensuring proper handling of requests and responses.
Why does it ignore your DNS A record?
And we apply the SNAT in this case.
SNAT (Source Network Address Translation) modifies the source IP address of outgoing packets. In the context of NAT loopback, SNAT typically changes the source address of internal devices to the router's external IP address (WAN IP). This ensures that when the server responds, the traffic is sent back to the router, rather than directly back to the internal device. This setup ensures that both requests and responses pass through the router, avoiding issues that might arise from direct Layer 2 communication.
And we applied the SNAT in this situation.
In essence, when you use the router to traceroute that domain, it will automatically trigger the NAT loopback. That's how it is designed to be.
As for your computer and EAP, they have a local DNS server and DNS A record and it would simplify this into an inter-VLAN connection. However, this does not apply to the router itself as it triggers the NAT loopback.
And here's something interesting:
Whenever I make a VPN connection... It works!
OpenVPN gives me an IP 192.168.99.6, which is indeed showing up in the nginx access log when navigating to the site:
This smells like a routing issue... But only for HTTP(S) traffic? Considering ICMP (ping, traceroute) works perfectly fine. I don't have any manual Static or Policy routing configured.
Hi @MatvAxxes
MatvAxxes wrote
However, when I test this on my Gateway:
Even when using a local VLAN INTERFACE, I am ending up on my public IP address rather than my LAN IP address.
Is this expected behavior? And if so: What else could cause my HTTP requests going outside to my WAN rather than staying in my LAN?
What's the WAN DNS? It looks right to me as well.
The WAN interface will directly forward this to the DNS server and query the nameserver IP. The WAN does not query the local DNS server because NAT. Huh, you might wanna think about the WAN and LAN interface differences?
It reports a public IP address which is good to me.
(Local server IP has been changed from 192.168.68.3 to 192.168.30.13 since the original message)
Could the problem be that Source IP is 0.0.0.0/0? RFC1918 addresses should be excluded here.
Which is kind of implied considering the WAN Interface, but as stated above even local traffic being port forwarded (which it shouldn´t) is seemingly coming in from the WAN.
