Hi, Just to asure you : the final default deny all rule applies when there are no preceding matching rules. The issue is : the rule you crafted doesn't match. If it concerns IPv4, and you used the NAT (PAT) rule GUI, you saw that a NAT rule is actually '2' things. The NAT rule itself, and a WAN type firewall rule. These two have to be synced. Delete them all, and re do them if needed. Check out the NAT trouble shooter.

Huh? The firewall block rule makes no sense in the video because they have no allows that would allow the access. They only have a single allow rule that allows access to the 192.168.5.5 address. There is no point in creating block rules, unless you are putting them above a rule that would allow access because its wider open.. default is deny.. There is no point in creating more block rules, when that is default - the only time you need to block something is if you have a rule that would allow it because its an more open allow then you want.

@PM_13 said in DHCP problem: @JKnott Does pfSense offer "isolation mode" by default? That's a function of the access point, not pfSense. And yes, mine does. Here's what it says: Enable AP Isolation - Isolate all connected wireless stations so that wireless stations cannot access each other through WLAN. This function will be disabled if WDS/Bridge is enabled. However, I'm not worried about whether guests can connect to each other, not that I have a lot of guests at any one time (or ever). Also, ARP doesn't do much, other than provide a MAC address for an IP address. It's not even part of IP. It predates it.

@Inxsible said in Rule to block DNS except pfSense and cloudflare: @ericjames said in Rule to block DNS except pfSense and cloudflare: I didin't check/tried this myself despite the fact that I'm utilizing the default nsupdate technique, I'm utilizing my own far off 'tie' ace and treatment area name workers. Can you please explain this like you were explaining a total noob? Pretty sure that's a bot or spammer. A total of two posts by that account. First one was deleted and the second one makes no sense to even non noobs. It's gibberish. Edit, I can confirm the steps for redirecting DNS posted further above will work, I recently set that up.

it's a bug. group names must be max 15 character [2.4.5-RELEASE][root@pfSense.trmultiservice.lab]/root: pfctl -f /tmp/rules.debug /tmp/rules.debug:263: interface name too long pfctl: Syntax error in config file: pf rules not loaded pass in quick on $GROUPTEST123456A inet proto tcp from any to any tracker 1599036505 flags S/SA keep state label "USER_RULE" but it work with GROUPTEST12345A rename all your group interfaces to something with 15 or less character "pfblocker_groups" -> "pfblocker_group" it was already fixed here https://redmine.pfsense.org/issues/10835

THANK YOU (!!) for the explanation ! ...makes sense, and is something I was not aware of -- Thanks Again !

Well I feel like a right Id10T, I found in my firewalls I have a rule that allowed me on the required ports, however I had the source as LAN address, so when I changed it to LAN net, it works a treat. DOH!

Since they are on separate subnets - VLAN and LAN, you most likely have to use the exact IP address of the printer(s) in your computer settings on the LAN network. What you are seeing is the device "discovery" failing to cross over to the VLAN - this is by design. It has been said here many times, to make it easy for you, put the devices you access the most, in this case the printers, in the SAME subnet. Jeff

Here is a video that describes using pfblocker that uses DNS for blocking. https://www.youtube.com/watch?v=QwFpMwXEK5w But the same video (around 5:40 mark) also states that Google Chrome/Android proxies its own DNS server over Google protocols so there may not be a fail safe mechanism to block YouTube. Good luck and please share if you find a mechanism to block YT.

@akuma1x OMG can't believe I can be this stupid Flip flopping rule did the trick, thanks for pointing that out!

Out of the box the default any any rules would allow you access anything on any of your other vlans. Be it rdp, ntp, ssh, smb, anything.. The rules on your other vlan are meaningless if your lan is creating the traffic, since return traffic would be allowed by the state. If you can not access your vlan from the default lan rules of any any, then you have some firewall on your dest box, it doesn't have a gateway, or points to a different gateway..

https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.html packet arriving after the connection’s state has been removed or if you have other trouble could be asymmetric routing

And the firewall entries your actually seeing. Also pfsense can talk to anything it wants to.. Are you using a proxy, if so pfsense would be doing the talking not your client behind asking proxy to go xyz..

pcname isn't going to resolve, unless you client auto added suffix.. Or you were on the same L2 using a discovery protocol. pcname.domain.tld should be setup to resolve. Whatever domain and tld your using.

@mcdonaghc said in Unitrends CLoud storage issue: In pfSense I have added aliases for the Unitrends servers and have a LAN rule for the Unitrends server, Otherwise I haven't touched it in two years. Has something changed recently with Google cloud storage? Do I need to add a rule/alias for this? Any help or advice would be greatly appreciated. The very first thing to check is your firewall log to see if any traffic to or from the Unitrends Cloud servers is being blocked. You will need to know the IP address (or addresses) to look for. Second thing to check is whether or not you have the correct firewall rules in place. Have you followed the instructions from this Unitrends Support document? https://support.unitrends.com/UnitrendsBackup/s/article/000003983 And then this one: https://support.unitrends.com/UnitrendsBackup/s/article/000006888. Why did you create the Aliases you mentioned? Did you do this recently, as a result of this current problem, or are they from a time pre-dating the current issue? Do the aliases, as defined, have the correct IP address information in them? A common problem with cloud services is they use a number of data centers around the world and connect them to load balancers. This means the IP address can sometimes change unexpectedly. Don't know if this is the case for Unitrends, but it could be. Are your aliases configured as FQDN aliases? EDIT: Just saw this important footnote on their support site -- NOTES: Additional relevant information such as specific exceptions, warnings, etc. These URLs are hosted behind active load balancers in AWS and Unitrends Cloud datacetners. The list of IPs on each URL are dynamic, and change frequently, so we are unable to publish a specific listing. Thus agents and browsers used to access these services will either require unfiltered port 443 access to all external IPs,or, use of a firewall system that supports URL-based filtering instead of port/ip filtering.