Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Rule to block sending email through port 25 which is not secure.

    General pfSense Questions
    5
    15
    131
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Antonio Briguglio
      Antonio Briguglio last edited by

      Hi!
      I need to create a rule that blocks sending email through port 25 which is not secure.
      How you do it? you can show me with screenshoot why I have difficulty with the language. I'm Sicilian thanks.

      Antonio Briguglio 1 Reply Last reply Reply Quote 0
      • Antonio Briguglio
        Antonio Briguglio @Antonio Briguglio last edited by

        Is there anyone who can help me? Thank you

        dotdash 1 Reply Last reply Reply Quote 0
        • dotdash
          dotdash @Antonio Briguglio last edited by

          @antonio-briguglio
          Firewall/Rules/Lan
          add a new rule (position before default allow rule)
          Action- Block, Interface - LAN, IPv4, Protocol TCP
          Source LAN NET
          Destination ANY
          Destination port range 25
          Check the log box if you want, name the rule and save.

          Antonio Briguglio 1 Reply Last reply Reply Quote 0
          • Antonio Briguglio
            Antonio Briguglio @dotdash last edited by

            @dotdash ok thanks one more thing how can I check the tcp / udp ports of the pfsense firewall?
            My SG 1100 is connected to the router and when I put the public ip it shows me the TCP / UDP ports of my router and not the SG 1100

            johnpoz 1 Reply Last reply Reply Quote 0
            • johnpoz
              johnpoz LAYER 8 Global Moderator @Antonio Briguglio last edited by

              If pfsense is behind a nat router, which it sounds like it is.. Then there would be NOTHING open to pfsense that you did not forward to it from your router in front of pfsense.

              Antonio Briguglio 1 Reply Last reply Reply Quote 0
              • Antonio Briguglio
                Antonio Briguglio @johnpoz last edited by

                @johnpoz That is?
                can you explain me better I have difficulty with the language .....
                but is there a method to see open or closed tcp / udp ports on pfsense? Thank you

                johnpoz 1 Reply Last reply Reply Quote 0
                • johnpoz
                  johnpoz LAYER 8 Global Moderator @Antonio Briguglio last edited by

                  Out of the box there is NOTHING open inbound from the wan side.. NOTHING.. Unless you created port forwards.. All inbound unsolicited traffic to your wan would be dropped.. Even pings.

                  To go along with that is seems like you have a nat router in front of pfsense, that would normally being doing exactly the same thing.. So unless you setup port forwards to pfsense wan IP on that router, nothing would even get past your other router in front of pfsense for pfsense to even do anything with..

                  A simple test tool to see what is open would just go to the shield up on grc.com This will scan first 1056 ports or something..

                  Look on pfsense wan interface rules - do you have anything allowed? If not then nothing is open..

                  Antonio Briguglio 1 Reply Last reply Reply Quote 0
                  • Antonio Briguglio
                    Antonio Briguglio @johnpoz last edited by

                    @johnpoz OK! I got it.
                    a question but pfsense automatically blocks port 25 or should I block it with the rule?

                    johnpoz Gertjan 2 Replies Last reply Reply Quote 0
                    • johnpoz
                      johnpoz LAYER 8 Global Moderator @Antonio Briguglio last edited by johnpoz

                      Out of the box all OUTBOUND traffic from your lan is allowed.. So if you want to block 25 outbound from some client on your lan.. Then yes you would need to block it.. As to should you - what client in this day an age would be sending email via 25, vs some spam infection??

                      I am not aware of any current email client that would send outgoing mail to its mail server via 25..

                      Do you have some email server behind pfsense that sends email? To other domains - if so then you would need 25 open..

                      Personally before I went and started blocking outbound traffic - unless you want people screaming at you that xyz broke. I would would log on your allow rule - so you get an idea of what ports your clients and applications behind pfsense are using.. You can track those down and figure out if that is something you want to continue to allow or not.

                      Shoot for most ISPs - they don't even allow outbound on 25 ;) Because unless your on a business line and have need, there would never be a need to send traffic out on 25 other than spam..

                      Antonio Briguglio 1 Reply Last reply Reply Quote 1
                      • Antonio Briguglio
                        Antonio Briguglio @johnpoz last edited by

                        @johnpoz Ok thanks for letting me understand how the rules work, now I have clear ideas :-)

                        1 Reply Last reply Reply Quote 0
                        • Gertjan
                          Gertjan @Antonio Briguglio last edited by

                          @antonio-briguglio said in Rule to block sending email through port 25 which is not secure.:

                          pfsense automatically blocks port 25

                          Added to what @johnpoz said :

                          Port 25 is reserved for mail server to mail server communication only.
                          I know, some very stupid ISP's, last century, had other ideas. Like : have mail clients send mail without authentication .... We all know what happened next.

                          Mail clients on your LAN, like Outlook 365 or Thunderbird or even pfSense itself (mail notification System > Advanced > Notifications) should use 587 TCP or 465 TCP.
                          " No firewall rule needed".

                          1 Reply Last reply Reply Quote 1
                          • bingo600
                            bingo600 last edited by bingo600

                            I only have port 25 forwarded to my mailserver.
                            I have no problems sending & receiving w. encryption to/from other mailservers

                            /Bingo

                            dotdash 1 Reply Last reply Reply Quote 0
                            • dotdash
                              dotdash @bingo600 last edited by

                              @bingo600
                              That's inbound, to your mailserver. OP was talking about outbound traffic from clients on the LAN, who shouldn't be using port 25.

                              Antonio Briguglio 1 Reply Last reply Reply Quote 0
                              • Antonio Briguglio
                                Antonio Briguglio @dotdash last edited by

                                @dotdash @gertjan @bingo600 That is? Is the rule you wrote me wrong? I did not understand the discussion well. Thank you

                                johnpoz 1 Reply Last reply Reply Quote 0
                                • johnpoz
                                  johnpoz LAYER 8 Global Moderator @Antonio Briguglio last edited by

                                  If you want to stop devices from talking outbound on 25.. Then put in a rule.. Simple enough..

                                  Here
                                  block25.png

                                  I would set it to log - and so you can see who is trying to do that.. Since unless you have some box infected trying to send spam - you should never see that rule even trigger.

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post

                                  Products

                                  • Platform Overview
                                  • TNSR
                                  • pfSense
                                  • Appliances

                                  Services

                                  • Training
                                  • Professional Services

                                  Support

                                  • Subscription Plans
                                  • Contact Support
                                  • Product Lifecycle
                                  • Documentation

                                  News

                                  • Media Coverage
                                  • Press
                                  • Events

                                  Resources

                                  • Blog
                                  • FAQ
                                  • Find a Partner
                                  • Resource Library
                                  • Security Information

                                  Company

                                  • About Us
                                  • Careers
                                  • Partners
                                  • Contact Us
                                  • Legal
                                  Our Mission

                                  We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                  Subscribe to our Newsletter

                                  Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                  © 2021 Rubicon Communications, LLC | Privacy Policy