Inbound Port Forward while keeping originating IP address (without NAT)?

[aeleus]

I set up a few inbound port forwarding rules for HTTP, SMTP and the like. They work. The issue is that when pfSense forwards the packet to the target server on the LAN, it translates the public IP address to its own LAN IP address. The internal, target server sees that traffic as coming from the pfSense box - not the internet.

That works okay for HTTP traffic as pfSense adds the X-Forwarded-For (XFF) HTTP header field to identify the originating IP address. That allows the Web server to see from where the traffic is coming.

For SMTP, there is no "X-Forward-For" mechanism. This is not good as the email server relies on the public IP address to make decisions on what clients to trust, IP blacklists, etc. All SMTP traffic now appears to be LAN traffic.

Interestingly, OPNsense does the opposite. All inbound NAT appears to the target endpoint to come from the original public IP address. Downside: the target server must use that OPNsense box as its default gateway.

When I used TMG firewall, each "publishing" rule could be set to appear to come from the firewall or the original public IP. I liked this approach as there are times when one approach is desired over the other.

Is there a way to configure this behavior in pfSense?

Thanks!

Running pfSense 2.3.3-RELEASE-p1

[viragomann]

pfSense doesn't source-NAT on forwarded packets by default.

Are you using a proxy or have you set a gateway in the internal interface settings?
Otherwise check the outbound NAT settings. There shouldn't be any rule for internal interfaces if there are no particular reasons for this.

[kpa]

Yep, this sounds like a misconfiguration in the outbound NAT settings. By default the source address is left untouched by the port forwarding RDR rules, only the destination address is changed.

[aeleus]

Thanks  viragomann and kpa for pointing me in the right direction. The problem was indeed the outbound NAT rules. At some point, an outbound rule had been created for the SMTP server, and that was doing the NAT'ing on inbound port-forwarded traffic.

Once I cleaned that up, the traffic now flows as expected. BTW, HTTP traffic is actually coming in via squid reverse proxy (not port forwarding) - that explains the "x-forward-for" header.

As a bonus, I can now control which inbound ports are NAT'd and which are not.

[Korn123]

I do not understand the problem is when pfSense forwards the packet.

[Derelict]

Port forwards translate the destination address and/or port.

Outbound NAT translates the source address and/or port.

[aeleus]

@Derelict:

Port forwards translate the destination address and/or port.

Outbound NAT translates the source address and/or port.

It helped me to realize that "Outbound NAT determines how traffic leaving a pfSense system will be translated". That is, "outbound" from the pfSense system - not necessarily "outbound from the network". One can apply Outbound NAT rules to traffic that is "inbound" to the network (including Port Forward traffic).