pfSense+Postfix via Port Foward
-
I have been running a postfix server behind firewall with private IP via port forward without any problems. But one issues that I have been researching to fix is how I can know the client IP on the SMTP.
My mail log only captures my pfsense box interface IP and not client (source) IP.
MTA captures 10.0.0.1 on its log for all incoming mails via port forward and/or 1:1NAT.[ISP] - [WAN: 219.xxx.xxx.xxx global IP] pfsense box [LAN(DMZ): 10.0.0.1] - MTA [LAN: 10.0.0.2]
I am trying to use RBL and Rspamd more efficiently and wonder how I can use pfSense to maintain the client IP for MTA to receive behind fire wall or perhaps to use proxy protocol.
Other than that, the mail server has been working great and no troubles and I assume Rspamd is also working fine despite history shows only 10.0.0.1 as sender IP, but not RBL, I wonder.
I am using HAproxy for all other http traffic to numbers of web servers with X-forwarder-for and it works great.
I have been trying to find some info on this in Japanese, but not so many people in Japan use pfSense. unuumbered is popular in Japan for multi number of global IPs connection.
If I can set unnumbered in pfsense, I can get 8 global IPs to assign a global IP to certain servers require direct access. I can not find a way to do so either.
Any help or information is greatly appreciated.
-
@t-sato
pfSense does not masquerade source IPs on incoming traffic by default. HAproxy does though, but as I got you, you simply forward the SMTP packest to the postfix server.Bu masquerading is also applied on inbound traffic if you have stated a gateway in the LAN interface settings, did you do that? If then you should remove it.
-
Thank you for your reply.
Yes, I set simple port forward for mail related ports.
And no gateway is set on the LAN interface in "IPv4 Upstream gateway". There is no selection other than "None".
-
@t-sato
That's all correct. If the port forwarding is applied to the incoming packets, they cannot go to HAproxy. So pfSense shouldn't masquerade them.My mail log only captures my pfsense box interface IP and not client (source) IP.
MTA captures 10.0.0.1 on its log for all incoming mails via port forward and/or 1:1NAT.I assume, you're talking about public access to the MTA here, not access from internal devices.
Is your outbound NAT in automatic mode?
-
@viragomann said in pfSense+Postfix via Port Foward:
I assume, you're talking about public access to the MTA here, not access from internal devices.
Yes, that is correct. Client access from WAN with public address.
Is your outbound NAT in automatic mode?
My current outbound NAT is set as Hybrid. And auto created rules are there.
If I remove rules for the LAN portion, connection will be lost.
Currently all accesses from both WAN and other LANs in my pfsense box to the MTA are logged with 10.0.0.1 which is pfSense box IP for the LAN (DMZ, I named) interface.
I have another pfSense box (port foward) with different WAN/ISP and did same test with different IP (i.e. 10.0.0.3) in the same LAN and the postfix log shows 10.0.0.3 for all access from the 2nd pfSense box.
Both of those box maintains all connections and MTA works no problem to receive and transmit, jusst access log shows box LAN IPs and cannot obtain client's public IP so MTA can not know where it came from IP address wise.
-
@t-sato said in pfSense+Postfix via Port Foward:
If I remove rules for the LAN portion, connection will be lost
Your screenshot doesn't show any LAN rule(?).
-
I have this set up going in my DC.
I have VIPs but this runs on the WAN address.
WAN tab of Firewall Rules:
The SMTP_Ports Alias:
That's it. Nothing more on the firewall to allow traffic from WAN to the SMTP (Postfix/Dovecot/SpamAssassin) server.
-
@viragomann said in pfSense+Postfix via Port Foward:
@t-sato said in pfSense+Postfix via Port Foward:
If I remove rules for the LAN portion, connection will be lost
Your screenshot doesn't show any LAN rule(?).
I pasted wrong screenshot. This is the current outbound NAT setting.
If I disable DMZ (2nd line from top), connection to the network will be lost from public and also other LAN.
-
Thank you for the rule info. Yes, mine is same way as allowing mail related ports on WAN.
10.0.0.23 is actual LAN IP for my MTA.
There is no access issues and all deliveries are fine. But just can not log the source IP, all access logs of postfix and dovecot are accessed from 10.0.0.1 which is pfSense interface IP.
-
@t-sato
This is masquerading! pfSense translates the origin source address into the DMZ interface address in outgoing packets on DMZ.If you need this to get access to your mail server the server doesn't accept outside sources. He blocks it by its own firewall.
So you have to configure the server properly to accept access from the internet.There is nothing what pfSense can do here.
-
@viragomann said in pfSense+Postfix via Port Foward:
@t-sato
This is masquerading! pfSense translates the origin source address into the DMZ interface address in outgoing packets on DMZ.Earlier, you mentioned that pfSense does not masquerade source IPs on incoming traffic by default.
I just want to clarify port forward or 1:1 NAT on pfSense does masquerading, therefore the server can not log source IP and log interface IP of pfSense.
If you need this to get access to your mail server the server doesn't accept outside sources. He blocks it by its own firewall.
So you have to configure the server properly to accept access from the internet.My server accept everything properly. I think now I need to find a way to assign public IP on the mail server and bridge it or tunnel or use proxy protocol via HAproxy outside of pfsense to know the source IP.
There is nothing what pfSense can do here.
I was reading this article and was looking for a way to know source IP at server via pfsense port forward, but I was wrong I assume.
https://www.haproxy.com/blog/efficient-smtp-relay-infrastructure-with-postfix-and-load-balancers/?_gl=1g5bk2y_gaMTcwNjExMDIzMi4xNjcwOTk2Nzg3_ga_MGHPDQ7WFP*MTY3MjE2Mjg2OS4xNi4xLjE2NzIxNjI5MjAuMC4wLjA.
Thank yo so much for your advice. It really helped me to find different way to achieve the goal.
BTW, cheap router provided by ISP here has simple DMZ function (1:1 NAT or similar) and somehow same mail server was able to obtain source IP in maillog. Since I replaced with pfsense, it doesn't log sorce IP. I assume the way pfsense works sounds normal and correct while the cheap router worked was useful but not right.
-
On your server log (maillog), is source IP recorded? Or log shows interface IP that serves for 10.50.1.3?
-
@t-sato
When receiving email from the outside:Dec 27 11:59:05 mail postfix/qmgr[1120]: 7091B40E87: removed Dec 27 11:59:31 mail postfix/smtpd[2472233]: connect from unknown[185.55.243.205] Dec 27 11:59:33 mail postfix/smtpd[2472233]: CA5E940956: client=unknown[185.55.243.205]Dovecot when I check my email:
Dec 27 12:00:07 imap-login: Info: Login: user=<sales@domain.com>, method=PLAIN, rip=174.2x.1xx.xx, lip=10.50.1.3, mpid=2472478, TLS, session=<!@#$%^RTDFG#@> Dec 27 12:00:07 imap-login: Info: Login: user=<support@domain.com>, method=PLAIN, rip=174.2x.1xx.xx, lip=10.50.1.3, mpid=2472479, TLS, session=<!@#$%^RTDFG#@> -
@t-sato said in pfSense+Postfix via Port Foward:
Earlier, you mentioned that pfSense does not masquerade source IPs on incoming traffic by default.
This is still true. pfSenes doesn't masquerade incoming packets by default. You have added the outbound NAT rule by yourself.
I just want to clarify port forward or 1:1 NAT on pfSense does masquerading, therefore the server can not log source IP and log interface IP of pfSense.
1:1 does both, DNAT (port forwarding) and SNAT (masquerading). But if the rule is configured correctly, the latter is applied only on outbound traffic on WAN.
You didn't show your NAT 1:1 rules. Maybe there is something wrong.
Ensure to add the rule on WAN.I was reading this article and was looking for a way to know source IP at server via pfsense port forward, but I was wrong I assume.
https://www.haproxy.com/blog/efficient-smtp-relay-infrastructure-with-postfix-and-load-balancers/?_gl=1g5bk2y_gaMTcwNjExMDIzMi4xNjcwOTk2Nzg3_ga_MGHPDQ7WFP*MTY3MjE2Mjg2OS4xNi4xLjE2NzIxNjI5MjAuMC4wLjA.HAproxy is not the solution for this. As I mentioned above HAproxy does masquerading by default.
It can insert the forward-for header though to provide the origin source to the web server, but this is only done in HTTP traffic. So there is no benefit of this for an MTA at all.BTW, cheap router provided by ISP here has simple DMZ function (1:1 NAT or similar) and somehow same mail server was able to obtain source IP in maillog.
Cheap router often does masquerading on forwarded traffic.
Since I replaced with pfsense, it doesn't log sorce IP.
So I cannot believe that.
-
@t-sato Also you outbound NAT looks horrible. Why do you use hybrid in the first place?
-
Thank you for the clarification. You are really helping me to understand pfSense.
No, I do not use 1:1NAT for this.
I will review outbound NAT settings and documents to ensure my setting is correct to maintain DNAT w/o masquerade and proper outbound traffic.
My mail server works no problem sending and receiving with WAN if I do not mind log shows LAN interface IP....
You are correct, x-forward-for works only for HTTP, won't work for SMTP. The article cites proxy protocol for SMTP not XFF. I understand it not pfsense issues.
Again, I really appreciate you for taking your time to share your knowledge and experience. Not so many pfSense users in Japan and I could not find much information or discussion about pfsense in Japanese environment.
-
Thank you! This is what I wanted to see on my server. I will review my outbound NAT settings.
-
@t-sato said in pfSense+Postfix via Port Foward:
Again, I really appreciate you for taking your time to share your knowledge and experience. Not so many pfSense users in Japan and I could not find much information or discussion about pfsense in Japanese environment.
However, DNAT, SNAT, port forwarding, masquerading are all networking basics. I think, you might find also much stuff in Japanese regarding this.
But yeah, some terms for these settings might be different in pfSense than in other routers. -
@bob-dig said in pfSense+Postfix via Port Foward:
@t-sato Also you outbound NAT looks horrible. Why do you use hybrid in the first place?
That is a good question. I honestly do not know why I did exactly. I remember I found some articles to switch hybrid to make something work. You are correct. I know I should not do thing that way. I have no excuse.
I left the part alone since everything else is working.
I will review and confirm all setting from clean install in test environment.
Thank you for guiding me to right direction!
-
@t-sato said in pfSense+Postfix via Port Foward:
I remember I found some articles to switch hybrid to make something work.
If you're doing PBR then you will want it to make sure your specific routes use the outbound interface (typically a VPN) but I think in your situation it's unneeded
