Firewall Rule - Advanced Options



  • We're a Public Library running v1.2-RELEASE in a 6 zone (wan, wan2, lan, lan2, dmz, wifi) configuration.

    Lately, Wifi users are swamping our firewall (connections over 10,000) with P2P traffic.

    The wifi zone has a very simple "allow everything" outbound rule:

    • WIFI net   *   *   *   63.225.xxx.yyy       Wifi Net -> ANY

    I've added these rules under the "Advanced Options" for that Rule:
    Simultaneous client connection limit  750
    Maximum state entries per host  25
    Maximum new connections / per second   5/1
    State Timeout in seconds  120

    Unfortunately that does NOT seem to be working.

    Reading thru the forum, it was stated that #1 Sim client connections and #3 Max new connections applied to the entire rule (i.e. all wifi clients) and that #2 applied to each host.

    If so, and with that set to 25 (per host), why am I getting hosts with 193+ connections (see attached "states" report for 1 user IP)?

    The goal is to prevent P2P WiFi users from causing the Firewall to drop traffic due to too many connection states.

    Unfortunately, that does not seem to be working, and the new "advance options" rules are causing trouble for normal Wifi web/email users (dropped connections, page load errors, can't connect, etc.).

    Thanks - VS
    wifi-problem_user.txt



  • No one?  Bueller?  Anyone?

    Since these are in the core PFSense Firewall Rules - and seem not to have ANY documentation - and seem to be buggy (although I could just be guessing wrong on how to use/apply them) - I would have thought that at least ONE PFSense developer could chime in and help straighten this out.

    Would it help if I said "please"?  If so, would someone PLEASE help me figure this out - especially since it seem like a bug since the max connections per host does NOT work.



  • I am not developer but can you try to use 'default' gateway instead of specifying one? It's been know that using this field greately affects pf's behaviour.
    It would be interesting to have a look at your rules with this advanced options:
    pfctl -sr | grep



  • Thanks for replying Eugene!

    I need to use the listed gateway - we have a dual WAN (T1 for staff, DSL for public) and can't put the wifi (Public) traffic on the T1 which run's critical SAAS for the library.

    Here's the output you requested:

    # pfctl -sr | grep dc4
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19003 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19007 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19011 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19015 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19019 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19023 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19027 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19031 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19035 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19039 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19043 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19047 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19051 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19055 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = 19059 keep state label "NAT REFLECT: Allow traffic to localhost"
    pass in quick on dc4 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps label "allow access to DHCP server"
    pass in quick on dc4 inet proto udp from any port = bootpc to 10.1.1.254 port = bootps label "allow access to DHCP server"
    pass out quick on dc4 inet proto udp from 10.1.1.254 port = bootps to any port = bootpc label "allow access to DHCP server"
    block drop in on ! dc4 inet from 10.1.1.0/24 to any
    block drop in on dc4 inet6 from fe80::2a0:ccff:fe5f:b851 to any
    pass out quick on dc4 all keep state label "let out anything from firewall host itself"
    pass out quick on dc4 proto icmp all keep state label "let out anything from firewall host itself"
    pass out quick on dc4 all keep state label "let out anything from firewall host itself"
    pass in quick on dc4 inet from 10.1.1.109 to <vpns> keep state label "NEGATE_ROUTE: Negate policy route for local network(s)"
    pass in quick on dc4 route-to (dc0 63.225.115.30) inet from 10.1.1.109 to any keep state label "USER_RULE: Child (STAFF) Dept. WiFi Connection"
    pass in quick on dc4 inet from 10.1.1.0/24 to <vpns> keep state (source-track rule, max-src-states 75, max-src-conn-rate 15/1, max-src-nodes 1500, overload <virusprot> flush global, tcp.established 300, src.track 1) label "NEGATE_ROUTE: Negate policy route for local network(s)"
    pass in quick on dc4 route-to (dc0 63.225.xxx.yyy) inet from 10.1.1.0/24 to any keep state (source-track rule, max-src-states 75, max-src-conn-rate 15/1, max-src-nodes 1500, overload <virusprot> flush global, tcp.established 300, src.track 1) label "USER_RULE: Wifi Net -> ANY"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = spamd keep state label "FTP PROXY: Allow traffic to localhost"
    pass in quick on dc4 inet proto tcp from any to 127.0.0.1 port = ftp keep state label "FTP PROXY: Allow traffic to localhost"</virusprot></virusprot></vpns></vpns>
    


  • Interestingly according to

    pass in quick on dc4 route-to (dc0 63.225.xxx.yyy) inet from 10.1.1.0/24 to any keep state (source-track rule, max-src-states 75, max-src-conn-rate 15/1, max-src-nodes 1500, overload <virusprot> flush global, tcp.established 300, src.track 1) label "USER_RULE: Wifi Net -> ANY"</virusprot>
    

    I would assume that:
    75 - max number of simultaneous state entries that can be created per source IP address
    max 15 connections per second
    1500 - max number of source IP addresses that can simultaneously create state.



  • I'm not sure what you're saying.

    The max connections is set to 75 - yet it's allowing WAY more then that (see attached log snippet in my first post).

    So either I don't understand how to correctly apply that rule (which would help prevent the firewall from being flooded with connection states by p2p clients) or that rule does NOT work in PFSense.



  • Do you have more than just this single rule on the WiFi interface?



  • There are at least two rules created by user on WiFi interface:
    pass in quick on dc4 route-to (dc0 63.225.115.30) inet from 10.1.1.109 to any keep state label "USER_RULE: Child (STAFF) Dept. WiFi Connection"
    pass in quick on dc4 route-to (dc0 63.225.xxx.yyy) inet from 10.1.1.0/24 to any keep state (source-track rule, max-src-states 75, max-src-conn-rate 15/1, max-src-nodes 1500, overload <virusprot>flush global, tcp.established 300, src.track 1) label "USER_RULE: Wifi Net -> ANY"</virusprot>



  • Only the main rule with the Advanced-Options set.

    The other rule is disabled (now deleted).  It was an attempt to have the ONE Staff laptop that uses the WiFi bypass the general WiFi advance-option rules.  That didn't work either, so I moved that laptop to a wired connection until I can get the WiFi setup as needed (i.e. stop p2p users from swamping the Firewall with 10,000's of connection states).



  • That is interesting topic. First of all we have to be sure that  settings from GUI go correctly to pf rules. I'll try to reproduce it.


Log in to reply