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

    Not translating outbound port 25 communication

    Scheduled Pinned Locked Moved NAT
    5 Posts 3 Posters 1.0k Views
    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 Offline
      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 Offline
        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

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

        1 Reply Last reply Reply Quote 0
        • johnpozJ Online
          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?

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 24.11 | Lab VMs 2.8, 24.11

          1 Reply Last reply Reply Quote 0
          • P Offline
            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.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • S Offline
              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
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.