Alias firewall block rule not blocked!

mrsunfire

Hi!

I use an Alias for some clients to block access to WAN. For this I made a block rule on LAN. For two of the clients it works, but for one (192.168.1.17) of them it doesn't. I was wondering why pfTop shows traffic from that client to WAN so I setup a separat rule for that client and then it works as you can see below. I setup the Alias as Hosts and entered every single IP. On firewall logs I see that the 192.168.1.18 gets blocked by the rule with the Alias, the 192.168.1.17 gets blocked by the new rule I made only for that client even it is below the rule with Alias where that client already is in.

But why?

KOM

Existing active states are not affected by new firewall rule changes. Clear the active states for that connection and then try your test again.

mrsunfire

I did, I even rebootet the pfSense and the client. Nothing worked! I now deleted the Alias and created it new 1:1. Now it works! Very strange...

bmeeks

@mrsunfire said in Alias firewall block rule not blocked!:

I did, I even rebootet the pfSense and the client. Nothing worked! I now deleted the Alias and created it new 1:1. Now it works! Very strange...

Could you have had a space (like a trailing space, perhaps) in your alias? I have not looked at the pfSense PHP code for the Alias page to see if it scrubs input for trailing spaces. I have been the victim of that trailing space thing in other situations not involving pfSense (like a Windows filename, for example). This problem is very hard to detect because a trailing space is going to be invisible on the screen. Sometimes you can tell it's there by going to the end of a line and then you notice an extra space, but then sometimes that trick does not work. The fact deleting and then recreating the alias fixed the problem points to having a hidden character in there maybe.

mrsunfire

Well the Alias „worked“. One IP and the FQDN worked. Only the other IP not. There was nothing special in it and I did the same again and now it works.

bmeeks

'192.168.1.17"@mrsunfire said in Alias firewall block rule not blocked!:

Well the Alias „worked“. One IP and the FQDN worked. Only the other IP not. There was nothing special in it and I did the same again and now it works.

Unless I misunderstood what you wrote and posted originally, you created an alias called NoWAN and put three entries in it. One of those was a hostname "drucker" and the other two were actual IP addresses. The host name would have been internally converted to an IP by the pfSense code. What I am saying is maybe when you put the 192.168.1.17 IP address in you inadvertently had a trailing space on the end when you typed it into the text box on the alias creation page. So instead of just "192.168.1.17" you actually had "192.168.1.17 " (notice the extra space after the 17). To a computer "192.168.1.17 " is not the same as "192.168.1.17". You would not have been able to see this trailing space on the screen. When you deleted the alias the trailing space entry would have also been removed. When you created it again the trailing space was not there and so things worked as expected.

This is just a theory based on having this type of event happen to me in the past on other platforms. It's easy to typo a trailing space on something and then you can't see it's there to fix it. Some software will automatically scrub user-typed input to remove trailing spaces, but not always. I need to check the pfSense code to see if it does that when letting the user create alias entries.

johnpoz

If you put a trailing space on it - pfsense balks at you

bmeeks

@johnpoz said in Alias firewall block rule not blocked!:

If you put a trailing space on it - pfsense balks at you

Thanks for the quick test! So my theory is not valid. pfSense apparently does a good job of input scrubbing.

johnpoz

Without seeing is full rule set, floating even and his current states its not really possible to understand what the issue might of been.

Its quite possible this .17 had a state open to internet he was testing with.. Which is why it was working when he first put in the rule.. Or for that matter maybe the .17 uses proxy..

KOM really hit it on the nose - and it causes many users misunderstanding of how rules and when they get applied..

bmeeks

@johnpoz said in Alias firewall block rule not blocked!:

Without seeing is full rule set, floating even and his current states its not really possible to understand what the issue might of been.

Its quite possible this .17 had a state open to internet he was testing with.. Which is why it was working when he first put in the rule.. Or for that matter maybe the .17 uses proxy..

KOM really hit it on the nose - and it causes many users misunderstanding of how rules and when they get applied..

I agree it could have been an active state, but it is puzzling still as the state should still have been in place when he added that independent rule with just the IP and not the alias. So I would expect that extra rule to not block either. Of course, we don't know the full extent of what the rules in force were at the time.

That trailing space thing is just etched in my brain now because I've been victimized several times by it over the years. Most recently about two months ago on my wife's Windows 10 machine where she complained about not being able to delete a directory. Turns out, after much investigation, it was the trailing space thing again.

mrsunfire

There was no active state. I checked it multiple times with pfTop. Even after reboot the .17 got wide open access to internet. The Alias had no problem, no extra space or something else. I now created it exactly the same and now also the .17 gets blocked.

I only have 1 Floating rule for ICMPv6, nothing special on LAN. The Alias always is on top of course. There is no proxy setup.

Derelict

If the IP address was in the alias and there was no active state it would have been blocked.

If something else was the result then there was a reason for it. Finding that reason is the trick.

When you have an active state you can use pfctl to find which rule passed the connection should you desire to dig that deep. If I had traffic I thought should be blocked that wasn't, I would want to know why.

mrsunfire

There should be no active state after a reboot. I now did the same as before and now the IP gets blocked. If I could simulate that error again, I would do that.

Derelict

It was user error. You did not find a bug in pf that passed blocked traffic.

mrsunfire

Then how do you explain from my first screen that the alias is on top and the .17 IP is on 3th line of rules. But that one blocks the traffic and the alias did not?

Derelict

User error. Not understanding what you are looking at. State established before the rule was in place. Some other rule passing the traffic.

mrsunfire

So the state stays established even after a reboot? I can't believe that...

Derelict

No. The state was re-established after you rebooted because a firewall rule passed the traffic.

mrsunfire

I restored the firewall rules to an earlier date and rebooted the machine. The alias is still the same and now the .17 again gets access. How to find out what rule is the problem?

Derelict

pfctl -vvss | grep -A3 192.168.1.17

Find the state you think should not be there out of that. Post it.

mrsunfire

@Derelict said in Alias firewall block rule not blocked!:

pfctl -vvss | grep -A3 192.168.1.17

igb4 udp 192.168.1.1:53 <- 192.168.1.17:50872       NO_TRAFFIC:SINGLE
   age 00:00:55, expires in 00:00:05, 1:0 pkts, 56:0 bytes, rule 164
   id: 010000005cd28985 creatorid: 3dddfb2a
igb4 udp 192.168.1.255:32414 <- 192.168.1.10:55418       NO_TRAFFIC:SINGLE
--
igb4 udp 192.168.1.1:53 <- 192.168.1.17:43906       NO_TRAFFIC:SINGLE
   age 00:00:55, expires in 00:00:05, 1:0 pkts, 59:0 bytes, rule 164
   id: 010000005cd28988 creatorid: 3dddfb2a
igb5 ipv6-icmp ff02::1[192] <- fe80::201:5cff:fe6b:e046[192]       NO_TRAFFIC:NO_TRAFFIC
--
igb4 udp 114.55.218.176:32100 <- 192.168.1.17:27288       NO_TRAFFIC:SINGLE
   age 00:00:48, expires in 00:00:12, 1:0 pkts, 32:0 bytes, rule 178
   id: 010000005cd28a38 creatorid: 485eb46e
igb4 udp 47.91.90.222:32100 <- 192.168.1.17:27288       NO_TRAFFIC:SINGLE
   age 00:00:48, expires in 00:00:12, 1:0 pkts, 32:0 bytes, rule 178
   id: 010000005cd28a39 creatorid: 485eb46e
igb4 udp 192.168.1.1:161 <- 192.168.1.10:56756       MULTIPLE:MULTIPLE
--
igb4 udp 107.20.134.235:32100 <- 192.168.1.17:27288       NO_TRAFFIC:SINGLE
   age 00:00:48, expires in 00:00:12, 1:0 pkts, 32:0 bytes, rule 178
   id: 000000005cd28acc creatorid: 485eb46e
igb4.300 udp 8.8.8.8:53 <- 10.0.2.2:45009       NO_TRAFFIC:SINGLE
--
igb4 udp 192.168.1.1:53 <- 192.168.1.17:51499       SINGLE:MULTIPLE
   age 00:00:33, expires in 00:00:00, 1:1 pkts, 56:72 bytes, rule 181
   id: 000000005cd28c1a creatorid: b13ad8d2
igb5 udp 2a02:8071:800:0:527:2af9:a20f:552a[41679] -> 2001:8d8:fe:53:0:d9a0:52c2:100[53]       MULTIPLE:SINGLE
--
igb4 udp 107.20.134.235:32100 <- 192.168.1.17:25029       SINGLE:MULTIPLE
   age 00:00:33, expires in 00:00:00, 1:1 pkts, 32:48 bytes, rule 181
   id: 000000005cd28c1b creatorid: b13ad8d2
igb5 udp xxx:64148 -> 217.160.83.194:53       MULTIPLE:SINGLE
--
igb5 udp xxx:57526 (192.168.1.17:25029) -> 107.20.134.235:32100       MULTIPLE:SINGLE
   age 00:00:33, expires in 00:00:00, 1:1 pkts, 32:48 bytes, rule 141
   id: 000000005cd28c1c creatorid: b13ad8d2
igb5 udp 2a02:8071:800:0:527:2af9:a20f:552a[45428] -> 2001:503:e239::3:2[53]       MULTIPLE:SINGLE
--
igb4 udp 192.168.1.1:53 <- 192.168.1.17:35486       SINGLE:MULTIPLE
   age 00:00:33, expires in 00:00:00, 1:1 pkts, 61:77 bytes, rule 181
   id: 010000005cd28c21 creatorid: b13ad8d2
igb4 udp 107.20.134.235:32100 <- 192.168.1.18:10092       MULTIPLE:MULTIPLE
--
igb4 udp 114.55.218.176:32100 <- 192.168.1.17:25029       NO_TRAFFIC:SINGLE
   age 00:00:33, expires in 00:00:27, 1:0 pkts, 32:0 bytes, rule 181
   id: 010000005cd28c22 creatorid: b13ad8d2
igb5 udp xxx:41955 (192.168.1.18:10092) -> 107.20.134.235:32100       MULTIPLE:MULTIPLE
--
igb5 udp xxx:10147 (192.168.1.17:25029) -> 114.55.218.176:32100       SINGLE:NO_TRAFFIC
   age 00:00:33, expires in 00:00:27, 1:0 pkts, 32:0 bytes, rule 141
   id: 010000005cd28c23 creatorid: b13ad8d2
igb4 udp 2a02:8071:889:c500:4262:31ff:fe07:2bdc[53] <- 2a02:8071:889:c500:f525:878c:30fa:1bb5[50603]       SINGLE:MULTIPLE
--
igb4 udp 47.91.90.222:32100 <- 192.168.1.17:25029       SINGLE:MULTIPLE
   age 00:00:33, expires in 00:00:00, 1:1 pkts, 32:48 bytes, rule 181
   id: 010000005cd28c24 creatorid: b13ad8d2
igb4 udp 192.168.1.1:53 <- 192.168.1.122:53655       SINGLE:MULTIPLE
--
igb5 udp xxx:51011 (192.168.1.17:25029) -> 47.91.90.222:32100       MULTIPLE:SINGLE
   age 00:00:33, expires in 00:00:00, 1:1 pkts, 32:48 bytes, rule 141
   id: 010000005cd28c25 creatorid: b13ad8d2
igb4 udp 114.55.218.176:32100 <- 192.168.1.18:21763       NO_TRAFFIC:SINGLE

Derelict

@mrsunfire OK, help me out. Which state should not be there?

mrsunfire

All of the igb5 (WAN) connections from or to the 192.168.1.17.

Derelict

@mrsunfire Pick one.

mrsunfire

@mrsunfire said in Alias firewall block rule not blocked!:

igb5 udp xxx:10147 (192.168.1.17:25029) -> 114.55.218.176:32100 SINGLE:NO_TRAFFIC
age 00:00:33, expires in 00:00:27, 1:0 pkts, 32:0 bytes, rule 141
id: 010000005cd28c23 creatorid: b13ad8d2

igb5 udp xxx:10147 (192.168.1.17:25029) -> 114.55.218.176:32100 SINGLE:NO_TRAFFIC
age 00:00:33, expires in 00:00:27, 1:0 pkts, 32:0 bytes, rule 141
id: 010000005cd28c23 creatorid: b13ad8d2

Derelict

@mrsunfire said in Alias firewall block rule not blocked!:

pfctl -vvsr | grep -A3 '^@141('

pfctl -vvsr | grep -A3 '^@181('

mrsunfire

@Derelict said in Alias firewall block rule not blocked!:

pfctl -vvsr | grep -A3 '^@141('

@141(1000011161) pass out route-to (igb5 134.3.212.1) inet from xxx to ! 134.3.212.0/22 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
  [ Evaluations: 1218      Packets: 12419     Bytes: 8152153     States: 167   ]
  [ Inserted: pid 49753 State Creations: 183   ]
@142(1000011162) pass out route-to (igb5 fe80::201:5cff:fe6b:e046) inet6 from 2a02:8071:xxx to ! 2a02:8071:xxx::/56 flags S/SA keep state allow-opts label "let out anything from firewall host itself"

Derelict

[insert final jeopardy theme here.]

mrsunfire

Right now the alias is working again and I can't get it to not work. I did nothing but now it is blocking. Sorry, I don't see the error there and will give it a try again in the future. Thanks for your help so far.

Derelict

What was rule 181 in that rule set? Inquiring minds want to know!

mrsunfire

This is a rule that passed the traffic from one client on LAN to my Cable Modem interface:

@181(1526110841) pass in quick on igb4 route-to (igb5 134.3.212.1) inet from 192.168.1.20 to 192.168.100.1 flags S/SA keep state label "USER_RULE: PC TC4400 Modem"
  [ Evaluations: 1048      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: pid 79204 State Creations: 0     ]
@182(1417115627) pass in quick on igb4 inet from 192.168.1.0/24 to any flags S/SA keep state label "USER_RULE: Allow ALL IPv4"

Derelict

@mrsunfire said in Alias firewall block rule not blocked!:

Does pfctl -vvsr | grep -A3 1526110841 show anything more?

Derelict

Are you mixing and matching current data with old?

mrsunfire

Right now the old config works. But I post it anyways:

@181(1526110841) pass in quick on igb4 route-to (igb5 134.3.212.1) inet from 192.168.1.20 to 192.168.100.1 flags S/SA keep state label "USER_RULE: PC TC4400 Modem"
  [ Evaluations: 946       Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: pid 41920 State Creations: 0     ]
@182(1417115627) pass in quick on igb4 inet from 192.168.1.0/24 to any flags S/SA keep state label "USER_RULE: Allow ALL IPv4"

Derelict

Are the states that you posted citing rule 181 old data or new?

We need to be looking at the same rule set as the state table or we are just wasting time.

mrsunfire

They were the same rule set. I restored the config againto that point. But this time its working.

I will try to get the problem up again and post the same things again...

mrsunfire

OK I've now checked the latest config again and now here are connections to WAN, I'm really confused:

igb4 udp 114.55.218.176:32100 <- 192.168.1.17:10085       MULTIPLE:MULTIPLE
   age 00:28:43, expires in 00:00:48, 54:33 pkts, 3840:1352 bytes, rule 175
   id: 000000005cd29094 creatorid: 732cab7f
igb5 udp xxx:65411 (192.168.1.17:10085) -> 114.55.218.176:32100       MULTIPLE:MULTIPLE
   age 00:28:43, expires in 00:00:48, 54:33 pkts, 3840:1352 bytes, rule 139
   id: 000000005cd29095 creatorid: 732cab7f
lo0 tcp 127.0.0.1:6379 <- 127.0.0.1:26058       ESTABLISHED:ESTABLISHED
--
igb4 udp 107.20.134.235:32100 <- 192.168.1.17:10085       MULTIPLE:MULTIPLE
   age 00:28:43, expires in 00:00:48, 54:54 pkts, 3840:2208 bytes, rule 175
   id: 000000005cd29098 creatorid: 732cab7f
igb5 udp xxx:17644 (192.168.1.17:10085) -> 107.20.134.235:32100       MULTIPLE:MULTIPLE
   age 00:28:43, expires in 00:00:48, 54:54 pkts, 3840:2208 bytes, rule 139
   id: 000000005cd29099 creatorid: 732cab7f
lo0 tcp ::1[3493] <- ::1[26068]       ESTABLISHED:ESTABLISHED
--
igb4 udp 47.91.90.222:32100 <- 192.168.1.17:10085       MULTIPLE:MULTIPLE
   age 00:23:35, expires in 00:00:48, 45:41 pkts, 3200:1680 bytes, rule 182
   id: 000000005cd295e5 creatorid: d0585f4d
igb5 udp xxx:46591 (192.168.1.17:10085) -> 47.91.90.222:32100       MULTIPLE:MULTIPLE
   age 00:23:35, expires in 00:00:48, 45:41 pkts, 3200:1680 bytes, rule 141
   id: 000000005cd295e6 creatorid: d0585f4d
igb3 udp 255.255.255.255:4944 <- 0.0.0.0:6134       NO_TRAFFIC:SINGLE
--
igb4 udp 192.168.1.1:53 <- 192.168.1.17:44606       SINGLE:MULTIPLE
   age 00:00:06, expires in 00:00:24, 1:1 pkts, 59:128 bytes, rule 182
   id: 000000005cd2a1af creatorid: d0585f4d
igb4.200 udp 8.8.8.8:53 <- 10.0.1.5:11824       SINGLE:MULTIPLE

Derelict

So what are rules 175, 139, 182, and 141 in the current rule set?

mrsunfire

175 is forcing a VOIP client to use a specific gateway (Multi WAN config).

@175(10000001) pass in quick on igb4 inet proto udp from 192.168.1.19 to <negate_networks:2> keep state label "NEGATE_ROUTE: Negate policy routing for destination"
  [ Evaluations: 1632      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: pid 41920 State Creations: 0     ]
@176(1524056818) pass in quick on igb4 route-to (igb5 134.3.212.1) inet proto tcp from 192.168.1.19 to any flags S/SA keep state label "USER_RULE: VOIP UM Gateway"

@139(1000011065) pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
  [ Evaluations: 16781     Packets: 3841      Bytes: 285161      States: 0     ]
  [ Inserted: pid 41920 State Creations: 13    ]
@140(1000011066) pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"

@182(1417115627) pass in quick on igb4 inet from 192.168.1.0/24 to any flags S/SA keep state label "USER_RULE: Allow ALL IPv4"
  [ Evaluations: 2225      Packets: 471566    Bytes: 563093528   States: 42    ]
  [ Inserted: pid 41920 State Creations: 1750  ]
@183(1525366696) pass in quick on igb4 inet6 from 2a02:8071:xxx::/64 to any flags S/SA keep state label "USER_RULE: Allow ALL IPv6"

@141(1000011161) pass out route-to (igb5 134.3.212.1) inet from xxx to ! 134.3.212.0/22 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
  [ Evaluations: 8760      Packets: 477427    Bytes: 563273095   States: 76    ]
  [ Inserted: pid 41920 State Creations: 4639  ]
@142(1000011162) pass out route-to (igb5 fe80::201:5cff:fe6b:e046) inet6 from 2a02:8071:xxx to ! 2a02:8071:800::/56 flags S/SA keep state allow-opts label "let out anything from firewall host itself"

mrsunfire

Oh I see that the second host in that Alias (192.168.1.18) also is not working and passes the traffic to WAN! That's new.

pfTop: Up State 1-6/6 (673), View: default, Order: bytes
PR        DIR SRC                           DEST                                   STATE                AGE       EXP     PKTS    BYTES
udp       In  192.168.1.18:10090            107.20.134.235:32100             MULTIPLE:MULTIPLE     00:41:52  00:00:22      150     8412
udp       Out xxx:50497           107.20.134.235:32100             MULTIPLE:MULTIPLE     00:41:52  00:00:22      150     8412
udp       In  192.168.1.18:10090            114.55.218.176:32100             MULTIPLE:MULTIPLE     00:41:52  00:00:22      114     6940
udp       Out xxx:22381           114.55.218.176:32100             MULTIPLE:MULTIPLE     00:41:52  00:00:22      114     6940
udp       In  192.168.1.18:10090            47.91.90.222:32100               MULTIPLE:MULTIPLE     00:31:10  00:00:22       98     5704
udp       Out xxx:2161            47.91.90.222:32100               MULTIPLE:MULTIPLE     00:31:10  00:00:22       98     5704