NAT'ting SMTP traffic sourced from the firewall's LAN IP

luckman212

Backstory…
https://redmine.pfsense.org/issues/5476
TLDR; Trying to make sure email alerts are reliably sent in a multi-wan setup without having to enable the "allow default gateway switching" option, and need some help with filing the bug(?) upstream with FreeBSD

I have found that rules cannot be used to route traffic from the firewall itself via a gateway group.

I am looking for some help with filing that bug Jim Pingle suggested against stock FreeBSD. He suggested "You'd need to configure [a stock FreeBSD system] for multiple WANs and use a pf ruleset similar to the one you have now that exhibits the problem. Preferably one that simplifies the rules to only expose the problem case." I am in over my head on that one. :-[

I had a thought which was to enable an unused interface (igb3 in my case) and assign it an IP like 10.10.10.1. I then modified the code at /etc/inc/smtp.inc to use [b]stream_socket_client() instead of fsockopen, which allows binding to a specific source IP for the outbound connection. I got the code to work but my theory that this would subject the connection to NAT processing and route traffic according to my 'igb3->any' rule didn't work – it still dumped the traffic out of the default gw and not the gateway specified on the igb3 interface rule.

Thanks to all for any advice

luckman212

Hi guys, this never got a response, trying one more time – if anyone can help me with filing the issue I would really like to see if this can get some attention. Very long standing issue.

kpa

Gateway groups and other policy routing tricks are not available for traffic that originates from the firewall itself, they only work on traffic that enters the firewall via an interface from the outside. You can call it bug or otherwise but FreeBSD's packet filtering hooks can not re-route traffic that is already in the outgoing queue of an interface. Binding to an unused interface (like the igb3 in your case) is not going to work either because the traffic is still originating locally and never actually enters the incoming queue of the interface where it could be tagged for policy routing.