Custom pass rule on LAN interface ignored in favor of default deny rule
-
I added a static route for the LAN interface that runs 5.0.0.0/8 (for a VPN network) over a separate gateway (192.168.17.1) on my local network. I also added a custom firewall rule that permits traffic to that other subnet.
However, all packets directed toward the 5.0.0.0/8 subnet are being blocked by pfSense. When I take a look at pfSense's Filter Logs (command line option 10), I get the following:
tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 000000 rule 196/0(match): block in on bge0: 192.168.16.2.80 > 5.161.239.107.51331: tcp 40 [bad hdr length 0 - too short, < 20] 924875 rule 196/0(match): block in on bge0: 192.168.16.2.80 > 5.161.239.107.51331: tcp 40 [bad hdr length 0 - too short, < 20] 1\. 003254 rule 196/0(match): block in on bge0: 192.168.16.2.80 > 5.161.239.107.51331: tcp 40 [bad hdr length 0 - too short, < 20] 1\. 001289 rule 196/0(match): block in on bge0: 192.168.16.2.80 > 5.161.239.107.51331: tcp 40 [bad hdr length 0 - too short, < 20] 675309 rule 196/0(match): block in on bge0: 192.168.16.2.80 > 5.161.239.107.51331: tcp 40 [bad hdr length 0 - too short, < 20] ^C 5 packets captured 5 packets received by filter 0 packets dropped by kernel196 is the Default deny rule, 188 is my custom rule:
# pfctl -vvs rules ... @188 pass in quick on bge0 inet from 192.168.16.0/20 to 5.0.0.0/8 flags S/SA keep state label "USER_RULE: Allow accessing Hamachi peers via static route" queue(qlandef, qlanacks) [ Evaluations: 5 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 26085 ] ... @196 block drop in log quick all label "Default deny rule" [ Evaluations: 5 Packets: 5 Bytes: 300 States: 0 ] [ Inserted: uid 0 pid 26085 ]Why is rule 188 not being respected so that the traffic would be allowed to pass?
The routing worked fine before I switched over to pfSense 1.2.2 and routing also works just fine if I manually add a route on the client, saying that 192.168.17.1 is the gateway for 5.0.0.0/8.
-
Hey man, just wanted to let you know I'm noticing the same thing after upgrading to 1.2.2. Custom rules are being overridden by the Default deny rule. Anyone have any thoughts?
-
Hey man, just wanted to let you know I'm noticing the same thing after upgrading to 1.2.2. Custom rules are being overridden by the Default deny rule. Anyone have any thoughts?
I second this, and it is also present in the latest 1.2.3 snapshot.
-
mkuron: you need to check "bypass firewall rules for traffic on same interface". You have asymmetric routing, which no firewall can statefully filter. It's a problem in every version, though you may not notice it in some scenarios in 1.2 because the older PF doesn't have the implied flags S/SA that the newer does in 1.2.1 and newer.
-
Thanks cmb, that solved it!
-
i only registered because of that problem :)
and it solved it smoothly :)thanks!
btw: i have setup the same scenario as you did!
Martin
-
On the other side, I have experienced maaany problems routing traffic from LAN to WAN and from PPTP clients to LAN since upgraded from 1.2RC to 1.2.2. I even reinstalled 1.2.2full LiveCD again just in case but it didn't solve it.
Either I don't have the slightest clue about firewall rules on pfS or 1.2.2 is broken.
I currently run a single pfS on a PIII-500 with 3 NICs, WAN, LAN and DMZ.DSL Modem
(in bridge mode)
|
WAN (62.48.181.xxx /29)
[6 static IPs but for now am only using 1 IP]
|
+– DMZ (192.168.99.1 /24)
|
LAN (172.22.10.17 /24)
|
Passport 1200 switch
[many VLANs and many networks]Our switch act as a router and as a DHCP server.
All our server ports are marked untagged on the default VLAN.
All our trunk ports (connecting to other office 350 and 450 24T switches) are marked tagged.
We have pfS serving PPTP clients with high IP addresses of 172.22.10.xxx in a /16 subnet (same network range as Server Farm).
Maybe we shouldn't be doing this but it has worked like a charm in the past.
We have rules allowing all traffic out from LAN -> WAN&PPTP and from DMZ -> !LAN.LAN Tab
Allow TCP LAN net * 192.168.99.5 22 (SSH) * LAN >> DMZ(sFTP)
Allow * LAN net * ! DMZ net * * Default LAN -> anyWAN Tab
Allow TCP * * WAN address 443 (HTTPS) * WebGUIDMZ Tab
Allow TCP 192.168.99.5 * 172.22.10.16 ePO_ports * Manut >> ePO
Allow TCP 172.22.10.16 * 192.168.99.5 ePO_ports * ePO >> Manut
Allow TCP 192.168.99.5 * 172.22.10.16 80 (HTTP) * Manut >> ePO
Allow TCP * * DMZ net 22 (SSH) * ALL >> DMZ(SSH/SFTP)
Allow TCP PPTP clients * DMZ net 5900 (VNC) * ALL >> DMZ(VNC)
Allow * DMZ net * ! LAN net * * DMZ >> !LAN(Any)PPTP tab
Allow ICMP PPTP clients * * * * PPTP >> LAN/DMZ(ICMP)
Allow TCP PPTP clients * DMZ net 22 (SSH) * PPTP >> DMZ(SSH/SFTP)
Allow TCP PPTP clients * * 445 (MS DS) * PPTP >> LAN/DMZ(SMB)
Allow TCP/UDP PPTP clients * * 53 (DNS) * PPTP >> LAN/DMZ(DNS)
Allow TCP PPTP clients * 172.22.10.18 3306 * PPTP >> HDNET(MySQL)
Allow TCP PPTP clients * LAN net 3389 (MS RDP) * PPTP >> LAN(RDP)
Allow TCP PPTP clients * LAN net 5900 (VNC) * PPTP >> LAN(VNC)
Allow TCP PPTP clients * 192.168.99.5 5900 (VNC) * PPTP >> DMZ(VNC)We also have rules allowing ports TCP 22,445,3306,3389 and 5900 from PPTP clients to LAN and ports TCP 22,5900 from PPTP clients to DMZ.
All this works fine.
pfS also has 2 static routes to 172.22.20.xxx /24 and 172.22.30.xxx /24 (desktops and laptops networks/VLANs) with default gateway being the Passport 1200 switch.
Server Farm can reach both these networks with full access since these are all LAN subnets.
The issue is, PPTP clients can open VNC to a server in 172.22.10.xxx but they can't do the same to 172.22.20.x or 172.22.30.x, wich BTW they used to be able to do with pfS 1.2RCs.
Also 172.22.20.xxx and 172.22.30.xxx can't both reach DMZ on TCP port 5900, but 172.22.10.xxx can.
When I go to Status > System Logs > Firewall, I see that it is default rule which is blocking traffic.
Any help will be greatly appreciated.
Cheers
PS: I'll post some screens of my config in a few minutes. -
rds_correia: sounds like the same, check "bypass firewall rules for traffic on same interface" as I said above.