Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If the HTTP_X_FORWARDED_FOR header is truly supported, then I think this would not be either forward or reverse proxy server causing this, but more likely Dynamic Network Address Translation or Dynamic Port Address Translation, which is happening below the application layer on the TCP/IP stack and thus would not affect an HTTP request header.</p> <p>There are many ways to configure NAT, most of which would <em>not</em> cause these symptoms, but it is certainly possible to configure NAT in a way that would present this problem. Dynamic NAT or Dynamic PAT would be two such examples, and I would suggest this is what you ask your network administrators.</p> <p>For more on Dynamic NAT/PAT, with good examples, you could review: <a href="http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_dynamic.html" rel="nofollow">http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_dynamic.html</a></p> <p>In a typical NAT scenario, the request packets reach the NAT device (firewall or router) as: FROM - 5.5.5.5 (public address of the client) TO - 6.6.6.6 (the public address of the server)</p> <p>The "typical" NAT configuration would rewrite only the destination, as follows: FROM - 5.5.5.5 TO - 192.168.6.6 (the private address of the server)</p> <p>In this typical case, the server would still see REMOTE_ADDR as 5.5.5.5, as that is the source address on the incoming request. Then, the packets would be returned to 5.5.5.5, and the response would return to the client successfully.</p> <p>Now, in the case of dynamic PAT, for example, the request would reach the NAT device as follows: FROM - 5.5.5.5 TO - 6.6.6.6</p> <p>Then, the NAT device would rewrite <em>both</em> source and destination packets, maintaining this "dynamic" mapping for only the lifetime of the request: FROM - 192.168.1.1:12345 (the dynamic PAT address) TO - 192.168.6.6 (the private address of the server)</p> <p>Now, when the server sees this request, it appears to be from private address 192.168.1.1. In fact, with a strict PAT <em>all</em> requests will appear to be from this address. In your case, there are 2 or 3 of these addresses, probably because you may have enough traffic that you risk running out of ports if you use only a single dynamic PAT address.</p> <p>So, your REMOTE_ADDR is 192.168.1.1, because that is actually the source address on the request packets. There is no HTTP_X_FORWARDED_FOR, because the Dynamic PAT is occurring at a lower TCP/IP layer (address and not application).</p> <p>Finally, the response is sent back to 192.168.1.1:12345, which routs to the NAT device, which for the duration of the request/response (see the Cisco documentation above) maps it back to 5.5.5.5, and then drops the "dynamic" mapping.</p> <p>Everything worked perfectly, the client gets the response back, except that you have no idea of the actual client address from the viewpoint of the server. And if it is dynamic NAT in play, I don't see how you could get this information from the server.</p> <p>Fortunately, you did exactly the right thing to get the information in javascript on the client, so this likely solves your problem as well as it could be solved.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload