A couple of Images of the problem.. With a Schedule... [image: 1645748253067-with-schedule.png] Without a Schedule Enabled. [image: 1645748303440-without-schedule.png] I have deleted the rule, powered off the firewall, removed the power cord, still happens on new Rules with a Schedule..

@johnpoz You can mark this solved if you'd like, not really sure how that works here at the Netgate Forums. I am very appreciative of your time and help. Thank you sir.

@kultigsptrizigfrisch So I'm wondering, why you don't answer the question, how the proxy should forward the traffic to the desired backend, since you don't tell him its IP address. I can imagine, how the sniproxy is meant to work this way you've it set up. That works for outside requests, where the traffic is routed to the proxy, while it forwards the traffic according to the hostname resolution in the internal DNS (split DNS). But if that's not possible for what ever reason in your case, you can as well state a backend IP in the proxy settings. And I'm wondering why you don't do that. Also again, this all can be done in HAproxy. HAproxy is as well capable to determine the SNI hostname without providing the TLS certificate and forward the traffic to the proper backend IP.

@johnpoz Yes, I understand those rules will never work. I'll remove then. Now you talking. I'll set the rules you mentioned and post the result here. Thank you !!!

@johnpoz Yeah, doubt I would send myself email. I was told if I was behind firewall and I tried to send others email others@mydomain.com they would not get it. It is working now so all good. Thanks so much for all your help.

@nabberuk did you pick your interface? I would think pfsense should of been able to figure out which interface to send the traffic.. but maybe you have something odd setup with your routing. Was that sniff you saw going out your wan - you sure that is the correct "wan" to be able to get there? edit: so you can see other open ports (get answers) but not 465 - interesting..

@the-other said in DNSBL Stops DNS Service (Solved): pfblockerng_dev (do not know about the other one) does NOT reload a list from servers if there are noch changes. It seems "smart" enough to recognize a change in the list. No changed list > no download (at least that's what the log says... I hope so, I'm not so sure. File attributes, size, last modified time stamp etc are needed before the file gets downloaded again. But : /usr/local/pkg/pfblockerng/pfblockerng.inc line 3373 : if (($fhandle = @fopen("{$file_dwn}.raw", 'w')) !== FALSE) { The local destination file is opened for writing - so initial file size date etc are lost : CURL doesn't cache by itself : the file can only be re downloaded at this stage. Also : /usr/local/pkg/pfblockerng/pfblockerng.inc line 170 : CURLOPT_FRESH_CONNECT => true Now read Is there a way to tell curl to not use cache edit : I forget something : most feeds are https://..... and default TLS web server caching is : no caching. So even if you, on the receiving side, are ok to receive a cached version, you still get the entire file again. Btw :less used download methods like rsync are version/date/time aware.

Thank you @viragomann, I appreciate the feedback. I'll take a look; but, for the moment, it'll have to wait. Since we last spoke, the QNAP has since died (I think it's the power supply since nothing happens when I press the power button), and I need to send it in for warranty repair. When I get it back, I'll get started on trying out some of your ideas. But honestly, I'm just about ready to throw the whole unit away and start all over w/ something else. At least my Netgate and PfSense keep going. Plus, I'm learning more about NAS's and servers than I ever thought I would. Take care, Matt

@johnpoz said in Prevent firewall logs from devices in WAN Net: @whitetiger-it yeah that works.. Or you could of just turned off logging of that rule ;) I keep logging in so if there is any other "strange thing" on the network it will be highlighted. Thank you again

@johnpoz YOU ARE MY HERO! This might be ridiculously stupid but the asymmetrical routing was the reason. As you may assume from my setup, I once used the FritzBox network only and started to setup the pfSense recently. The Synology NAS was connected directly to the FritzBox (WAN) network on the first eth interface. The second one was connected to the DEV interface of my pfSense where I was facing the described issues. On the Synology, the first interface was still the WAN subnet connected. Thanks a lot!!!!

@bambos that was the IP sending those PA from 443? that is a German IP. Owned by org-name: Myra Security GmbH https://www.myrasecurity.com/en/about-us/ Yes you can use pfblocker to create alias that contain the IPs of only the country or countries you want. For example my pfblocker alias I created contains the US IPs, Morroco because I have family member there (she is teaching for a few years there) using my plex.. And it also contains some other IPs that check if my plex is working.. [image: 1645019784369-pfblocker.jpg]

@nikpony from where exactly - out of the box pfsense does nat, so you wouldn't be able to get to any lan IP unless you did a port forward. Or if you had disabled pfsense from doing nat? Also out of the box pfsense blocks rfc1918 as source of traffic to anything you might allow on wan. So if your on some device in pfsense wan and its an rfc1918 address - you would have to disable that rule on wan to allow or even port forward to anything behind pfsense. So more details of exactly what your trying to allow and from where, just some local wan network, the public internet, etc.

fyi, the below is broken after upgrading to 2.6.0. From some digging, this version introduces "ridentifier" rather than "tracker" in rule definitions. If you replace tracker 1641638644 with ridentifier {$increment_tracker()} ... then all appears to work again.

@darkcorner I create one alias per hostname and then stack these aliases together as needed.

@msswift I don't mess around with floating rules. I define them more explicitly on each interface. But here's some official documentation from Netgate on how they are applied: https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html Also note that floating rules marked as "Quick" act differently than non-quick floating rules.