Navigation

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

    Not translating outbound port 25 communication

    NAT
    3
    5
    697
    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.
    • S
      sebna last edited by

      Hi All,

      I am looking to block LAN to WAN translation of communication through port 25 other then for a one specific local IP.

      Any help welcomed with rules creation - I assume two rules.

      Thanks

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis last edited by

        You just need to block the traffic - the fact that it would have had NATranslation aplied to it, had it been passed, is a moot point. So you don't need to change any NAT rule/s.

        I use aliases for everything, and never put a magic IP address number directly in a rule. So, make an Alias for the IP address that is allowed to go out through WAN to port 25 on the public internet - let's say it is called MailServer.

        You could do the block in 1 rule with a "not" (!) rule:
        Block source ! MailServer destination any port 25
        and then this assumes that there is some more general pass rule later that will let the MailServer-sourced traffic through with "everything else".

        But often it is clearer to explicitly allow what you want to allow, then block the rest, using 2 rules:
        Pass source MailServer destination any port 25
        Block source any destination any port 25

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

          No a fan of aliases for everything.  For one is mailserver going to be dhcp, I think not - so why not put in the IP address to make sure you don't run into issues with name resolution since this IP is not going to be changing very often..  Makes the rule table easier to understand because its clear cut address X has access out.

          Now aliases make sense if you need to put in something that needs to be resolved, or you have a list of things you want to add..  But when rule is so straight forward, allow IP X out, why not just use the IP vs the extra steps of alias?

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis last edited by

            Yeh, the alias for a single static IP is just personal preference - do whatever you can understand and maintain the easiest in that regard.

            1 Reply Last reply Reply Quote 0
            • S
              sebna last edited by

              Hi Guys,

              Thank you for your help. I followed the advice and created set of two rules on LAN side of FW to block all 25 port traffic other then my mail server.

              I also use aliases for everything. That saves time when you change IP of the particular service and do not have to track all rules for changes but just adjust alias IP.

              Cheers

              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