NAT reflection on mail servers
-
@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.
