I have used IPFire for just 2 days and I have an issue I hope can be solved.
I use RED/GREEN. IPFire has not been installed as part of the domain, but is a standalone server. I have setup static routes to make it work.
I have a basic firewall rule that forwards port 80 to my webserver.
The problem:
When I forward traffic from the internet (RED) to my webserver (GREEN) the IP that is being logged on the webserver log is the IP of the IPFire server. I need the original IP to pass through once it has been cleared.
this answer has been contructed using ChatGPT 4. It is NOT a copy/paste, but all the ideas come from the artifical intelligence machine. My contribution is just polishing. I am also not including the configuration files suggested, because I have no time to test their accuracy.
You need to do things differently.
There are two way to do this, as far as I know (or as far as ChatGPT knows).
Way number 1: X-Forwarded-For header:
Instead of using a DNAT (destination NAT), as you are doing, you setup in IPFire a reverse proxy, being nginx or haproxy, doing instead of a DNAT a SNAT (source NAT). This way you can use the header X-Forwarded-For. You can either have the reverse proxy add the header in the HTTP request it is forwarding, or configure the web server to read the X-Forwarded-For header and use it to populate the source IP address in the logs.
This works well for HTTP traffic. To have it working also for HTTPS traffic you have to configure the reverse proxy to terminate the SSL traffic at the router level and transfer the traffic to destination unencrypted, which might not be ideal. In alternative, you can create a new encrypted connection with the web server. There is a lot of documentation for nginx to do both.
If you chose to do SSL termination (also called offloading) you need to put the certificates for the encrypted traffic on the router and not on the web server. If you decide to forward the traffic encrypted, then you need another (different) set of certificates on the web server for this locally encrypted traffic.
Way number 2: Proxy Protocol and reverse proxy
With this second method you do not need to worry about HTTP or HTTPS. You set up a DNAT directed toward the reverse proxy instance (basically the firewall itself, instead the web server as you are doing now), and you instruct the reverse proxy to forward the traffic to the web server using the proxy_protocol on directive, while at the same time instructing the web_server to accept the proxy_protocol.
If you want to learn, you do research, test and document your effort keeping detailed notes. This way you learn. A cookbock or an AI is good only in this frame. You have a general description of the process. You are at step 1 and not anymore at step 0. This is really the hardest part. If you are really interested, you can do the rest.
