Thank you!!. I passed using ShieldsUP! This is a great site. I guess it was a false positive. :) [image: 1661652550169-passed.png]

@jt40 said in How to block access to the firewall: I can't use "This Firewall" because it doesn't allow to specify the IP or port, but I can create a custom rule. Sure you can, that is just an alias of the destination IP, you can set ports on that.. So it can be used as example to block access the web gui ports and ssh. Also you put what you want to allow before it, then just allow the block to anything else to this firewall. example this allows ping, dns and ntp to the pfense IP on that interface, and then the this firewall blocks any and all other stuff to any pfsense IP [image: 1661553452405-rules.jpg] Here its edited to block only access to gui ports via a simple ports alias. If you want to block just ports, you would have to change from any on the rule to something with ports tcp or udp or both tcp/udp [image: 1661553629059-ports.jpg]

@johnpoz why do you have that 169.254 address rule because I noticed that sometimes, even given DHCP availability, that emergency procedure is used Your rule 192.168.2.2 to 192.168/16 would block and not log any broadcast traffic to 192.168.2.25 I want to assure that the WIFI-repeaters from my networks do not communicate via the WIFI Then the next 3 rules pretty meaning really. No hits on them, not sure what trickyports are - but no hits. But unless you have UPnP enabled on pfsense, that would never be allowed anyway. I disabled Upnp, the idea that a computer is allowed to open FW-ports ..... never Tricky ports is a collection of ports which should never be allowed telnet ..... RPC, netbios etc That blocking multicast dns - you understand that would only be to pfsense.. A device on that network can still talk to every other device on that network and discover yep and no. It is only the guest lan and even not that, since the guest network is largely configured as a private lan Your use of bang rules is would would be causing you to see broadcast from other than 192.168.2.2 which your not logging I do not understand this. Note that 192.168.2.2 is the WIFI Access-point If you just had a block rule above those that blocked access to rfc1918 space and you didn't log it. And then a allow rule any for internet, you wouldn't be seeing the broadcast noise. I fix that at the end Why do you have source as any? because LAN-net is not working for IPV6 (I disabled the rule) and I do filter <> LAN-net as one of the first rules (for IPV4) also not that it is extra security, but normally spoken other addresses than lan-net should not / can not occur

@johnpoz Your explanation is very good, thank you.

@gertjan Yes thanks very much, the solution to the Aruba equipment issue was simply set them back to DHCP, they don't need static since they can be managed through Aruba onboarding system. Remove the earlier rules to allow visibility but once set to DHCP, they communicated on their own through the rule set. I obviously have quite a bit more work to see how everything works but this is a good step forward, without DNS and filtering working correctly didn't make sense to work on anything else. As I mentioned I am using DNS over TLS hence the reason I needed the 853 rules.

For comfort, I am running PiHole (3 of them) and they are reachable as described by others from any VLAN. Super easy once you do it once. My PiHoles also use DoH. As to why, the PiHole interface is better and DoH prevents the ISP from snooping. Are there different ways? Yes. This is my solution and I am comfortable with it and it is very easy to build PiHole to use DoH. A few tips, add your DHCP server to the lookup list on the PiHole so it can resolve names and add PiHole to pfSense so it can resolve static DNS entries. I do not point pfSense to PiHole for its primary DNS server. This is for ease of use and just in case the fan makes brown stains on the walls.

So I have made a bit of progress, I added a few rules to WAN side all to no avail. Ended up adding some outbound rules to my VoIP network and do have the phone connected and have tested it. Going to test a second phone to see if there are conflicts but I would have thought the WAN rules would have been necessary, guess not.

@parkerim this all look like broadcast [image: 1661041821150-broadcast.jpg] While x.x.x.255 doesn't have to be a broadcast network.. it could be a host address depending on the mask of the network.. It screams in what your showing since that is not your public IP to be broadcast traffic. Its not uncommon for a ISP to run multiple L3 networks on the same L2.. If I look up all those destination IPs they all seem to belong to Charter (I take it this is your isp) - the ones I checked do.. The one that is really really odd is the 11.14.0.x addresses - those are owned by the DoD ;) But then again its not completely uncommon for those networks to be used where they are not supposed to be used ;) Company I worked for use to use DoD space inside there DC.. Because it was just being local, and never going anywhere outside the DC, etc. its bad practice but it is done way more often then you would think. Port 520 is rip protocol - odd that would still be used anywhere to be honest.. In my opinion that is all just noise - your best bet if filling up your logs would be to just not log it.. You could create a specific block rule on your wan to block that traffic and not log it. Or you could turn off logging of the default deny rule, and then just create a block rule to log what you want to see. This is what I do, I don't log default and just log SYN only traffic to my IP and common UDP ports.. [image: 1661042468174-wanblocklog.jpg] There is some other odd IPs in there as destination though the 8.x.x.x address not a common broadcast address, and the .235 address Oh those 8.x.x.x are on your LAN, and out of state.. Those are being not seen on your wan, that is just something a client tried to go to and the traffic is out of state. I can see what some of that could be odd and confusing to see.. Where exactly is this pfsense - is this your home internet connection via charter ISP? Or is it in a colo or dc somewhere? The one to the .235 address could also be broadcast that would be broadcast for a x.x.x.232/30 network.. And you see that source is .233 which yeah points to broadcast as well just a different network mask. a x.232/30 network would be hosts .233 and .234 with .235 being the broadcast for that /30

ATM, I cannot conduct further tests, as my DSL line is down. I carefully read all your suggestions, thank you all Cheers, Xavier

@menethoran What was the solution to this issue in the end? I'm having similar issues.

@pacomillan While I understand your frustration - when technology becomes antiquated and no longer secured or supported. The solution is not to continue to use old tech, but move on - even if there is going pains. PPTP has been dead, should of migrated away from it 10+ years ago, slow to change ok 8 years ;) Maybe you could facilitate with your client on getting with who runs this server, could be a new client for you. That being said the problem is GRE which used in outbound pptp connection via some client behind pfsense doesn't actually use a port. The tracking of the GRE connection unless you have multiple public IPs to use would be problematic. Not sure if pfsense ever was able to do that. I can not be sure - its been 10 some years since did anything with it, again because its been dead for that long - and should of been migrated away from way before then.

@tekniqal said in LAN communication lost with Load balancer: "the modified any to any group under the LAN interface." CORRECTION: the modified any to any RULE under the LAN interface.

@beavisnbutthead Edit: if this is wrong subforum, can a mod move this post?

@erick51 You can. But it takes experience and knowledge. And you need hardware with dual Xeon proc. to cope.

@lees I have 8 vlans.. While it would take a few minutes to setup.. To be honest its way faster to just do it vs trying figure out what interface belongs in this group, what interface belongs in that group, etc.. 15 does seem like a lot of a home setup, for a even a small business sure could see that many easy, etc.

@louis2 said in "RuleSets" would be highly appriciated: ... … you can not use "lan address" or "lan-net" since <the vlanname> is automatically substituted by "vlan-1" or "vlan-2" I would like to see “This lan” and “This net” options in addition to a copy all rules. Then when setting up a new vlan all rules from the most similar interface could be easily copied across.

@jknott Thank you!! Well, I guess the IPv6 & IPv4 were happening on different NICs. I realized that the MAC was more than likely a raspberry pi. I SSH'd to the unit and shut it off. I will make this a mission to clean up a few more.