@SteveITS You are right :P Looks like i forgot to change the destination when i copied that rule. Corrected, tested a little, and it looks like this is working fine! Thanks. Looks like my issues are solved, but I will look more tomorrow. [image: 1712699764054-12d009d3-600f-457d-8593-7410562a5588-image.png]

@gusto said in Open DNS on the WAN interface: Could someone from outside abuse my dns resolver? You've said yourself : @gusto said in Open DNS on the WAN interface: I performed a port test and found that port 53 is open to the Internet This : [image: 1712557057653-bfd40ad3-8b24-417e-a381-037dfd684cad-image.png] means traffic from 'WAN' (the entire internet) was reaching your WAN IP, port 53 TCP and UDP, and passed. This mans the traffic reached the process that was (could be) boud to the port 53 for UDP and TCP : that's (normally) unbound or some other DNS handling server process. Note : this would be fine if the interface was a LAN type interface. One of the last barriers still in place (are they ?) are the aforementioned unbound ACL rules. These are the last barrier that will prohibit unbound from taken in account a DNS requests from the WAN port. Like a open rely mail server, you shouldn't 'open relay' your DNS facilities neither. It not bad per se, but what happens if I, and many other, start to request DNS requests to your WAN IP ? I'll be able to DOS your internet connection very rapidly. So, again, normally, "if you don't know what a firewall is" : don't put any pass rules on the WAN interface, and you'll be fine.

@duvel Network ports have to be assigned to usable interfaces at first. This is also true for the rest. When you install pfSense, the first set up step is to assign WAN and LAN and maybe other interfaces. You have to state the respective network port for the interfaces. After firing up a VPN instance, pfSense gives you a new network port, which can be assigned to a certain interface. But this is only needed for some use cases.

Does anyone else have an insight as to what's going wrong? Something I didn't make clear is that there are no UDP rules other than the one I'm trying to add, i.e. it's not a case of traffic being blocked by a different rule; I in fact don't have any block rules, only pass and rely on the default rule to block any traffic which doesn't match a pass rule

@SteveITS My pfsense is running in pass through mode. It's not acting as a router. It's simply a firewall. Traffic passes through it (if allowed) to the servers behind it. I understand that's a but of an unusual setup but that's the way the expert set it up originally. I no longer have access to him. No, I'm not trying to restrict email to only the US. I get email from several countries around the world. What I do what to do is shut down most countries because mostly they just attack my servers. I have both email and web servers behind the firewall so all that traffic needs to pass. We do 99% of our business to US customers but we do have vendors in other countries and support often comes from other countries, as do our credit card clearing services. We already run a 3rd party spam filter and it does a pretty decent job. But why allow all those countries where we don't have reason to connect to slam away on our servers? We'd rather just tell them to go away. But that doesn't mean everyone other than the USA. It's not that simple. Plus as you said, GeoIP isn't 100% So, I have always blocked a lot of countries while still allowing a few dozen in and it's worked pretty well until pfSense went nuts last week and then went insane and we had to start over. I'd be thrilled if I could just get back to where we were but restoring the configuration from the pre-mess doesn't seem to put us back to where we were. It seems not all the settings restore. And then of course there's the desire to put a couple rules stuck to the top of the rule set and that's what started all this mess in the first place. I have a project I need to finish this week. I don't think I'll have time to circle back to this until Tuesday.

@WalterEgosson I think, you're looking for floating rules with Match action.

@bvt Is your wireless the same as your LAN network? If not you'd need the Avahi package to cross networks. If it is then pfSense isn't involved.

@SteveITS Could you please assist with OpenVPN, don't understanding where is my mistake with settings? https://forum.netgate.com/post/1161108

Hey, @SteveITS, and thank you. Reflection has been enabled from the first install. Disabled HAProxy After configuring some things on nginx, I could load the page https://stream.example.com:9443, which gave the SSL Cert. Then. The streaming URL started working after a few reboots on the Linux Server. Don't know why, but it just started working. https://stream.example.com:9443/hls/Radio.m3u8 Thanks, Steve. Have an awesome week. Wayne

@nasheayahu If your going to run some vpn client locally on a box, you need to make sure it doesn't send traffic from the local network.. But yeah its a much less complex setup to just setup your vpn service on pfsense. And then route whatever traffic you want going out the vpn via policy routing.

@viragomann OMG correcting that NAT rule really solved it, pings now work fine!!! You're awesome!! Huuuuuuuge Thanks!! 🫶🫶

@Sergei_Shablovsky there are ways to do rate limiting in pfSense e.g. https://docs.netgate.com/pfsense/en/latest/firewall/configure.html#maximum-number-of-established-connections-per-host Does Suricata have a rule for that?

Issue resolved, this WAS NOT Pfesnese related so please delete this post as I do not have the correct permissions to do so (I just tried to delete the post). The network interface was missing from OMV even though I can connect to it, odd. I added the network interface, part of this configuration needed the DNs server address adding, I did this and everything is working ok now. Odd as all devices should be using Pfsense for DNS but hey, it's working, so I ain't complaining. Apologies if I took up your time. Regards Trebz

@flat4 that drawing - that is not mine.. Believe Derelict is the author, I just saved it because its a great drawing to show use of downstream L3 with L2 switches as well. Pretty sure that is just old copy of visio.. Or at least old icon set.. Could prob create a prettier looking one ;)

@johnpoz Greetings. I'll tell you my solution to the same problem. After reading the recommendations on the link https://docs.netgate.com/pfsense/en/latest/troubleshooting/filterdns-thread-errors.html set kern.threads.max_threads_per_proc to 4096. The problem with determining IP addresses remains. Set kern.threads.max_threads_per_proc to 8192. Oh miracle! The lists are working. In fact it turned out that: [image: 1711464139415-screen-2024-03-26-16-35-32.png] The number of filterdns threads turned out to be more than 4096.

@ngpfskrak This info : [image: 1711445028600-dee7b8a0-74d4-4275-b0f7-90a8b92b82bd-image.png] tells me that you can try something that would work 100 % and I'm 100 % sure. Reset pfSense to default. Change just one ( 1 ) thing : the password. Nothing else. So : Do not change WAN settings. Do not change LAN settings. Do not change DNS settings. This also implies : do not add / enter / touch - don't even look at DNS - do nothing. Also : do not import your saved config, as this would bring you back to square one : "Cannot access internet". As you already might suspect : pfSense, out of the box, works ( ! ! ) This means you could give a pfSense to "Grand Ma" and she would have a working set up after hooking up the cables and power. And don't worry, you won't loose anything, as you can always can import your saved config, and your back at the subject of the thread.

Thanks for the tips... it looks like it was a combination of things on an old Windows 10 Dell laptop that I had left running unattended for a couple weeks. Somehow something had crashed so hard I had to force a power cycle. I think the crash was triggered by a Windows update - when I restarted it went through the usual "please wait while we finish updating your machine because we don't know how to actually install software properly" reboot cycle. The clue was that something was trying to contact Teamviewer and I remembered I had that installed on that machine from an old job. More recently I installed Tailscale as an overlay network, and apparently it defaults to an APIPA address when it's not connected. 21:10:02.592148 IP 169.254.71.22.61774 > 192.168.0.1.53: 7277+ A? master3.teamviewer.com. (40) 21:10:03.596669 IP 169.254.71.22.61774 > 192.168.0.1.53: 7277+ A? master3.teamviewer.com. (40) 21:10:05.610651 IP 169.254.71.22.61774 > 192.168.0.1.53: 7277+ A? master3.teamviewer.com. (40) Thanks again!

@johnpoz @spgeise said in Traffic seems to be ignoring rules: @NightlyShark NTP was always configured in the pfSense, with all interfaces included. It just refused to function on the VLAN25 interface. Strangely enough, specifying the VLAN25 address wasn't enough. Once I set the port to 123 I started to get some hits. [image: 1710717187448-e09dfb7d-db40-419d-b6b1-256608af74b7-image.png] We'll go with this for now.