FW rules not working as dsigned.
I created three different FW rules to control traffic traveling between the interfaces. I have the rules:
Protocol Source Port Destination Port Gateway Queue
IPv4 OPT2 * WAN * * none
Except, that the rule starts to filter TCP:S traffic for port 443 and UDP traffic on port 53. If the rule is set to allow all TCP IPv4 traffic, why is this rules filtering traffic.
The kicker is if I change the rules to:
Protocol Source Port Destination Port Gateway Queue
IPv4 OPT2 * * * * none
Then the rule work like fine, except that it is sending all the traffic through on interface. Which it is not what I am looking for.
Another option that that I have is to set the Protocol to TCP/UDP and that will also works, but it is not what I am looking for either. The rule was set to allow all traffic between OPT2 and WAN interfaces.
Trying the configuration on another interface the result it is exactly the same. Can it be possible this is a bug in the code?
"WAN Network" is strictly IP addresses in the subnet that your ISP is providing (i.e. other local customers of your internet provider in some cases). If you want to be allowing access to the internet, the destination needs to be * and not WAN.
Because a destination of * would also include other local networks, you need any rules blocking those networks that shouldn't be accessible before that rule.
Thank you for your response.
I am not sure if I follow what you are saying. If you are using * (indicating any rule) then any connection going through that interface is allow.
The rule is stablishing connection between two interfaces interface WAN and OPT2 allowing IPv4 (meaning the entire stack, TCP and UDP) to pass through. The rules should allowed any packet to pass through between the interfaces.
The routing should work from OPT2 traffic traveling to WAN pass all the packets, the WAN interface has a rules of any from any to pass through as long as the request is coming from the inside network. What I am seeing, is the TCP:S and UDP 53 are being blocked from leaving the network. Every other packet leave and return successfully.
The TCP:S is a TCP flag that stand for SYNC as explained by the two links below:
TCP/IP v4 is unsecured by definition. That is why TLS and VPN or encrypted communication is needed.
please post screenshots of your rules.... this isn't making much sense
The destination is not the interface that the packet should be forwarded to. It is the destination IP address of the packet being processed.
pfSense is a layer 3 firewall. It works at the IP layer, looking at source and destination IP addresses of the packets it handles. If the source and destination match, the packet is passed or blocked, based on what the rule says to do.
"WAN Network" is the same as providing the IP subnet that your internet provider provides you. For example, if your ISP provided a subnet of 100.66.64.0/22, a packet going through the firewall would need to have a source address from your OPT2 network and a destination address within that IP range from your ISP in order to be passed by the rule.
Thank you again for your response.
I will mod the interface to reflect the WAN address and see if that makes any difference.
Will report later if the changes made any differences.
virgiliomi last edited by
If you still have issues, please do as heper requested and post a screenshot of your rules. That way we can see everything exactly as it is set up.
Here is the update.
In either net or address configuration, the rule is still blocking TCP:S UDP:53 requests.
For instance connecting to my email server, the UDP:53 is getting blocked still. This seems very stupid but, if I remove all the rules, and I just set on rule allowing any * * * * any * * * all my systems can get out to the Internet. Once again the rule the "Default deny rule IPv4 (1000000103)" is taking place. How can I configure default rules in pfSense?
This rules is very simple, allow all traffic from X interface to the Y interface. Every FW that I ever used, does not block internal traffic from leaving the network and getting a response back from the Internet. I have configured this type of rule in CheckPoint, ASA, Juniper, Sophos, SonicWall I have never has the results I am experiencing with pfSense.
As a matter as fact, most FW will allow all traffic to communicate with the outside without any rules since it will allow common ports to get out.
The normal work of the FW is to match the internal request to the external response and base on the several criteria such sequence, destination, port, domain/IP it is allowed to pass or drop. This rule it is not that complicated and there is not indication for internal threat since it an internal request.
Since it is not working and doing what I want to accomplished, I have decided to write a single global rule. Later on I will replace pfSense with a better FW.
About your request, there is not need to post every single rule set in my FW, since the only rule affecting traffic between OPT2 and the gateway is the rules I presented.
Again, if the rule is set for global any any, it works find. Which makes me wonder in which direction is traveling. It seems that it is going to a default route???
You really need to post up your rules if you want any help.
Out of the box pfsense allows all traffic out the lan, default is any any rule. And yes the return traffic would be allowed via the state.
If you created a new interface you would need to create rules, since the default is deny.. As mentioned wan address or net is not the internet..
Which makes me wonder in which direction is traveling
Rules are evaluated as traffic enters an interface from the network its attached too. First rule to trigger wins, no other rules are evaluated.
Post up your rules if you want help. What I can tell you for FACT!!! Is users say they do A, when really they didn't do anything close to that.. Its more like X+Y=z^2
IPv4 OPT2 * WAN * * none
If that is your rule - its a nonsense rule, unless all you want to do is allow traffic to the WAN.. And wan what did you put, wan net, wan address? Which has been stated multiple times already.
Once traffic is allowed the return traffic would be allowed by the state.
jwj last edited by
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.
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
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/22
My computer on OPT2, 192.168.2.42, wants to ping a server on the internet.
Protocol: IPv4 ICMP... matches
Source: OPT2 network... matches
Destination: WAN Network... doesn't match. (22.214.171.124 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.
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.
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 126.96.36.199 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:
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!!!