Question
A private server (10.0.0.11) in account A accesses a private web server (10.0.0.22) in account B through a public NAT and a public ALB. Is there a way to check the client IP (10.0.0.11) on the private web server (10.0.0.22) in account B?
When checking on the web server based on Tomcat using "request.getHeader("X-Forwarded-For")", the NAT IP appears. Is there a setting in NAT that prevents the internal client IP from being visible when outgoing?
Answer
When going out through NAT, the original source instance IP is replaced by the NAT IP. This is due to the working principle of NAT, so once it passes through NAT, the IP is changed, making it difficult to see the source instance IP after NAT.
However, if verification is needed, it is possible through VPC flow logs.
Also, since NAT operates at layer 4, application-level information is not included. Therefore, if you want to check the source instance IP at the destination web server using the x-forwarded-for header, it may be possible by manually adding it from the source instance from the beginning.
For example, when sending a command like curl -H "X-Forwarded-For: 1.1.1.1" your.alb.domain, you can check the packet with tcpdump on the destination instance and see the following X-Forwarded-For values in the header.
When using append mode > X-Forwarded-For: 1.1.1.1, your.alb.domain node IP
When using preserve mode > X-Forwarded-For: 1.1.1.1
When using remove mode > X-Forwarded-For header does not appear
If you want to add the X-Forwarded-For header to all https(s) communications to the destination instance by configuring it within the source instance itself rather than using the above method, you need to configure it directly according to your system setup.