Hi @MatvAxxes

MatvAxxes wrote

  @Clive_A 

 

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.

Hi @MatvAxxes 

Thanks for posting in our business forum.

MatvAxxes wrote

  @Clive_A 

 

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.