Blocking a specific net from reaching a portforwarded ip/port



  • I have portforwarded my "outside" port 25 to a DMZ 192.168.x.x ip addr.
    And have set "any" to be able to reach the server on port 25.

    Now i'd like to deny 91.200.12.0/24  from connecting to it (Ukrainian mail spammer net)

    At the moment i have added a block rule on the Wan IF:
    block 91.200.12.0/24  , any , dest TCP/25

    If i wanted to make it more specific , ie. just blocking the DMZ server.

    Should i then use the wan (outside) , or the Xlated IP  (192.168.x.x/32 DMZ address) , as the dest ip

    My gut tells me that it should be the 192.168.x.x , as the NAT might be done before the rule is hit , but i thought i'd just ask before trying.

    TIA
    /Bingo



  • Install package suricata



  • @bingo600:

    Now i'd like to deny 91.200.12.0/24  from connecting to it (Ukrainian mail spammer net)

    At the moment i have added a block rule on the Wan IF:
    block 91.200.12.0/24  , any , dest TCP/25

    If i wanted to make it more specific , ie. just blocking the DMZ server.

    You're to kind ;)
    I wouldn't enter "dest TCP/25" but default to any at first. Thus blocking 91.200.12 to whatever.
    "Set if and forget it" for a while. When the rule counter goes zero, remove the rule.

    Btw : I'm not an expert, but I 'think' the firewall rule comes first, and NAT will be handled afterwards.


  • LAYER 8 Global Moderator

    No the nat rule is looked at first, but would not be allowed unless there is a firewall rule.  You could just put it in one rule with the use of ! or not or inverted however you want to call it… So your forwarding 25 to 192.168.9.50 lets say... In that rule just put a ! source saying anything But 91.200.12.0/24, you end up with this.. see attached.

    But some people don't like ! rules, so yes you can just put a rule above the rule that your port forwarded created.. See second attachment.

    https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order

    More accurately, the following order (still simplified) is found in the ruleset (Check /tmp/rules.debug):

    Outbound NAT rules
      Inbound NAT rules such as Port Forwards (including rdr pass and UPnP)
        NAT rules for the Load Balancing daemon (relayd)
        Rules dynamically received from RADIUS for OpenVPN and IPsec clients
        Internal automatic rules (pass and block for various items like lockout, snort, DHCP, etc.)
        User-defined rules:
            Rules defined on the floating tab
            Rules defined on interface group tabs (Including OpenVPN)
          Rules defined on interface tabs (WAN, LAN, OPTx, etc)
        Automatic VPN rules

    But with a rule like this why would you want/need to be specific - the only reason you would need to be specific is if you wanted to allow that netblock access to other stuff other than smtp.. If they are spammers why would you want to have them be able to even ping your wan, etc.  Just block them outright to any above you port forward wan rule that allows access to 25.






  • Instructive.
    Thanks !



  • @johnpoz:

    But with a rule like this why would you want/need to be specific - the only reason you would need to be specific is if you wanted to allow that netblock access to other stuff other than smtp.. If they are spammers why would you want to have them be able to even ping your wan, etc.  Just block them outright to any above you port forward wan rule that allows access to 25.

    This, plus there are a whole lot more spam sources out there.  Are you going to manually create a rule for each one?  That way madness lies.

    Try Suricata or a VM with postfix to front-end your mail server or maybe even the unofficial postfix package - any of these with zen.spamhaus.org



  • @johnpoz:

    More accurately, the following order (still simplified) is found in the ruleset (Check /tmp/rules.debug):

    Outbound NAT rules
      Inbound NAT rules such as Port Forwards (including rdr pass and UPnP)
        NAT rules for the Load Balancing daemon (relayd)
        Rules dynamically received from RADIUS for OpenVPN and IPsec clients
        Internal automatic rules (pass and block for various items like lockout, snort, DHCP, etc.)
        User-defined rules:
            Rules defined on the floating tab
            Rules defined on interface group tabs (Including OpenVPN)
          Rules defined on interface tabs (WAN, LAN, OPTx, etc)
        Automatic VPN rules

    Thank you - informative  :D

    /Bingo



  • @biggsy:

    any of these with zen.spamhaus.org

    I'm looking into combining zen.spamhaus.org with my sendmail
    But just got annoyed at that /24 , as it kept hammering my mail-logs (they actually list it as a /22 doing noise on spamhaus)

    I was just trying out possibilities , to get a feeling of pfsense possibilities  -  (comming from a PIX/ASA world)

    /Bingo


Log in to reply