Strange firewall logs with captive portal



  • I am using a captive portal with the built in usermanager from pfsense.

    I am seeing allot of PASSED logs (so not blocked) in my firewall going to my captive portal interface (Wireless lan, subnet 10.0.0.0) and my captive portal status screen shows no logged in users?

    
    00:00:14.137884 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.58722:  tcp 36 
    00:00:14.998512 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.58723:  tcp 36 
    00:00:15.002240 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.58724:  tcp 36 
    00:00:15.001131 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.59301:  tcp 36 
    00:00:15.019500 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.59302:  tcp 36 
    00:00:04.603422 rule 16/0(match): pass out on run0_wlan0: 93.188.131.12.80 > 10.0.0.102.49242: [|tcp]
    00:00:15.001506 rule 16/0(match): pass out on run0_wlan0: 93.188.131.12.80 > 10.0.0.102.49243: [|tcp]
    00:00:14.982505 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.59303:  tcp 36 
    00:00:15.002623 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.59304:  tcp 36 
    00:00:15.023751 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.59305:  tcp 36 
    00:00:14.980129 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.59306:  tcp 36 
    00:00:14.998876 rule 16/0(match): pass out on run0_wlan0: 174.35.67.7.80 > 10.0.0.102.59307:  tcp 36 
    
    

    I am somewhat "scared" that it's allowing traffic on this interface even when users are not logged in? Also I'm seeing traffic inbound and not outbound when I look at the logs?
    How is this possible?

    edit: when I test the captive portal, by connecting to this wireless LAN with one of my laptops I get a login screen and I'm not allowed to go to any sites (keep getting captive login screen). When I log-in I can browse the internet. So everything seems to work.. but I don't understand why traffic is being accepted or sent to my clients which are not logged in on my captive portal?



  • The CP is implemented using the ipfw packet filter, which is different from the regular pf.



  • Does this mean that traffic is allowed in/out and it ignores my own firewall rules?
    That's a scary thought..

    Is it possible to fix this? I do not want any traffic on my WIFI interface except for 80/53/443 and I want only external access AFTER people are logged in.
    Where am I suppose to configure the captive portal firewall rules if it ignores my pfsense firewall rules?



  • As previously stated, Captive Portal is implemented on pfSense using ipfw. I believe ipfw will handle input traffic before pf (the standard pfSense firewall) and output traffic after pf.

    The log extract you posted shows traffic from port 80 on a server at 174.35.67.7. This is traffic passed by pf which is independent of captive portal. It doesn't mean ipfw will also pass the traffic. (I don't know whether ipfw passes or blocks such traffic when there are no active users.)

    @AudiAddict:

    I am somewhat "scared" that it's allowing traffic on this interface even when users are not logged in?

    That log is showing traffic allowed by pf, not traffic allowed by ipfw. The traffic is mostly TCP from a HTTP server. It is quite possible this traffic is the server probing a previously established TCP connection to see if the client is still "listening". I don't know if there is any mechanism for ipfw to notify pf that pf should now block traffic on particular flows because the user is now "logged out".

    @AudiAddict:

    Also I'm seeing traffic inbound and not outbound when I look at the logs?
    How is this possible?

    Please provide a specific example of your concern if you are not satisfied by the previous explanation. Note that firewalls can't stop "inbound" traffic (that is they can't stop another computer sending traffic to them).

    In short, you haven't provided any evidence that anything is "broken". I understand your concern. A packet capture on the interface is a far more reliable way of seeing traffic that is actually sent and received but a capture doesn't tell you what the firewall does with the traffic.


Locked