Odd Firewall Behavior
-
I have two main issues/concerns with the firewall rules and/or implementation of them in pfSense. The first showed up after migrating to 2.2.2 from 2.2.1, the second I haven’t been able to get working via rules, but it should.
I appreciate the assist and insight you all can provide. Thanks.
Background: I have two (2) HP t5740s running pFsense – one live, the other for testing. The live one is a 4G nanobsd, 3GB RAM, with WAN/LAN/OPT1, two OpenVPN client connections, a L2TP/IPsec server, and an SSH server + numerous inbound port forwards to various devices on the LAN. I started with 2.1.5, then 2.2, then 2.2.1, and am now 2.2.2. For packages, I have the following currently installed: Squid3 (not configured yet), SquidGuard (not configured yet), and Cron.Issue 1: After about 24 hours of ‘up’ time, then pfSense Firewall Rule set forgets ALL of the inbound open ports and I cannot VPN or SSH into the device from external connections. Outbound rules work fine and it doesn’t affect any of the Internet ‘experience’ for the users when the inbound rules are broken. I route all of my inbound port redirects over one of the two OpenVPN connections, but I don’t think this is an OpenVPN or provider issue as I have not changed that configuration in 6 weeks and this only showed up when I upgraded to 2.2.2. If I reboot the router, then the inbound port forwards work fine again. I can easily put in a cron job to reboot the router in the overnight hours, but it seems a little overkill for something that was previously working fine.
Issue 2: I have a Vonage ATA attached as the only device on OPT1. Before migrating to pfSense, I used DD-WRT for my firewall/router/OpenVPN client needs. One of the things I could do was restrict devices access to the Internet by time (Access restrictions). I easily created firewall rules with time periods for the ATA (and other devices) which for the most part work, except for the Vonage ATA. Once it connects to the Vonage network, even after the time has passed to block access, it is still accessible from the Internet (ie, a SIP session is initiated and the phone rings), but the ATA cannot call out or actually answer the call. (I do this since we are in Europe to block telemarketers from calling in the middle of our night.) I have rules to block ANY to/from OPT1, but it still didn’t do anything. I created two cron jobs – one to take the OPT1 interface down at the designated time everything and another to bring it up in the morning. [/sbin/ifconfig opt1 down || /sbin/ifconfig opt1 up] That seems to work fine, but seems to be a little overkill for something that the ruleset should easily control. Of course, now I’ve limited any other device on OPT1 to those operating hours. I don’t think this is related to Issue #1 as I would see the problem immediately when OPT1 is taken down.
I know these are two distinct problems/issue, but the first may be a bug in 2.2.2, so I’m willing to revert back to 2.2.1 OR go ahead and build a cron job to reboot as 2.2.2 has some good security patches.
Thoughts?
Thanks.
-
Issue#2: If a scheduled rule is in place to block stuff, then when it comes time to block there is no easy way for pfSense to find existing states that should be killed because they now should be blocked by the block rule. So those states keep going. For phone systems and other apps that keep "saying hello" between themselves states like that will get kept alive constantly.
Try doing your rules the other way around. Put a pass rule for the Vonage traffic with a schedule of the times you want it to work. Then immediately after that pass rule put a block rule for the same traffic without any schedule. pfSense should be able to track the states that match the pass rule, and when the pass rule is taken out of schedule, any corresponding states should get killed. -
Thanks Phil.
That does seem a little counter intuitive, but in a way it makes sense.
I took it a little further and changed the state type to "none" and it seems to be holding in the 'off' position. I'll have to confirm in the morning if there were any ill affects when the traffic is allowed to flow again. Granted, the "none" state type may be overkill, but when it initially went to blocking mode, the state would keep coming back even after being killed when I had it set to "keep state". Setting to "none" kept them off.
-
Update.
There is a two step process to time limit the Vonage (and any other device with active states).
Step 1) Put rules in place to block the traffic. (Per the above suggestion, I have an allow rule with a schedule, then a block rule without schedule. A simple block rule that has the 'off' time may be sufficient.)
The rules ONLY affect NEW traffic. Any existing states are not affected when the rule goes into effect. For Vonage there was a steady state on port 10000 between my device and the Vonage servers.
Step 2) Add a cron job to execute 1 minute after the rule goes into affect, utilizing the following: /sbin/pfctl -k 0.0.0.0/0 -k 192.168.10.10
The job kills all states with a destination of my Vonage device (192.168.10.10 in this case). The 0.0.0.0/0 is a wildcard. This kills the inbound state, the outbound state will die relatively quickly.
Also, by taking hard interface status change [/sbin/ifconfig opt1 up] out of the equation, the pfSense box doesn't loose the inbound port forwards on the VPN anymore and I can SSH, so something was breaking the status of the VPN connection. Anyway, happy to report that fixing issue #2 also took care of issue #1.