UDP traffic not blocked after schedule expires
-
2.3.2-RELEASE-p1
Using an allow rule on an VLan for the kids. After 21:30 this allow rule expires. All connections are killed, but Skype session keeps up on that VLan. After inspection I can see an UDP connection (Skype) is active. Even after I manually kill this connection, it instantly returns. No TCP connections are made.
Am I doing something wrong, or did I ran into an bug?
Edit: Just thinking, could it be caused by UPnP?
-
Unless you have a separate block rule for Skype (or a default block ALL rule), Skype will happily reestablish its connections (and state) after the pass rule expires and correctly kills state.
The pfSense default is PASS all on LAN, so your scheduled skype pass rule is effectively redundant during the hours it's scheduled. What you need is a scheduled block rule for the opposite time period.
NOW, though we get to the real bug, which is that pfSense doesn't kill state when scheduled block rules become active. You're in luck, though: the best workaround is to have a scheduled pass rule (which you already have) that expires and kills state at the same time as the scheduled block rule becomes active. The better solution would be for the scheduled block rule to do its own state killing, but that's not yet implemented: https://forum.pfsense.org/index.php?topic=77168.msg665726#msg665726
-
Update…
There is no default PASS all rule because it’s on a vlan (not default LAN) so by default all traffic should be blocked.
To make sure I added an block all rule starting the same time the allow rule end.
I can confirm this is not working. So still (only) UDP traffic can pass despite expiration of allow rule and active block rule.
Just 15 minutes ago allow rule expired (and block rule is active) and one of the kids did not even notice and keeps on Skyping. When I look at the states, there is only one active (the UDP one). When I manually kill it, it’s back instant and Skype don’t notice it also.Only one thing worked: reboot pfSense.
I can’t really imagine that pfSense is so disrespectful to firewall rules. Am I doing something wrong, or is this a really nasty bug?
-
I had similar issues blocking teenagers devices (iphone, PC & Xbox), where Skype stayed online. The solution for me was to create a 24/7 block rule for the required devices, and than have Allow rules above it with schedules.
-
Create static DHCP entries for each device you want in the list.
-
Create an Alias for all the static IP's. (Alias cannot simply use MAC address)
-
Use this Alias for your 24/7 block rule and the scheduled rules.
-
-
I had similar issues blocking teenagers devices (iphone, PC & Xbox), where Skype stayed online. The solution for me was to create a 24/7 block rule for the required devices, and than have Allow rules above it with schedules.
-
Create static DHCP entries for each device you want in the list.
-
Create an Alias for all the static IP's. (Alias cannot simply use MAC address)
-
Use this Alias for your 24/7 block rule and the scheduled rules.
I have been playing with this for a couple years and also experience the UDP states not flushing correctly - kill them manually and they re establish straight away.
My setup is as you suggested above.
-
-
If they reestablish they are passed by a rule.
Pass the desired traffic using a scheduled rule followed by a rule that blocks everything (or no rules at all).
How about you post your rule set so we can see what you have done, instead of a description of what you think you have done.
-
LAN rules attached.
IPV6 is disabled.
Upnp is disabled.
-
Probably need to look at the states that you think should be blocked and see what rule created them.
I assume those blocked out aliases contain the source IP addresses you are trying to schedule?
When there is connectivity happening that you think should have been blocked, run this in Diagnostics > Command Prompt or the shell prompt
pfctl -vvss | grep -A 3 ip_address_of_host
Example: Me (192.168.223.6) ssh to the VM at 172.25.228.5. This is work done on 172.25.228.5:
pfctl -vvss | grep -A 3 192.168.223.6
re1 tcp 172.25.228.5:22 <- 192.168.223.6:64257 ESTABLISHED:ESTABLISHED
[3007015539 + 131028] wscale 7 [2084171029 + 66560] wscale 5
age 00:00:55, expires in 120:00:00, 2848:2849 pkts, 154293:429805 bytes, rule 127
id: 0000000059dd4dde creatorid: c64b4d20(above trimmed to the interesting traffic)
Then:
pfctl -vvsr | grep '^@127'
@127(0) pass in quick on re1 reply-to (re1 172.25.228.1) inet all flags S/SA keep state label "USER_RULE: Allow all ipv4 via pfSsh.php"
-
Thanks for the info..
First command worked, # pfctl -vvss | grep -A xxx.xxx.x.xxx did not work, no output.
I used pftop, set to 'label' and found the rule that is keeping the UDP session is #80 -'let out anything from firewall host itself'..
Shouldn't my block rule take care of this?
-
How about actually posting the states in question?
-
How about actually posting the states in question?
The state in question after the pass schedule expires -
@80(1000002761) pass out log route-to (pppoe1 xxx.xx.xxx.xx) inet from xxx.xxx.xxx.xxx to ! xxx.xxx.xxx.xxx flags S/SA keep state allow-opts label "let out anything from firewall host itself"
Shouldn't a block any rule on the LAN rules I posted above stop this from happening?
-
Another expired schedule - still active states
pppoe1 tcp xxx.xxx.205.53:7104 (192.168.1.200:56803) -> 104.24.115.111:443 ESTABLISHED:ESTABLISHED
[1310735961 + 111616] wscale 8 [3731195127 + 714584] wscale 10
age 02:07:54, expires in 23:56:06, 2763:4823 pkts, 139530:7088860 bytes, rule 80
id: 0000000059998d6d creatorid: fb128bc1
–
pppoe1 tcp xxx.xxx.205.53:19708 (192.168.1.200:56961) -> 184.87.121.47:443 ESTABLISHED:ESTABLISHED
[1523828575 + 128992] wscale 8 [3293443788 + 65280] wscale 5
age 01:37:40, expires in 23:56:21, 264:361 pkts, 60389:283996 bytes, rule 80
id: 000000005999a3b6 creatorid: 083854cc
–
pppoe1 tcp xxx.xxx.205.53:29934 (192.168.1.200:56887) -> 104.16.59.37:443 ESTABLISHED:ESTABLISHED
[2193638097 + 43008] wscale 8 [2872928872 + 65426] wscale 10
age 01:50:30, expires in 23:56:59, 13302:14887 pkts, 545051:4006334 bytes, rule 80
id: 010000005995b51b creatorid: cd60a119
pppoe1 tcp xxx.xxx.205.53:44287 (192.168.1.200:53452) -> 111.221.29.92:443 ESTABLISHED:ESTABLISHED
[2235807986 + 6905] wscale 8 [1184586678 + 64891] wscale 0
age 06:04:04, expires in 23:56:25, 51:31 pkts, 6740:8513 bytes, rule 80
id: 000000005998b51e creatorid: cfd77895
–
pppoe1 tcp xxx.xxx.205.53:17171 (192.168.1.200:53591) -> 108.177.97.188:5228 ESTABLISHED:ESTABLISHED
[2327943397 + 47104] wscale 8 [715977687 + 65660] wscale 8
age 06:03:40, expires in 23:56:35, 516:515 pkts, 22998:32389 bytes, rule 80
id: 000000005998b595 creatorid: cfd77895
–
pppoe1 tcp xxx.xxx.205.53:41699 (192.168.1.200:53930) -> 77.234.41.25:80 ESTABLISHED:ESTABLISHED
[4111583925 + 16384] wscale 8 [3062596744 + 305594] wscale 13
age 06:00:57, expires in 23:59:39, 344:608 pkts, 45046:560917 bytes, rule 80
id: 0100000059953ee1 creatorid: f3f915ea
–
pppoe1 tcp xxx.xxx.205.53:35750 (192.168.1.200:53516) -> 111.221.29.129:443 ESTABLISHED:ESTABLISHED
[1963077451 + 8192] wscale 8 [1333848027 + 65915] wscale 0
age 06:03:59, expires in 23:55:42, 52:33 pkts, 7089:9014 bytes, rule 80
id: 030000005995450a creatorid: cfd77895
–
pppoe1 tcp xxx.xxx.205.53:25622 (192.168.1.200:57333) -> 104.16.58.5:443 ESTABLISHED:ESTABLISHED
[1312314967 + 33792] wscale 8 [955395054 + 66048] wscale 10
age 00:03:31, expires in 23:56:29, 15:14 pkts, 1413:7103 bytes, rule 80
id: 030000005995e5ba creatorid: 12e8ec5e
pppoe1 tcp xxx.xxx.205.53:45977 (192.168.1.200:57335) -> 60.254.148.10:80 ESTABLISHED:ESTABLISHED
[953442817 + 30272] wscale 3 [242617014 + 262144] wscale 5
age 00:03:31, expires in 23:56:29, 4:4 pkts, 449:2051 bytes, rule 80
id: 030000005995e5bc creatorid: 12e8ec5e
–
pppoe1 tcp xxx.xxx.205.53:16952 (192.168.1.200:57326) -> 111.221.29.254:443 TIME_WAIT:TIME_WAIT
[2336466661 + 132096] wscale 8 [2627898276 + 64832] wscale 8
age 00:03:58, expires in 00:01:29, 8:8 pkts, 3214:4547 bytes, rule 80
id: 000000005999e9c5 creatorid: 12e8ec5e
pppoe1 tcp xxx.xxx.205.53:58183 (192.168.1.200:57328) -> 172.217.25.163:443 ESTABLISHED:ESTABLISHED
[2813417892 + 44032] wscale 8 [1302333566 + 66048] wscale 8
age 00:03:41, expires in 23:56:19, 9:9 pkts, 809:4667 bytes, rule 80
id: 000000005999e9fb creatorid: 12e8ec5e
pppoe1 tcp xxx.xxx.205.53:25889 (192.168.1.200:57330) -> 104.20.75.196:80 ESTABLISHED:CLOSING
[3334405779 + 30720] wscale 8 [314514731 + 66047] wscale 10
age 00:03:39, expires in 00:12:07, 4:7 pkts, 443:848 bytes, rule 80
id: 000000005999ea02 creatorid: 12e8ec5e
–
pppoe1 tcp xxx.xxx.205.53:61313 (192.168.1.200:57329) -> 184.87.121.47:443 ESTABLISHED:ESTABLISHED
[3186924564 + 33184] wscale 8 [3309381952 + 66560] wscale 5
age 00:03:40, expires in 23:56:20, 10:11 pkts, 2447:8474 bytes, rule 80
id: 020000005995f894 creatorid: 12e8ec5e
pppoe1 tcp xxx.xxx.205.53:28969 (192.168.1.200:57334) -> 60.254.148.10:80 ESTABLISHED:ESTABLISHED
[2468430302 + 30272] wscale 3 [4177331865 + 262144] wscale 5
age 00:03:31, expires in 23:56:29, 4:4 pkts, 449:2284 bytes, rule 80
id: 020000005995f8a6 creatorid: 12e8ec5e -
Those are all on WAN, not on LAN. There will be no traffic permitted from the host to the destination because the LAN state no longer exists (presumably because the schedule expired).
All of this code comes from a time when it was very difficult to match up the LAN state with the WAN state in a reliable way.
I do not know if that has changed.
But without a state on the LAN interface passing the traffic into the firewall, the traffic will not be passed regardless of those states on WAN.
You can compare to the same commands when traffic should be flowing.
Also, none of those states are UDP, which is the subject of the thread.
-
My mistake - here is the output from a laptop I setup for testing. Again, UDP states are open after schedule expires.
–
igb1 udp 192.168.1.254:67 <- 192.168.1.117:68 MULTIPLE:MULTIPLE
age 01:12:54, expires in 00:00:38, 146:146 pkts, 49494:47888 bytes, rule 68
id: 0100000059958261 creatorid: 60743c4a
pppoe1 tcp 120.146.205.53:15500 (192.168.1.101:54966) -> 72.216.11.163:54483 TIME_WAIT:TIME_WAITigb1 udp 155.133.227.11:27019 -> 192.168.1.117:54771 MULTIPLE:MULTIPLE
age 00:03:10, expires in 00:00:57, 37:70 pkts, 6848:21216 bytes, rule 78
id: 000000005996c40b creatorid: 0ee73808
igb1 tcp 61.9.129.150:80 <- 192.168.1.200:58542 ESTABLISHED:ESTABLISHEDpppoe1 tcp 120.146.205.53:33307 (192.168.1.117:2658) -> 111.221.29.89:443 ESTABLISHED:ESTABLISHED
[1299936452 + 7612] wscale 8 [3593757052 + 65792] wscale 0
age 01:09:37, expires in 23:49:51, 23:16 pkts, 2994:6200 bytes, rule 80
id: 0300000059955e7f creatorid: 60743c4a–
pppoe1 udp 120.146.205.53:41509 (192.168.1.117:54771) -> 155.133.227.11:27019 MULTIPLE:MULTIPLE
age 01:13:31, expires in 00:00:57, 1015:792 pkts, 307344:467152 bytes, rule 80
id: 0000000059967d80 creatorid: 60743c4a
igb1 tcp 104.116.169.238:443 <- 192.168.1.211:50326 CLOSING:ESTABLISHED -
How about you explain what traffic should not be there and show what the various rules are?
Can't read minds and you obfuscated your actual rules.
-
How about you explain what traffic should not be there and show what the various rules are?
Can't read minds and you obfuscated your actual rules.
While you have provided some help, you have mostly wasted my time.
Please do not try and help any further.
-
Best of luck to you.
