@viragomann Thx for your help. I have to think about which would be the best way now. As it's a testing setup I have no problem starting everything over again.

@steveits This fixed the issue for me. Thank you! [image: 1673976867755-328e3f2e-11cc-496f-9bc7-47a0c2966c07-image.png]

@viragomann Thanks so much for the help...this was exactly what I was looking for (but didn't know existed )

The most effective way is to unplug your Internet connection ! Ok, just kidding there, but that is really the only way to be 100% guaranteed such services are blocked. Blocking those, and other services such as YouTube, Facebook, etc., is very difficult because they do not use a single IP address. They have servers located in data centers all over the world, and the different servers connect to the Internet via different IP networks using CDNs (content delivery networks). It is not as simple as blocking some host that only has a single IP address that it uses. For load balancing purposes and other reasons, CDNs typically put very short TTL (time-to-live) values on the DNS entries for such services as WeChat, TikTok, YouTube, etc. Sometimes these are as short as 2 to 5 minutes. So two different clients attempting to resolve one of those domains can actually receive and use two completely different IP addresses. Most pfSense users are installing the pfBlockerNG-devel package and configuring it with ASN lists for the services they want to block. There is an entire sub-forum here just for pfBlockerNG. You can get some input from others by posting questions there. Here is a direct link: https://forum.netgate.com/category/62/pfblockerng.

@mrpete: This is probably worthy of a bug report to the Netgate team, then. Seems you have done the research to make it easy for them to reproduce. I ran into some of that problem with IPv6 in my Snort and Suricata packages when displaying alerting IP addresses. You can report the bug on the pfSense Redmine Site here: https://redmine.pfsense.org/projects/pfsense. Include your steps for how to reproduce the behavior and the suggested resolution.

@stewart hahaha <rofl>

yes when I use IPTV services then I face this situation. so this is the solution. The solution I ended up using was to configure a layer 3 switch and route between the two networks. I connected the main network (the one provided by the ISP) to the layer 3 switches and then connected my pfsense machine to the layer 3 switch as well. I then configured static routes between the two networks on the layer 3 switch, allowing traffic to flow between the networks. This allowed me to keep my pfsense machine on the main network, and still be able to access the resources on the other network.

@itheadquarters Again, you shouldn't have to do anything. Those look like they would all be outbound which would be allowed by default. but if you want to try it, set up a NAT for each of them to the IP of the device.

It only works on the interface tab(s) for interface(s) where the dynamic address can be looked up from the OS interface. Otherwise it is ambiguous and cannot be properly resolved. It has no way to know which interface to look it up from. IIRC there is an open feature request for that sort of thing (https://redmine.pfsense.org/issues/7922 exists also but it's not quite that either). Ultimately the problem is that the daemon that gets the delegations from upstream doesn't expose the info in a way we can use it outside of an OS interface, so they can't be used anywhere else even if we know the prefix ID and so on.

@mtiede said in Zoom Alert! (Network Trojan Detected): And that hack just happened to get reported when it tired to infect the zoom server? Common Sense ;) Yeah 2 years ago android phones were spreading conflicker talking to zoom IPs.. And that port would be a download of the payload etc, not trying to infect it.. So yeah his the zoom server was being used to spread conflicker - and his android phone was infected.. Or I don't know common sense says he uses zoom, and the IPS reported a false positive based on traffic type and port -- anyone that has ever used IPS or IDS for more than 10 minutes knows that is quite common... So yeah common sense..

@johnpoz said in Protect pfSense: Better security when changing pfSense access-ports: I run for example gui on 8443 for this reason, That's exactly what I do as well as have a specific browser that's use only to access the GUI.

Well, as unsolicited traffic on WAN is blocked by default, I am assuming you are trying to block return traffic that matches something- IPs in geographic regions? As it's return traffic that you are trying to block, isn't it better to block it on the LAN side, traffic going out TO somewhere you don't want, as opposed to letting the user reach that IP, and then have that return traffic blocked. Maybe I am not sure of what you are trying to do, you allow the traffic OUT then stop it on the way back...

@ramizak while I love the unifi APs - I had a usg3p for a short time, while my 4860 was back ordered, and need something that could handle my new internet speed. Was never a fan of it, my son used it for a bit at his house. But now its just on my shelf. I have one of their switches as well (on the shelf).. Not a fan of it either - price point was good, and its a tiny little thing - and can be powered by poe which is nice and there are for sure some use cases for such a switch. The little flex mini, just not a fan of management and configuration of anything other than their APs Have fun with your new netgates - a late xmas present sort of to play with ;)

@robertk-1 see my completed edit - on what happens when the ttl has expired on that fqdn and pfsense is asked again to look it up.. I didn't redo the table or anything - just did a dns query for the fqdn that is in the table.

@werkstrom Strange. The network cable can for sure be a reason for some weird behavior. But this one, access through HAproxy succeed, but from other subnet doesn't...

@gerry26500 Also doulbe-check all VLAN settings on all involved devices. Possibly there is something messed up.

BTW, I'm on this version, maybe something regressed (potentially): 2.7.0-DEVELOPMENT (amd64) built on Wed Jan 04 06:05:22 UTC 2023