ER707-M2 router is not using the expect DNS servers?
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?
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @MatvAxxes
MatvAxxes wrote
Let's agree to disagree? I don't consider it expected behavior that whenever I navigate to "service1.mydomain. com" for which I have a local A record pointing to 192.168.30.13, that I go via the WAN interface.
There's a static default route between VLANS with metric 0, so why is traffic not going directly when there's DNS or port forwarding involved?
And why is that, whenever I connect via VPN and I'm in a different vlan (192.168.99.0/24), it does work correctly?
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.
- Copy Link
- Report Inappropriate Content
Hi @MatvAxxes
Thanks for posting in our business forum.
MatvAxxes wrote
Apologies if I come across as obtuse, but this issues has been bugging me for quite some time now.
So, to summarize, from the Wikipedia article:
If a packet is sent to 203.0.113.1 by a computer at 192.168.1.100, the packet would normally be routed to the default gateway (the router)[d] A router with the NAT loopback feature detects that 203.0.113.1 is the address of its WAN interface, and treats the packet as if coming from that interface.
Note that in my case, a packet is not sent to 203.0.113.1 (or 94.x.x.x in my case), but rather to 192.168.30.13, because of DNS.
The default gateway for my client 192.168.10.27, is 192.168.10.1. There's an entry in the routing table stating that 192.168.30.0/24 traffic should exit via the SERVER interface on 192.168.30.1.
Now, I understand that at this point the Omada router performs SNAT to modify my source address of 192.168.10.27 to 94.X.X.X in order to "ensures that both requests and responses pass through the router, avoiding issues that might arise from direct Layer 2 communication."
But routing between vlans CLIENT and SERVER is already happening at layer 3. This is proven by the fact that 1) disable port forwarding makes it work (and I realize that port forwarding is what makes this happen in the first place), 2) disconnecting the WAN port makes it work (probably also disabling port forwarding since there's no more WAN connectivity), and 3) making a VPN connection and ending up in the VPN vlan 192.168.99.0/24 also makes it work (although this might be an edge-case alltogether).
So now that I fully understand what's going on, I guess the bottom line is: Is there a way to disable NAT hairpinning/loopback or SNAT?
Unfortunately, there is no option to list this feature yet. Currently, to avoid any problems with communication, it is enabled by default.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
Hi @MatvAxxes
What does it make anything related to the router?
The OP does not make any sense in relating this to the router.
DNS resolution is a problem in your LAN. Now, the pictures showed me that it only resolved to a private IP address. Not a public.
And the tracert is not a thing about the router.
Both tracert and the traceroute in the controller GUI indicated that this seems to be a problem with your DNS server. DNS A has nothing to do with the router either.
If you have a different opinion, can you show me a mind note in how this relates to the router? I think if we need to troubleshoot this, we need to have a clear mind note before we discuss this as this involves DNS. It seems to be easy but it is a very wild wide topic.
I only see the router play a role in the network but did not touch the DNS resolution. It forwards based on what it resolves.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
That is indeed my WAN IP, and the expected response.
However, I would expect to receive my WAN IP when I peform a traceroute from the WAN interface. But as you can see in the screenshot, I am using an internal interface (USER), which is a LAN, and has private DNS resolvers.
Any client in the USER VLAN is using the correct DNS servers. But the router itself, when performing a ping or traceroute from the USER interface is using public DNS, not the private DNS as specified in the USER VLAN settings.
Is this behavior expected? As it does not seem very intuitive to me.
I'm trying to figure out the exact routing path here, because accessing an INTERNAL resource (which happens to be reachable via WAN as well) is being accessed via the WAN rather than the LAN. Despite my client DNS settings being correct. Not a single one of my internal networks are using the local IP to reach these resources. Except for the OpenVPN profile as mentioned in the second post.
- Copy Link
- Report Inappropriate Content
Hi @MatvAxxes
Thanks for posting in our business forum.
MatvAxxes wrote
That is indeed my WAN IP, and the expected response.
However, I would expect to receive my WAN IP when I peform a traceroute from the WAN interface. But as you can see in the screenshot, I am using an internal interface (USER), which is a LAN, and has private DNS resolvers.
Any client in the USER VLAN is using the correct DNS servers. But the router itself, when performing a ping or traceroute from the USER interface is using public DNS, not the private DNS as specified in the USER VLAN settings.
Is this behavior expected? As it does not seem very intuitive to me.
I'm trying to figure out the exact routing path here, because accessing an INTERNAL resource (which happens to be reachable via WAN as well) is being accessed via the WAN rather than the LAN. Despite my client DNS settings being correct. Not a single one of my internal networks are using the local IP to reach these resources. Except for the OpenVPN profile as mentioned in the second post.
It is expected.
Do you have any other NAT functions enabled?
- Copy Link
- Report Inappropriate Content
I only have port forwarding configured for ports 80 and 443 pointing to the local IP of the server on which NGINX is running.
I'm bashing my head for weeks on this issue now. Every single local server that is being accessed via NPM from within the LAN is arriving from my Public IP address.
Making a VPN connection makes it work. Unplugging my ISP cable makes it work. Why is HTTP(S) traffic seemingly going outside first when the WAN is up, before coming back in?
For all I know it could be an NGINX issue but that doesn´t explain why the path being taken from my LAN client to my LAN server is seemingly coming from outside my network?
Maybe it's not. Maybe the traffic is staying inside and the router is just messing with the HTTPS headers?
Edit: I have just tested by disabling port forwarding... It works now.
So to summarize: When I disable port forwarding, request from my LAN client are arriving on my LAN server from my client's LAN IP.
When I enable port forwarding, requests from my LAN client are arriving on my LAN server from my public WAN IP.
Obviously I need port forwarding enabled, otherwise I can´t access any of my resources from the outside anymore. But I also want them available from inside, but keep the traffic local.
- Copy Link
- Report Inappropriate Content
(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.
- Copy Link
- Report Inappropriate Content
Ok, I did one final test and I can now confirm it's an issue with port forwarding between VLANS. To summarize:
When port forwarding is enabled, accessing the server on IP 192.168.30.13 (VLAN30) via client IP 192.168.10.27 (VLAN10), results in me accessing the server via my WAN IP 84.x.x.x.
When port forwarding is disabled, accessing the server on IP 192.168.30.13 (VLAN30) via client IP 192.168.10.27 (VLAN10), results in me accessing the server via my Client IP 192.168.10.27. The same is achieved when unplugging my ISP cable.
And the test I just did:
When port forwarding is enabled, accessing the server on IP 192.168.30.13 (VLAN30) via a different client IP 192.168.30.14 (VLAN30), results in me accessing the server via my Client IP 192.168.30.14.
So it appears that when you stay within the same VLAN, everything is fine. The moment you cross from one VLAN (10) to another (30), port forwarded causes the traffic to (seemingly) re-enter the netwerk via the WAN IP rather than the LAN IP. This should obviously not be the case, especially considering the router table automatically adds routes between VLANS and they should not pass via the static default route.
- Copy Link
- Report Inappropriate Content
Hi @MatvAxxes
Thanks for posting in our business forum.
MatvAxxes wrote
Ok, I did one final test and I can now confirm it's an issue with port forwarding between VLANS. To summarize:
When port forwarding is enabled, accessing the server on IP 192.168.30.13 (VLAN30) via client IP 192.168.10.27 (VLAN10), results in me accessing the server via my WAN IP 84.x.x.x.
When port forwarding is disabled, accessing the server on IP 192.168.30.13 (VLAN30) via client IP 192.168.10.27 (VLAN10), results in me accessing the server via my Client IP 192.168.10.27. The same is achieved when unplugging my ISP cable.
And the test I just did:
When port forwarding is enabled, accessing the server on IP 192.168.30.13 (VLAN30) via a different client IP 192.168.30.14 (VLAN30), results in me accessing the server via my Client IP 192.168.30.14.
So it appears that when you stay within the same VLAN, everything is fine. The moment you cross from one VLAN (10) to another (30), port forwarded causes the traffic to (seemingly) re-enter the netwerk via the WAN IP rather than the LAN IP. This should obviously not be the case, especially considering the router table automatically adds routes between VLANS and they should not pass via the static default route.
Think this is the reason why.
- Copy Link
- Report Inappropriate Content
I don't see those routes in the routing table:
Nor in the RIP or Static routes on the gateway CLI
But more importantly: How do I make sure my USER traffic is being routed to SERVER without passing through WAN?
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 891
Replies: 18
Voters 0
No one has voted for it yet.