Multi WAN & Mail Servers
-
Hi everyone,
I've added another gateway to my Pfsense with 5 VIP.
I already had one GW with 5 VIP. So my network look like this :
WAN 1 => Public IP + 5 VIP (wan1.x.x.1 , wan1.x.x.2 ...)
WAN 2 => Public IP + 5 VIP (wan2.x.x.1 , wan2.x.x.2 ...)I have 2 mails servers on my WAN 1 VIP running smoothly for months.
This week, I've added one mail server on WAN 2 VIP and got some problems to make it works, but now it's working.My last problem is that all servers can email Google, Microsoft with no problem but the servers can't email each others.
Here some screenshots of my config :
My WAN 1 Rules :
My WAN 2 Rules :
My DMZ Rules : (All three servers are in the DMZ, 10.10.3.83 is the new on WAN 2)
My iRedMail Aliases :
My NAT Port Forward Rules :
My NAT Outbound :
When I try to email 10.10.3.80 on WAN 1 via 10.10.83 on WAN 2 I get:
mail postfix/smtp[3996]: connect to mail.DOMAIN2.tld[wan1.x.x.3]:25: Connection timed out mail postfix/smtp[3995]: 4P3cDH1QcVz2R: to=<test@DOMAIN2.tld>, relay=none, delay=1515, delays=1485/0.08/30/0, dsn=4.4.1, status=deferred (connect to mail.DOMAIN2.tld[wan1.x.x.3]:25: Connection timed out)
To send emails, I'm using Thunderbird, connected on port 587.
Any idea, what I'm missing ?
-
@alek
Either add host overrides for your mail servers and point them to their internal IP or exclude your WAN1 subnet from the policy routing rule for the new mail server and enable NAT reflection in the NAT rules.
-
@viragomann
Thanks ! Did add a host override for all my email servers like this :
Now they can email each others internally.
#################################################################################################- 2nd question, why can't they talk to each other externally ? What did I miss in my rules ?
#################################################################################################
- 3rd question, while looking into my NAT rules, found out that all of them have NAT Reflection disabled by default.
My default setting :
Not sure if I really understand this setting, what's the recommended way of doing it ?
-
@alek said in Multi WAN & Mail Servers:
2nd question, why can't they talk to each other externally ? What did I miss in my rules ?
The firewall rule for passing the traffic from 10.10.3.83 to anywhere directs all matching packets to the WAN2 gateway, since you stated it in the rules advanced options. Hence also the traffic to WAN1.
This doesn't work with default settings. It might run into asymmetric routing issues.
Even if the packets are routed from WAN2GW to your WAN1 interface, response packets to the WAN2 IP won't be routed back to the gateway again, since the destination IP is assigned to interface of pfSense itself.3rd question, while looking into my NAT rules, found out that all of them have NAT Reflection disabled by default.
As you have already defined host overrides, you don't need NAT reflection anymore. Host overrides are the more reliable solution.
With the host override, when the one mail server needs to access another one, it gets the internal local IP address from the DNS and hence sends the packets to it directly. The traffic doesn't pass pfSense, since both devices are within the same network segment.
So also the policy routing rule doesn't matter then.NAT reflection means, that the NAT rules, which you have assigned to WAN interface, is also applied on the other pfSense interfaces. So if the device tries to access a WAN1 IP it is redirected to the internal IP is well.
Without that, internal requests to any of your WAN IPs are not redirected. -
I've edited my DMZ rules to look like this :
What should I change then to match what you said ?
Thanks.
-
@alek
Not clear, what you try to achieve now or what you're missing.
As you stated above, you want certain host to go out on WAN2 and the others on WAN1.
So assuming WAN1 is your default gateway, add all IPs, which should use WAN2 to the GW2_IPOUT alias and it should do that.The second rule is applied to all other IPs then. The third one is not needed anymore.
Of course you still need the rule for allowing DNS access to pfSense without any gateway stated.