NAT reflection on mail servers
-
Hi,
I have a setup where 2 mail servers sit on the same LAN (private IP, RFC 1918) using pfSense as gateway to Internet (each one has its outbound NAT rule to use its public IP), and pfSense has the inbound NAT rules to publish SMTP port to Internet, each one having its own same public IP.
The issue comes when one of the servers has to deliver mails to the other. The fast solution seems to use the "reflective" NAT tick to the inbound NAT rules, so each one can reach the other server on its public IP. Done and it works.
But this solution is not ideal... It makes that all SMTP connections from one server to the other use as source IP, the IP of pfSense on that LAN, which breaks SPF checks on the mail server.
As i see there's no easy trick to make pfsense perform the outbound NAT (so public IP could be attached as source IP to this connection) prior to get through the inbound reflection NAT... Tried to apply outbound NAT on LAN interface but no luck.
Is there any solution that we are missing?
Thanks in advance -
@pipers Well, the obvious solution would be to amend spf records to allow this to happen.
Even listing rfc1918 on spf is allowed.
And since we are talking about same lan, a few tricks with hosts files would allow mail servers to talk to each other directly, being on the same lan. -
Also many/most mail servers have a way to whitelist certain IPs, so SPF checking is not performed.
-
@netblues Thanks Netblues... Thought about this possibility, but listing RFC addresses on SPF seems as a bit of exposing information not very securely... Isn't it?
-
@teamits Thanks Teamits... This is the solution we have adopted up to now (set up the LAN IP address of pfSense as a trusted SMTP server). But this leads to two points:
-
All hosts on LAN are now trusted (pfSense's LAN IP is used), not only the 2 mail servers. One of them is a hosting panel, holding some websites in it. A misconfiguration/vulnerability on it would leak a hole on using the others host mail server as an open relay
-
My point was about using pfSenses packet manipulation capabilities (isn't it a layer 3-4 device?) How could this be done using NAT rules or other techniques? IPtables would resolve it using two ordered NAT rules (SNAT inbound on LAN first and DNAT after)...
-
-
@pipers What do you mean by all hosts on lan ip is now trusted? What this has to do with pfsense lan ip? And why you trust pfsense as a mail sender?
As for spf, no it is not an issue. If someone breaks into your network, just knowing the ip of your internal mail server is something that can be found anyways.
And how about listing all your lan at the spf? Like 192.168.0.0/16
Says nothing to noone.
Obviously it is much better to whitelist specific ip's at the mail server.
Keeps all configuration in one place and not relying on spfpfsense can also work as a bridge, with rules so if you segment your lan you can always do it that way.
-
Why would you use nat reflection at all?
Why would you not just setup local dns mx records so that your server wanting to send to domainX (your other mail server) would just resolve the local address. On this server just set a spf whitelist for your sending domain..
There is no need to put rfc1918 in your public spf records...
-
@netblues Hi and thanks again,
Reflective rules make all connections coming from the LAN appear with pfSense LAN IP address as source IP... This is the IP address we are whitelisting at the mail servers.
Showing your private IPs is considered as an information disclosure not recommended in IT security basics... Not a big hole, but a small one in any case.
The question about packet manipulation in the pfSense keeps with no answer to see if its possible.- In an Internet facing pfSense (having public IPs on one side and privates on the LAN side), can we make a connection coming from the inside (LAN interface) to a public IP managed by the pfSense (as an inbound DNAT) and forwarded to another inside host appear with a source IP address being a public address also managed by the pfSense (SNAT)? For sure reflective rules with no other config don't make it...
-
@johnpoz Thanks johnpoz! Seems a better workaround than the one we are using (whitelist IP on SMTP server)... Will apply this better...
Anyway networking and NAT manipulating question keeps open! -
@johnpoz said in NAT reflection on mail servers:
Why would you use nat reflection at all?
Why would you not just setup local dns mx records so that your server wanting to send to domainX (your other mail server) would just resolve the local address. On this server just set a spf whitelist for your sending domain..
There is no need to put rfc1918 in your public spf records...
That would also mean running split dns. Otherwise this would break things on the internet side.
-
Yes this is a "split" dns setup - why I stated "local" dns mx record.. Here is the thing - if your using nat reflection to access the server sitting next to you. Your doing it wrong..
-
@johnpoz But there is no local mx record with unbound, right? But also it is not needed in the first place for Email with split DNS I think.
-
You can setup a mx record in unbound.
And yes you need a mx record, how else would the smtp server find where to send the mail for domianX? Unless you hard code it in the smtp server? Which sure would be an option depending on your smtp software.
You would setup MX records in unbound via use of the Custom options box in the unbound settings page.
-
And you also need to do this for all domains hosted on local mail servers.
And also manage this and external dns changes as needed.