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
Thanks for posting in our business forum.
MatvAxxes wrote
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?
I double-confirmed your situation again with the test team. This is the NAT loopback. Fit what I thought at first.
I reconsidered my last reply and I think it is not highly related to the issue.
- Copy Link
- Report Inappropriate Content
So what could be a possible solution to the problem? Reminder that I do have a local DNS which correctly points all A records to my local NGINX server, and a dig command confirms works for all my clients.
- Copy Link
- Report Inappropriate Content
Hi @MatvAxxes
Thanks for posting in our business forum.
The system is working as expected which means we don't have a solution for this.
- Copy Link
- Report Inappropriate Content
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?
- Copy Link
- 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
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?
- 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
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1030
Replies: 18
Voters 0
No one has voted for it yet.