On Fri, 2005-01-28 at 12:07:02 +0100, Daniel Hartmeier proclaimed...
> The second rule expands to two rules
>
> block in log quick on $wlan_if from <bogon> to any
> block in log quick on $wlan_if from !$wlan_if:network to any
>
> If $wlan_if:network is also in <bogon>, maybe you see where this is
> leading :)
>
> You could add the negation of $wlan_if:network to the bogon table
> instead.
>
> If you're wondering what other effect expansion has, take a look at the
> output of pfctl -sr. Those are the rules that are really in effect.
> Also, pfctl -vvsr prints the rule number for each rule, which pflog
> entries refer to. So, if you see a packet logged as blocked but get no
> RST, you can look up what rule blocked it (instead of the return-rst
> rule you thought should have).
Hi Daniel, thanks for the reply. I started playing with some of the rules
and found this to be happening (10.116.131.1 is the firewall).
$ telnet 10.116.131.1 7357
Jan 28 11:23:38.565478 rule 40/0(match): block in on fxp0: 10.116.131.15.11723
> 10.116.131.1.7357: SWE 4179382606:4179382606(0) win 16384 <mss
1460,nop,nop,sackOK,[|tcp]> [tos 0x10] (ttl 64, id 44969)
Jan 28 11:23:44.557060 rule 40/0(match): block in on fxp0: 10.116.131.15.11723
> 10.116.131.1.7357: S 4179382606:4179382606(0) win 16384 <mss
1460,nop,nop,sackOK,[|tcp]> [tos 0x10] (ttl 64, id 45638)
After these two packets (about 6 seconds or so), I get a
"telnet: connect to address 10.116.131.1: Connection refused."
on the client side.
But when I connect to the host from the outside world to de0 (ext_if), the
reset happens immediately.
Jan 28 11:24:35.447744 rule 0/0(match): block in on de0: 207.227.243.193.3435 >
67.175.80.217.7357: S 1276381594:1276381594(0) win 16384 <mss
1460,nop,nop,sackOK,[|tcp]> (ttl 54, id 22646)
This is rule #0 and #40 that are being matched.
@0 block return log all label "any-block-log"
[ Evaluations: 122 Packets: 2 Bytes: 468 States: 0
@40 block return in log quick on fxp0 inet proto tcp from 10.116.131.0/25 to
10.116.131.1 label "fxp0-block-in"
[ Evaluations: 2 Packets: 2 Bytes: 128 States: 0
So next, I took out this:
#block return in log quick on $wlan_if inet proto { tcp, udp } \
# from $wlan_if:network to $wlan_if label "$if-block-in"
#$bilq on $wlan_if from $wlan_if:network to $wlan_if label "$if-block-in"
And replaced it with this:
$piq on $wlan_if inet proto tcp \
from $wlan_if:network to ! $wlan_if label "$if-wlan-tcp-$dstport-in" $ms
$piq on $wlan_if inet proto udp \
from $wlan_if:network to ! $wlan_if label "$if-wlan-udp-$dstport-in" $ks
$piq on $wlan_if inet proto icmp \
from $wlan_if:network to ! $wlan_if label "$if-wlan-icmp-in" $ks
$piq on $wlan_if from $wlan_if:network to ! $wlan_if label "$if-ip-in"
But the same problem exists...
Jan 28 11:37:00.782318 rule 0/0(match): block in on fxp0: 10.116.131.15.1496 >
10.116.131.1.7357: SWE 4292232786:4292232786(0) win 16384 <mss >
1460,nop,nop,sackOK,[|tcp]> [tos 0x10] (ttl 64, id 16728)
Jan 28 11:37:06.775511 rule 0/0(match): block in on fxp0: 10.116.131.15.1496 >
10.116.131.1.7357: S 4292232786:4292232786(0) win 16384 <mss >
1460,nop,nop,sackOK,[|tcp]> [tos 0x10] (ttl 64, id 19753)
Now it's being matched on
@0 block return log all label "any-block-log"
[ Evaluations: 88 Packets: 6 Bytes: 384 States: 0 ]
So my question is: why does it take two packets for the session two reset on
this internal network, but it happens immediately on the external interface?
Here's a dump of the session:
Jan 28 11:39:46.896428 0:2:2d:60:24:16 0:90:27:3d:38:d4 0800 78:
10.116.131.15.11241 > 10.116.131.1.7357: SWE [tcp sum ok]
2629313729:2629313729(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale
0,nop,nop,timestamp 1264327927 0> [tos 0x10] (ttl 64, id 43645)
Jan 28 11:39:46.896672 0:90:27:3d:38:d4 0:2:2d:60:24:16 0800 54:
10.116.131.1.7357 > 10.116.131.15.11241: R [tcp sum ok] 0:0(0) ack 2629313730
win 0 (DF) [tos 0x10] (ttl 64, id 12985)
Jan 28 11:39:52.889117 0:2:2d:60:24:16 0:90:27:3d:38:d4 0800 78:
10.116.131.15.11241 > 10.116.131.1.7357: S [tcp sum ok]
2629313729:2629313729(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale
0,nop,nop,timestamp 1264327939 0> [tos 0x10] (ttl 64, id 43740)
Jan 28 11:39:52.889353 0:90:27:3d:38:d4 0:2:2d:60:24:16 0800 54:
10.116.131.1.7357 > 10.116.131.15.11241: R [tcp sum ok] 0:0(0) ack 1 win 0 (DF)
[tos 0x10] (ttl 64, id 1749)
Hmm, perhaps the client (3.6-STABLE GENERIC) is being pesky?
Thanks.
- Eric
