SMTP Server/rules



  • 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



  • 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.



  • 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?



  • 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.



  • 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?



  • 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.



  • 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



  • @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  ;)


Log in to reply