NAT packets rewrite source IP for mail logs
-
Hello, I have a particular problem with pfSense NATed traffic being logged internally on a mailserver. I have scanned the commentaries here and find some relevance but not precisely the issue I have.
I have a complex enterprise setup that includes a mail system featuring three parts;
1 Enterprise mail (Linux/Axigen- a virtualbox guest) with no exposure to the internet,
2 Edge mail-wash server A (Win2016/hMailServer - a virtualbox guest) taking port forwarded traffic from a pfSense router (also a virtualbox guest on the same host) with three (3) public WAN IPs that are part of a block of IPs mapped to my NBN modem, and,
3 Edge mail-wash server B (Win2016/hMailServer - a virtualbox guest at a different physical location to server A) taking port forwarded traffic directly from an NBN router.I am perfectly content with how all of the packets flow to achieve the filtering of rubbish before reaching the enterprise mail server. BUT the two mail-wash servers operating hMailServer software do not both deliver the full potential of their abilities.
Both have the ability to use AutoBAN by monitoring the behaviour of source IPs.hMailServer B (packets forwarded direct from the NBN router) does that well as the inbound mail logs record the original source IPs of the packets. I can configure AutoBAN when a particular source IP makes failed login attempts. This server is very effective in dealing with crap mail and crap senders.
hMailServer A (packets forwarded from pfSense) logs the packet source as the internal Lan IP of pfsense. Login failures identified by the mail server would effectively ban the pfSense router LAN IP.
All of the materials I have canvassed that talks to the rewriting of headers (X-forwarded) seem to me to be talking about outbound traffic. pfSense is presumably rewriting the inbound header, I have tried the NAT configuration and a firewall rules only redirection, but both cause packets to be logged with the LAN IP as the source.
Am I missing something simple in settings?
The thought crosses my mind that my multi-public-WAN configuration does not allow me to configure a gateway assignment on the individual interfaces - each will generate an error that the configuration overlaps or is in use by the other two interfaces. That said, in every other respect the pfSense device is doing its job to my entire satisfaction. The mail logging would just be a nice bonus.
Regards, Graham
-
@boss2908 said in NAT packets rewrite source IP for mail logs:
Am I missing something simple in settings?
What you're seeing is probably the main reason why a mail handler processes like a mail server or your mail washer shouldn't be mounted behind a NAT type device.
You know it already, but I'll repeat it anyway : NAT = Network Address Translate
NAT is working both ways : when you LAN based mail server is sending mail, the receiving server on the Internet will 'see' your WAN IP, not your RFC1918 LAN IP. -
@gertjan
Thanks for your comments. I do know that, but the mail server is not the only local facility that uses the WAN IP, something has to split traffic to other devices.In the case of the second mailserver behind an NBN router, it is pure port forwarding that does not rewrite the headers apparently. My query was to probe any knowledge of pfSense that would emulate the same behaviour. As I described, I have tried simple port forwarding using a firewall rule, but the same rewrite seems to occur.
Thanks again, Graham
-
iptables could do something like that, I guess.
But pfSense / freeBSD != Linux.But what's the point of putting a mail server behind a NAT and not wanting NAT ?
My mail server - an off-the-shelves postfix, lives on a server, which lives on the Internet, using a boat load of IP's attached to it.
Port 25 TCP is open of course. As what you would do : handle all 25 TCP traffic to the inside mail server. So no security is added nor removed.
Ok, I admit, some how it looks scarry : a server on the Internet.Still, the issue you have is the price you pay if you put a mail server on a LAN.
I understand I don't really help you here. I hope others chime in, as I know that my 'put it outside' won't be your solution for you.
-
@gertjan
Thanks again for taking the time to communicate your thoughts.I have no aversion whatsoever about the placement of a mailserver in full view of the Internet. The choice to place it behind a router is purely the desire to have a device that can turn a single public IP address into a multi-destination relay of traffic. Different protocols making use of that public IP address are better served by specific equipment/software on the inside. As you point out, all inbound TCP/SMTP 25 traffic has no requirement or logical reason to have the packet headers rewritten (disguised), ie inbound NAT is not even the key factor here. Maybe an elaboration would help you to understand what my mind is processing.
First location - one public IP address.
The boundary router is a AR129 Huawei product supplied by the ISP.
There are several internal machines using the connection to the internet.
There is a mailwash server using the WAN IP as a MX address in DNS.
The direction of TCP/SMTP 25 packets is done by settings within that router.
Those settings are; NAT > Port Forwarding > TCP/SMTP 25 > Mailserver 25.
Those packets are delivered to the mailserver without rewriting the packet header.
That behaviour is not an optional setting.
That port forwarding is not possible by any other means in that router.
It might be reasonable to assume that TCP/SMTP 25 inbound packets are not
having the headers rewritten by design, ie, it cannot be deemed necessary.Second location - 1 primary public IP address + subnet/29 (8) mapped IP addresses.
The boundary router is a AR129 Huawei product (and the primary WAN IP address)
There is another boundary router being the pfSense virtual device;
It has 6 nics,
4 x WAN that service 4 of the 5 available IP addresses in the subnet/29 block,
1 x LAN address that is on the 192.168/24 subnet,
1 x DMZ address that is on the 10.179/24 subnet.
If I use the AR129 Huawei (NAT > Port Forwarding) = NO SMTP rewritten headers.
BUT that is just one public address, without rewritten inbound headers.
If I use the pfSense router (NAT > Port Forward) = all SMTP headers are rewitten.
BUT that handles 4 public IP addresses, therein is the trade-off.I did think I was pretty smart to get a configuration that could pass 4 public IPs through to a dynamic multi-dimensional facility. The capability of the pfSense router was not rated so much for protection from the internet, as it was for the pure compactness and configurability of the routing. I had variously dabbled with a Linux box with multiple nics but that was much more cumbersome that the pfSense experience that I currently use.
Hence my goal here is to pick the brains of the obvious pool of knowledge, to see if there is some way (even undocumented) to disable the header rewrite on inbound port forwarded TCP/SMTP packets. I am hoping that the proprietary routers are an indication that it is the more prevalent mode.
Regards, Graham