2

On a simple network, my nginx logs will the gateway address (10.0.0.1) instead of the internal client address (10.0.0.19) when I'm using DNS (e.g. foo.com) to access a server inside the LAN.

I'm trying to read more on this, but I don't know what it's called. Is there a term for "the router noticed you were trying to reach outside the network, to a resource inside the network, and replaced your IP address with the gateway address"? If this is just a standard thing, are there any articles where I can read more? I don't quite understand why this is happening, but it feels like a router "feature" I don't know the name of.

As a side effect of the FROM address being the gateway, replies go to the router (then back to the local client) instead of just using the switch. This isn't great because the LAN switch has much higher throughput than the router due to the router running firewalling features.

This is a fairly simple network setup:


WAN - (70.x)Router(10.0.0.1) - Switch - (10.0.0.3)  Server
                                      - (10.0.0.19) Client

On a computer inside the lan (Client 10.0.0.19) I make a request to foo.com. The DNS for foo.com points to the WAN interface on the Router, which has a port forward setup to Server. nginx inside the server shows the request as coming from 10.0.0.1 instead of 10.0.0.19.

If the request originates from the WAN, then the nginx logs show the expected data.

If it's relevant, the router is a ubiquiti USG with a ubiquiti switch behind.

2

"the router noticed you were trying to reach outside the network, to a resource inside the network, and replaced your IP address with the gateway address"?

That is a NAT (Network Address Translation) variant called NAPT (Network Address Port Translation). Some people call it PAT (Port Address Translation) because a large vendor calls it that, But RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations explains it. When you want it to loopback inside, that is called various things, depending on the vendor (hairpin routing, NAT reflection, etc.), and it is very wasteful of router resources.

There are various resources, including RFCs. For example, RFC 3022, Traditional IP Network Address Translator (Traditional NAT) has Section 2.2. Overview of NAPT:

2.2. Overview of NAPT

Say, an organization has a private IP network and a WAN link to a service provider. The private network's stub router is assigned a globally valid address on the WAN link and the remaining nodes in the organization have IP addresses that have only local significance. In such a case, nodes on the private network could be allowed simultaneous access to the external network, using the single registered IP address with the aid of NAPT. NAPT would allow mapping of tuples of the type (local IP addresses, local TU port number) to tuples of the type (registered IP address, assigned TU port number).

This model fits the requirements of most Small Office Home Office (SOHO) groups to access external network using a single service provider assigned IP address. This model could be extended to allow inbound access by statically mapping a local node per each service TU port of the registered IP address.

In the example of figure 3 below, stub A internally uses class A address block 10.0.0.0/8. The stub router's WAN interface is assigned an IP address 138.76.28.4 by the service provider.

                                 \ | /
                               +-----------------------+
                               |Service Provider Router|
                               +-----------------------+
                             WAN |
                                 |
             Stub A .............|....
                                 |
     ^{s=138.76.28.4,sport=1024, |  v{s=138.76.29.7, sport = 23,
     ^ d=138.76.29.7,dport=23}   |  v d=138.76.28.4, dport = 1024}
                     +------------------+
                     |Stub Router w/NAPT|
                     +------------------+
                       |
                       |  LAN
 --------------------------------------------
    |        ^{s=10.0.0.10,sport=3017, |  v{s=138.76.29.7, sport=23,
    |        ^ d=138.76.29.7,dport=23} |  v d=10.0.0.10, dport=3017}
    |                                  |
   +--+      +--+                    +--+
   |--|      |--|                    |--|
  /____\    /____\                  /____\
 10.0.0.1  10.0.0.2   .....        10.0.0.10

  Figure 3: Network Address Port Translation (NAPT) Operation

When stub A host 10.0.0.10 sends a telnet packet to host 138.76.29.7, it uses the globally unique address 138.76.29.7 as destination, and sends the packet to it's primary router. The stub router has a static route for the subnet 138.76.0.0/16 so the packet is forwarded to the WAN-link. However, NAPT translates the tuple of source address 10.0.0.10 and source TCP port 3017 in the IP and TCP headers into the globally unique 138.76.28.4 and a uniquely assigned TCP port, say 1024, before the packet is forwarded. Packets on the return path go through similar address and TCP port translations for the target IP address and target TCP port. Once again, notice that this requires no changes to hosts or routers. The translation is completely transparent.

In this setup, only TCP/UDP sessions are allowed and must originate from the local network. However, there are services such as DNS that demand inbound access. There may be other services for which an organization wishes to allow inbound session access. It is possible to statically configure a well known TU port service [RFC 1700] on the stub router to be directed to a specific node in the private network.

In addition to TCP/UDP sessions, ICMP messages, with the exception of REDIRECT message type may also be monitored by NAPT router. ICMP query type packets are translated similar to that of TCP/UDP packets, in that the identifier field in ICMP message header will be uniquely mapped to a query identifier of the registered IP address. The identifier field in ICMP query messages is set by Query sender and returned unchanged in response message from the Query responder. So, the tuple of (Local IP address, local ICMP query identifier) is mapped to a tuple of (registered IP address, assigned ICMP query Identifier) by the NAPT router to uniquely identify ICMP queries of all types from any of the local hosts. Modifications to ICMP error messages are discussed in a later section, as that involves modifications to ICMP payload as well as the IP and ICMP headers.

In NAPT setup, where the registered IP address is the same as the IP address of the stub router WAN interface, the router has to be sure to make distinction between TCP, UDP or ICMP query sessions originated from itself versus those originated from the nodes on local network. All inbound sessions (including TCP, UDP and ICMP query sessions) are assumed to be directed to the NAT router as the end node, unless the target service port is statically mapped to a different node in the local network.

Sessions other than TCP, UDP and ICMP query type are simply not permitted from local nodes, serviced by a NAPT router.

The proper way is to use something like split DNS so that your internal traffic never enters the router, so that you do not waste the LAN interface bandwidth (in both directions), and you do not use router CPU and RAM for traffic that should never leave your network.

| improve this answer | |
  • Oh man, thanks much – Hamy Nov 7 '19 at 0:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.