the vpn stuff was fixed by switching the crypto acceleration to intel

@mmo Did you enable logging on all rules?

@crcagle It was definitely caused by the match statements for the traffic shaper as well as a bit of match rules I had to route specific traffic out a VPN connection vs the default gateway. I was able to get up and running without those features by comment out the match statements from /tmp/rules.debug and loading the file manually with 'pfctl -f /tmp/rules.debug'. I had the auto-config backup service running for a while and it still had a few configs from before the upgrade, so I just reinstalled 5.0-release, reapplied my config, reinstalled my packages and it was back to working as normal again. PF is pretty low level, so I'm not sure if something got left out of the kernel builds in 2.6 or if it was a big feature change in PF and the web UI hasn't been updated with the new keywords yet.

Thanks everyone. Worked like a charm.

@jimp said in (Solved) Renaming Alias used in firewall rule: There is a fix in place now. You can install the System Patches package and then create an entry for 585e7567d0e308ce440ff1b0651976c97fe58115 to apply the fix. Tested that too and worked like a charm ! Thx!

@vmac Just noticed. Any device using IPv6 will exit using the default gateway. The only rule affecting IPv6 are the rules preventing LAN, GUEST, and CAMERAS net access. On the LAN interfaces there is a default allow all rule at the bottom (hidden). So if a VPN_Device is using IPv6 instead of IPv4 it will not exiting using NordVPN. It will exit using the default gateway.

In addition to what @Gertjan noted, many folks who are new to firewalls don't understand that in the default behavior not all rules are evaluated for a packet. The packet is compared to rules starting with the very first rule in the list. The first rule encountered that matches on a packet results in that rule executing, either blocking or passing the packet, and then nothing else happens to that packet. It is not evaulated against the other rules. The first matching rule wins. The only exception to the above is Floating Rules which can have a "match" option for tagging packets. In that case, the packet is compared to each Floating Rule, and the "last match" wins. More details on Floating Rules is in the documentation here: https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html.

@bmeeks Thank you.. this answers my question

@hanalei_boy Start typing the alias name in the port field.

So i know this is an old thread but i think this is whats happening to my storj node. Sonehow traffic is begin blocked but should not be. I have the correct port forwarded in my router but the satellites are being blocked. Here is a link to my other post. https://forum.netgate.com/topic/161260/necessary-traffic-being-blocked-how-to-identify-and-pass?_=1613954739379 I sure could use some help on this.

@hieroglyph Thanks. You've answered my questions and I see what you mean about blocking the TCP admin ports.

@c00kie55 I do not use squid. Nor am I familiar enough with squid to give you a definite answer. But quick google search of allow only specific websites with squid seems to indicate it is possible.

@pfnow Nothing looks crazy in your rules. So there is either something weird happening with the DNS resolver/resolver settings. Or you states are expiring fast. Are 1.1.1.1, 8.8.8.8, and 8.8.4.4 the only three DNS servers you are using? If you are using other DNS servers are they also showing as being blocked by the default WAN rule?

What is the end goal here? This sounds like the way things are supposed to work. Source devices pick a random port for each outbound connection it wants to initiate. If I have x3 tabs open in my web brower (gmail.com, bank.com, and movie.com) my device will choose x3 random ports that look something like this: 192.168.1.11:23456 --> gmail.com:443 192.168.1.11:34567 --> bank.com:443 192.168.1.11:45678--> movie.com:443

@ronpfs So are you saying that if the IP ranges overlap, then the firewall will block those IP addresses, regardless of what their "Network Address" is (one has a network address of 192.168.1.0 and one has 192.168.0.0)? [Edit] I did some more reading and realized that subnets can overlap and that is an incorrect design. I thought all subnets were unique and couldn't overlap, that is where my confusion was.

@psp thanks, that worked!