FW rules not working as dsigned.
-
I'm not going to be one of those unpleasant people who say RTM, but this is really well written and worth reading for all pfSense users. New and more experienced.
https://docs.netgate.com/pfsense/en/latest/firewall/index.html
-
@johnpoz said in FW rules not working as dsigned.:
Seems you have personalized opinion about users in general.
Beside the point and as previously mentioned, there is only one rule between interface OPT2 and WAN interface.If WAN net or address it not pointing to the Internet, then how are you passing your traffic to the internet? Every FW route the packets to the WAN interface unless you have a different def on this meaning. This is not a multi-homed FW. And making comments:
"If that is your rule - its a nonsense rule, unless all you want to do is allow traffic to the WAN."
GET OFF your high horse and explained your reasoning. Better yet, if you don't have anything useful to say, just DON'T say anything.And since you want to be an AR$$, yes I know how FW rules get evaluated from top to bottom and how they work. As mentioned previously, the only way to make the rule work is using the any/ant rule other than that it wont pass specifict traffic Internet which in other FW that dosn't happen. That is why the ANY factorizes all packets
-
@g405tsh311 said in FW rules not working as dsigned.:
there is only one rule between interface OPT2 and WAN interface.
There is NO such thing.. Rules do not work that way on pfsense - it is not a zone firewall.. You have to set destination based on IP. Be that any or something specific.
Setting wan as destination, would only get you to the wan net or the wan address.. Doesn't get you to anything past that..
So yeah stating something like this
IPv4 OPT2 * WAN * * none
Is a nonsense rule that sure is not going to let you get to the "internet" or anywhere past the wan..
-
The firewall here is ALL based on IP addresses, ports, and protocols.
Does the protocol match?
Does the source IP/port match?
Does the destination IP/port match?
If so, [allow | block | reject] the packet.If the packet is allowed, it's then usually routed based on the IP routing table.
The rule does not say "Traffic in on this interface should go out that interface." That's not how pfSense works.
To go back to your original case...
OPT2 Network: 192.168.2.0/24
WAN Network: 100.66.64.0/22My computer on OPT2, 192.168.2.42, wants to ping a server on the internet.
>ping 8.8.8.8
Protocol: IPv4 ICMP... matches
Source: OPT2 network... matches
Destination: WAN Network... doesn't match. (8.8.8.8 is not within 100.66.64.0/22)
Result: No action taken. If no other rules match, the packet is blocked by a default rule.If the DESTINATION in the rule was ANY, then the destination would have matched and the packet would have been passed. It would then be routed to the WAN interface based on the IP routing table.
-
Thank you fro the link.
I have totally no issue RTFM. I just was thinking it is just another FW with the same concepts, but I guess, I was wrong.
Thank you for the pointer, really appreciated. Going through it right now.
-
Thank you for the clarification, I am looking into that right.
Currently analyzing packet dump. -
@virgiliomi
Thank you for the guidance.
I am a bit confused at your last statement:
"If the packet is allowed, it's then usually routed based on the IP routing table."
Since the dst IP does not live in the current routing table, but the routing engine know the closest interface that match the destination and so on and so forth until the packet is delivered.Just give me a sec I am going through the packet dump.
Thank you again. -
@g405tsh311 said in FW rules not working as dsigned.:
Since the dst IP does not live in the current routing table
Sure it does.. That is what your default route is for.. For anything not attached or or have a direct route to how to get to some IP, send to default gateway..
What he prob meant by this statement
it's then usually routed based on the IP routing table."
Is you can policy route and send traffic out some other gateway that is not your default, based upon some criteria other than destination IP. Say you have multiple wans, or have a vpn. And you want traffic destined for 1.2.3.4 to go out wan 2 vs default wan 1 gateway. Or maybe you want traffic going to port xyz to go out only your vpn. Or maybe you want some IP on your network 192.168.1.100 to always use vpn..
You can create a firewall rule that shoves traffic based on the criteria in the rule out a specific gateway.
So while yes normally traffic will be routed based on the routing table - it is possible to policy route if you so desire. Most of the time users use this functionality for routing traffic out a vpn. Where pfsense is a client of some vpn service, or server..
know the closest interface that match the destination and so on and so forth until the packet is delivered.
Not sure where you got such an idea. No router/firewall works like that. That I have ever seen - and I have been working with routes and networking since before there was even IPs to route ;) There is either a route where to send the traffic per destination IP, or it is sent out the default route.
Sure if there are multiple routes for a destination, than route will be chosen based on the metric of the route.. But I have never seen anything like this route is "close" lets send traffic out that interface and see if it gets to where it wants to go. Guess not, lets send it out some other route ;)
-
I am unsure where you get that information but the destination IP does not reside in the current routing table. That is why the routing algorithm determine the next hop to pass it to. Using the default route (0.0.0.0) is a clear indication of missing route. Unless you know about a different RFC, I would love to read it.
Every device has its own routing table and no one single router has the entire routing table from source to destination. As I said, in a very over simplistic way. The packet is pass to best found route in the routing table, IP-to-interface. The packet is passed on that inter face which will send the packet to the next hop. This process is repeated until the packet gets to its destination. Over simplistic as well be support the point:
https://youtube.com/watch?v=MZ6xBkjjJrU&ab_channel=ISOTraininginsitute -
Feeling really silly and slow due to my findings....LOL
In any case, I would like to thank everyone for the responses and assistance provided.
After looking at the packet dump and analyzing the network I discover that Win10 was the issue. For some reason the FW was seeing Win10 out sequence and blocking the UDP:43 and TCP:S for TLS over 443/
Now the rules is set as previously presented and working wonderfully!!!
Thank you again guys, much appreciated!!!
