Allow ports 80 & 443 rule being ignored by Android apps running in background



  • Hi all.

    • I have an alias (Web) created which contains the two web ports, 80 & 443 (http/https).
    • On the LAN interface, I've created a rule to allow all outbound traffic with a destination port of (Web).
    • For troubleshooting purposes, the VERY LAST rule I have on the LAN interface is to block everything & LOG.
    • When I look at the log file, two devices (IP's 15 & 34) both have been blocked on ports 80 & 443 on outbound connections, i.e. they ignore the rule to allow outbound connections on these ports.

    Both these devices are Androids, and one of them is mine. I can confirm that when the log was generated, the Android was sitting idle, hence it was a background application that generated the http/https request.

    Normal http/https browsing works fine on the Android, so I'm guessing the application generating these requests in background is doing something strange that pfsense can't match to the allow web rule, hence its defaulting to the last rule which is to block & log.

    Any thoughts / comments on why these devices are being ignored by the allow rule?









  • You don't need that rule for pfsense. For instance, if you disable the anti-lockout rule without making any allow rules first you will be locked out unless that was fixed but I'm pretty sure that pfsense is still for the hardcore. Meaning that the way pfsense rules work for the Lan interface in particular is that you can put only what you want to allow and the default rule will drop everything else. Also, if I wanted to block something it would go before all of the allow rules because pfsense matches from top to bottom not bottom to top.

    This brings to mind the WAN interface which by default blocks everything except for the requests that you send out from the LAN to the WAN in order to reach the internet which means that when the connection is no longer needed it just drops off.  Just to be clear, nothing unsolicited will come through your WAN interface unless it's your gateway or you specifically allowed something.

    The reason I say it's your gateway on WAN is because let's say you go to youtube. What has to happen is that from your LAN interface(LAN NET) with destination port 443 destination address (any or you can get specific) will go out and search for youtube when you type it. Then what happens is youtube says hey this person wants to access my site so I'm going to go ahead and send an immediate response which does come back through the wan in order for you to be able to see the web page. This is perfectly normal. But let's say some hacker tries to get through the wan. He will have a difficult time unless you specifically allowed something that would possibly create a backdoor.



  • https://forum.pfsense.org/index.php?topic=79501.0 probably is the same case, and quoting Harvy66 below -

    PFSense is enforcing proper TCP. For whatever reason, the state for that TCP session does not exist. You can't send ACK packets for a session that does not exist, so PFSense blocks them.

    It was mentioned that asymmetrical routing is a common reason. This would agree with my wife's cellphone doing this a lot. I assume it's primarily when her cell phone switches between WIFI and 4G. I haven't wiresharked it, but that's because it doesn't happen often, but when it does, it happens in bursts.



  • @Cmellons:

    You don't need that rule for pfsense. For instance, if you disable the anti-lockout rule without making any allow rules first you will be locked out unless that was fixed but I'm pretty sure that pfsense is still for the hardcore.

    Thanks for that, I'm a newbie on pfSense & some after some digging around found out I had disabled the option to Log packets blocked by the default rule, then created a rule to cover what I had disabled.  ???

    @indecided:

    https://forum.pfsense.org/index.php?topic=79501.0 probably is the same case, and quoting Harvy66 below -

    Thanks for the link, appears to be the same kind of logging that I'm getting. It basically explains why I'm seeing these reported.