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

    SMTP Server/rules

    Firewalling
    3
    8
    5.6k
    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.
    • I
      IanSVT
      last edited by

      I have an SMTP server behind my firewall.  I have it carped for "binat" duties.  My rules are as follows on the WAN interface:

      outbound:  From 10.5.5.9 port/25 to anything
      outbound:  DNS from anything
      inbound:    From anything to 10.5.5.9 port/25

      The LAN interface has "Default LAN -> any" on it from install.

      I'm not sure if this is the best configuration.  I'd like to clamp down the DNS setting.  I tried doing it from 10.5.5.9 but my flow of mail stopped.  I'm not sure why that happened.

      Also, I'm not sure how the LAN and WAN interface correlate for rule building.  Do I need to disable the defulat LAN rule and make references on both interfaces?

      TIA

      1 Reply Last reply Reply Quote 0
      • H
        hoba
        last edited by

        Rules are ony applied on imcoming traffic. If you permit traffic it will generate a state so the other direction will be allowed for this state/connection as well. Besides that rules are applied top down, first match wins.

        1 Reply Last reply Reply Quote 0
        • I
          IanSVT
          last edited by

          Doesn't SMTP need DNS outbound to resolve MX records?  Would I create an inbound rule for DNS and that would automatically create the state for outbound?  Wouldn't I want, for security purposes, just outbound DNS for that specific server?

          1 Reply Last reply Reply Quote 0
          • H
            hoba
            last edited by

            Sorry but please reread. I don't even understand how you have inbound and outbound rules at the wan interface. This is not possible as we only allow to create inbound rules at an interface only.

            1 Reply Last reply Reply Quote 0
            • I
              IanSVT
              last edited by

              I'm sorry, I'm not following.  I figured outbound and inbound were determined on the usage of source/destination ports.  So if I want people to be able to get(inbound) to a webserver(10.1.1.5, which is carped and 1:1 NATed to a public IP) I allow anyone to access 10.1.1.15 on port 80 and that would create the outbound state to return the traffic.

              In any event, here are my WAN rules:

              
              Block 	*  	RFC 1918 networks  	            *  	 *  	*  	*  	Block private networks  	
              Block   * 	reserved/not assigned by IANA 	*    * 	    * 	    * 	Block private networks 	
              Block	TCP     * 	* 	WAN address 	21 (FTP) 	* 	  	
              Allow 	TCP 	* 	* 	10.1.1.18 	80 (HTTP) 	* 	
              Allow 	TCP 	* 	* 	10.1.1.5 	80 (HTTP) 	* 	 	
              Allow   TCP 	* 	* 	10.1.1.6 	80 (HTTP) 	* 	  	
              Allow   TCP 	* 	* 	10.1.1.17 	80 (HTTP) 	* 	 	
              Allow   TCP 	* 	* 	10.1.1.12 	80 (HTTP) 	* 	  	
              Allow   TCP 	* 	* 	10.1.1.12 	7777 	          * 	  	
              Allow   TCP 	* 	* 	10.5.5.9 	25 (SMTP) 	* 	  	
              Allow	TCP 	10.5.5.9 	25 (SMTP) 	* 	* 	* 	  	
              Allow	UDP 	* 	* 	* 	53 (DNS) 	* 	  	
              
              

              And here is my LAN rule

              
              Allow  *  	 LAN net  	 *  	 *  	 *  	 *  	 Default LAN -> any 
              
              

              Does this mean that everything from the LAN can go out?  Does that make the Allow TCP/25 from 10.5.5.9 on the WAN interface redundant?

              1 Reply Last reply Reply Quote 0
              • H
                hoba
                last edited by

                For the smtp server to work receiving traffic you only need a portforward and a firewallrule for port 25 at wan. The portforward can be set up at firewall>nat, portforward tab. If you keep the option autigenerate firewallrule checked it even will generate the needed rule at wan too. If you have the default lan to any rule still in place it allows anything from lan to wan. All other rules are not needed.

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

                  Allow TCP 10.5.5.9 25 (SMTP) * * *

                  is wrong, I think.

                  If you want this to allow your SMTP server to send out emails, it should be

                  Allow
                  Proto:TCP
                  Source Ip:  10.5.5.9 (if this is your SMTP servers IP address)
                  Source port: any
                  Destination ip: any
                  Dest port: 25 (SMTP)

                  This rule should be on the interface that is attached to the SMTP server, not the WAN

                  1 Reply Last reply Reply Quote 0
                  • H
                    hoba
                    last edited by

                    @sai:

                    Allow TCP 10.5.5.9 25 (SMTP) * * *

                    is wrong, I think.

                    If you want this to allow your SMTP server to send out emails, it should be

                    Allow
                    Proto:TCP
                    Source Ip:  10.5.5.9 (if this is your SMTP servers IP address)
                    Source port: any
                    Destination ip: any
                    Dest port: 25 (SMTP)

                    This rule should be on the interface that is attached to the SMTP server, not the WAN

                    Ho works with the default LAN to any rule, so this rule is not needed. He only needs the portforward and the autocreated rule. But first he should clean up all the other rules. There was just a basic misunderstanding how pfSense firewallrules work. I hope I explained things well enough to get it going now  ;)

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.