單純的簡易型防火牆, 如果只開 Port Forwarding 功能, 是不會造成個問題的.

比較麻煩的是, 如果這台防火牆, 並不只是一台單純的 Layer 4 Stateful 網路防火牆, 他其實又兼任 Layer 7 的 HTTP Contenet Filter 或者 SSL Offloader 工作; 又或者它其實就是一台 L7 的 WAF 內容防火牆 (或者負載平衡器: Load Balancer) 的話, 那麼他就真的可能會將 Client 的 IP 換掉, 因為他自己需要擔任 Reverse Proxy 的角色, 才能拆開 HTTP 封包來檢查內容.

在這種狀況下(如上述, 不只是單純的 L4 防火牆功能), 當他檢查完畢, 要把封包往後送的時候, 發送出來的, 一定會是他自己的 IP (而不是 Port forwrad 進來的 IP), 所以如果後端的 Web Server (Nginx) 沒有另做特別處理, 就會變成誤以為防火牆 IP 就是 Client IP.

不過, 通常如果防火牆本身兼任 Reverse Proxy 角色的話, 他應該會同步向後端送出 X-Forwarded-for 或者 X-Real-IP 的 HTTP Header, 只要後端 Web Server 能夠解讀這個 HTTP Header, 就可以紀錄正確的 Client IP.
https://zh.wikipedia.org/zh-tw/X-Forwarded-For

由於您提到 Nginx, 要讓 Nginx 認得上層送來 X-Forwarded-for 的方法有兩種方法:

1. 直接改 log format, 讓他紀錄 $http_x_forwraded_for, 而不是 $remote_addr
2. 啟用 real_ip 擴充模組, 並將上游防火牆的 IP 設定在 set_real_ip_from 內

上述兩個方法的簡易步驟說明:
https://www.loadbalancer.org/blog/nginx-and-x-forwarded-for-header/

從 Nginx 內部的 11 道處理流程來看,
方法 1:改 log format 是在最後一個 LOG 階段才處理此問題;
方法 2:啟用 read_ip 模組, 則是在第一個 POST-READ 階段就處理這個問題:

這個案例是:
前端使用 HAProxy 當作 Load Balancer, 後端用 Nginx 當 Web Server,
此案是在 nginx 裡面, 採用 real_ip 模組解決, 取得 Client 真實 IP:
https://blog.wu-boy.com/2013/10/haproxy-get-user-real-ip-using-codeigniter/

試試 X-Forward