[SOLVED] Block smtp (25) on LAN network. Only allow mailserver to send mail
-
Firewall rules are read from the top down.
allow smtp from the server
block smtp from the lan
allow any anyAndy
1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22
-
@jknott Thank you for yhe quick reply. Off course you are right. I will do that when I have the main rule working.
Dot you have some example rules?
regards,
Herman -
@nogbadthebad Thank you for your reply. It seems that my block smtp from the lan blocks all. even the acces to the mailserver.
I try to post a screenshot :)
-
This is the rule I have created. It seems that the rule "Block all SMTP outbound" blocks all? when I disable the rule, mail wil be sended.
Hope this helps a bit..
Regards Herman
-
You have your exchange alias as a destination not a source.
-
@nogbadthebad Modified the rules as following. The mail wil be delivered. Strange issue is that Outlook 2016 has problems with connecting to the exchange server?! local LAN all is open right?
My LAN is an Active Directory environment running pfSense 2.4, DC Server 2016, Echange 2013 on server 2012R2.
Here are the mail rules;
-
pfsense has zero to do with lan talking to lan..
Other than dns? But if your using AD, then all your clients should talk to your AD dns anyway.
-
@johnpoz Hi John, completely right. All the clients do DNS via the Domain Controller. All clients first DNS entry is pointed to the DC's IP address. But still since pfSense is in the picture Outlook is giving trouble connecting to the exchange server.
Maybe I did some false config on the DNS config of the pf Sense? The DNS forwarder is disabled and the DNS resolver is enabled with default settings.
Any suggestions?
Greetz,
Herman -
@herman said in Block smtp (25) on LAN network. Only allow mailserver to send mail:
All clients first DNS entry
Are you saying they have more than 1 and this points to pfsense? Yeah that is Borked and going to cause you grief in the long run. You can not point to clients to more than 1 dns when the different dns does not resolve the same stuff. ie you do not point to local dns, and 2nd point to public dns - because public dns can not resolve local.
You can never be sure which dns client will actually use..
Point your clients ONLY to NS that can resolve your AD.. if pfsense can not resolve your AD then clients should not have it in their list for dns.
-
@johnpoz Right, double checked it. All clients have only one DNS server pointing to the DC hosting the DNS role.
Greetz,
Herman -
Well than pfsense has ZERO to do with device on lan talking to another device on lan.. If your having problems with outlook talking to your exchange that are on the same network - what do you think pfsense has to do with that conversation?
-
Doesn’t make sense to me at all too. Since I’ve implemented the pfSense firewall this issues start to occur.
Should the something be configured in the DNS resolver of the pfSense? Shouldn’t it also point to the DC’s DNS?
-
@herman Found the problem! I am also migrating Exchange 2013 to Exchange 2016. Since the 2016 box was off because I paused the migration, Outlook was still trying to resolve the public folders on the 2016 box. Turn the machine on resolved the problem.
Sorry for the inconvenience. My bad!
But still wondering if I should setup anything for the DNS resolver of the pfSense?
Cu,
Herman -
I wouldn't. If anything I would set up a backup domain controller.
-
@derelict So you suggest to leave the DNS Resolver on pfSense box disabled?
Gr. Herman
-
https://forum.netgate.com/post/778596
-
@derelict Thank you. Now it look like i would expect it to look. Even the ARP table is resolving the right hostname now.
Sorry if I keep going on but in the log file I see the folowing two entries. Any idea what they mean? port 67 and 68 is DHCP if I am correct.
and
That would be the last post for today. Have to go sleeping
Thanks to everybody for the kind support. CU soon.
Bye
Herman -
@herman If you are not running a DHCP server on pfSense you will not have the automatic pass rules for DHCP on your local network.
If you are limiting outbound connections and not passing any into the local interface, you might want to make a rule to block that traffic and not log it to kill that log spam. That is logging that a DHCP discover broadcast was received and not passed by the firewall.
Same with the IGMP if the log entries annoy you.
Or you could just turn off logging on the default deny rule entirely. Status > System Logs, Log firewall default blocks. For me it would depend on how many rules were necessary to get the log spam under control. If just a couple/few, I would make the rules. If it's a boatload, I'd probably just disable the logging entirely.
