Navigation

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

    Trouble using FQDN in Host Alias

    Firewalling
    2
    3
    824
    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.
    • R
      reisender last edited by

      I am trying to setup a rule on a VLAN interface that will allow IMAP traffic to reach only Gmail's servers, but no other providers.  The end users are using Outlook to connect to Gmail, and are therefore using ports 993 and 587.

      I've created this rule to allow IMAP traffic (see attached image):

      Action: Pass
      Source: VL20_Net (this is the VLAN)
      Source Port: Any
      Dest: MAIL_SRVR (this is an alias - see below for more info)
      Dest Ports: MAIL_PORTS (defined as 993 and 587)

      The problem I'm having is related to the MAIL_SRVR alias.  When I add the hosts imap.gmail.com and smtp.gmail.com the rule does not work.  The traffic isn't matched to the rule and it flows through to the reject all rule at the bottom.  If I change the alias to use IP addresses instead of the FQDN it works correctly and allows the IMAP traffic.  The problem is that the Gmail IP addresses change frequently.  I don't want to be constantly chasing IP addresses and would prefer to use an FQDN.

      Is there a trick I'm missing to get the Host Alias to work with a FQDN?

      Thanks

      ![VL20 Firewall Rules.jpg](/public/imported_attachments/1/VL20 Firewall Rules.jpg)
      ![VL20 Firewall Rules.jpg_thumb](/public/imported_attachments/1/VL20 Firewall Rules.jpg_thumb)

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

        imap.gmail.com points to a cname, did you try putting in the actual cname?

        ;; ANSWER SECTION:
        imap.gmail.com.        282    IN      CNAME  gmail-imap.l.google.com.

        Same goes for smtp
        ;; ANSWER SECTION:
        smtp.gmail.com.        300    IN      CNAME  gmail-smtp-msa.l.google.com.

        Also the TTL is very very very short.. 300 seconds..  So you going to have the alias update every 5 minutes?

        Your problem is prob not so much that alias is not resolver but more that the IPs change on it so fast that alias resolves to A, and couple of minutes later its IP B that is different IP before the alias has updated.  Are you using using pfsense for dns?

        1 Reply Last reply Reply Quote 0
        • R
          reisender last edited by

          After playing with this some more, I'm convinced that johnpoz hit the problem on the head - the very, very short TTL.

          To test it I let the email client run for several hours without changing anything in pfSense.  I saw the rule work for SMTP but not IMAP, than reverse itself and work with IMAP but not SMTP.  For a while it worked with both, but than spontaneously reverted back to not working at all.

          I then tried it will the CNAMES suggested by johnpoz and still got the intermittent functionality described above.  The fact that it would send but not receive, then receive but not send makes me think that one of the servers was resolving, but not the other.  Sometimes one would resolve, then neither would.

          I'm going to just going to change the rule to allow Dest ANY and Dest Ports 587 and 993.  It would be nice to narrow it to allow only traffic that is actually needed, but for my small network I don't think it will be a problem.

          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