Bug @ pfSense_ipfw_Tableaction

  • In the captiveportal.inc, function portal_allow(), when

    			if (!isset($config['captiveportal'][$cpzone]['nomacfilter']))
    				$_gb = @pfSense_ipfw_Tableaction($cpzoneid, IP_FW_TABLE_XADD, 1, $clientip, $clientsn, $clientmac, $bw_up_pipeno);
    				$_gb = @pfSense_ipfw_Tableaction($cpzoneid, IP_FW_TABLE_XADD, 1, $clientip, $clientsn, NULL, $bw_up_pipeno);
    			if (!isset($config['captiveportal'][$cpzone]['nomacfilter']))
    				$_gb = @pfSense_ipfw_Tableaction($cpzoneid, IP_FW_TABLE_XADD, 2, $clientip, $clientsn, $clientmac, $bw_down_pipeno);
    				$_gb = @pfSense_ipfw_Tableaction($cpzoneid, IP_FW_TABLE_XADD, 2, $clientip, $clientsn, NULL, $bw_down_pipeno);

    the variable $clientip will hold the client IP, but when passed to pfSense_ipfw_Tableaction it will not be used, instead  the IP will allways be in the ipfw table.

    This function is at /usr/local/lib/php/20121212/pfSense.so
    I can't find the source.

    regards azurata

  • Under what circumstances do you get there? Not seeing that.

  • 1. fresh snapshot amd64 install with pfSense-memstick-2.2-BETA-amd64-20141105-1226.img;
    2. add user1 with captive portal login privilege;
    3. enable captive portal on lan and wan;
    4. try to open google.com and get redirected to the captive portal page and login as user1;
    5. redirected to google.com;
    6. check firewall table 1 and 2 with ipfw -x 2 table 1 list;ipfw -x 2 table 2 list;
    7. the IP of user1 at ipfw tables will be;
    8. kill user1
    9. check firewall table 1 and 2 with ipfw -x 2 table 1 list;ipfw -x 2 table 2 list;
    10. rule is still there and user is not redirected to the captive portal anymore.

    regards azurata

  • Hi,
    I write just to support  you azurata and say that i can reproduce this issue with FreeBSD 2.2 BETA 10.1-RC4-p1
    I allow myself to point your previous topic about this problem

    I can add that i have test with and without authentication, with or without mac filter, with i386 and x64 distro.
    If i flush table 1 et 2 after kill user, i can authenticate again but it disconnect all user and the issue stay the same.


  • This is an ipfw command issue and not a kernel issue.

    That command issue will be fixed before 2.2 release.

  • @cmb please push the fix to ipfw from your pfsense snapshot.

    Under what circumstances do you get there? Not seeing that.

    regards azurata

  • I have the same ipfw as the rest of you. I'll try the mentioned circumstance when I have a moment and make sure there's a bug ticket open with the exact specifics.

  • Hi,
    Perhaps tickets #4001 and #4002 on redmine are linked all together.

    @Ermal thanks for patching #4002 but the trouble with #4001 is still there.

    I've tried the last snapshot and it's better but an user who is disconnected from his session is blocked, and can't re-authenticate a second time.

    With the last snapshot (Thu Nov 13 06:05:47 CST 2014 ) ipfw tables 1 and 2 are now populated correctly with ip and mac address (and  not but when i kill one user, his records stay in tables 1 and 2… and i need to  flush manualy tables (and i kill all users... because i don't know how to flush only one ip/mac) to authenticate again.


  • Developer Netgate Administrator

    I've pushed fixes today, please try next round of snapshots

  • Hi,

    I've tried this morning. (built on Thu Nov 13 22:13:57 CST 2014 )
    It works (for me) like a charm.

    Thank you very  much


Log in to reply