@marcosm DM sent.

@stephenw10 Oh, great! Thank you for that correction (I didn't know that). I'll replace my script with the one you gave me. Thank you so much!

@pftdm007 not quite - if you are not in forwarder mode, unbound resolves what was asks from the roots down.. It doesn't send the query anywhere - it resolves vs forwards. And not so much pfsense passes it to unbound, unbound is listening on 53, and as long as your firewall rules allow it - unbound will get the query directly. When you resolve - you don't need anything in the general setup at all. If pfsense itself needs to resolve something it will ask itself (unbound) via the loopback address 127.0.0.1 the only time something like 8.8.8.8 would be used if you have it in general is if pfsense itself wanted to lookup something and unbound wasn't answering. Or you were in forwarding mode, be that either native (just 53) or in dot mode (853 with encryption of the connection via tls) Now that you know normal dns works - you could go back to forwarding if you want. I personally not fan, but sure if you want to forward forward.. Only thing I would suggest if you forward is uncheck to do dnssec. It can only be problematic if you forward - where you forward either does dnssec already or it doesn't, if it doesn't telling unbound to do dnssec is just going to cause extra queries, and could cause problems. Also forwarding to different services can be problematic as well - especially if they do filtering, and the filtering could be different. Since you don't really know which one will be forwarded to when you have more than 1 service.. You are not sure which filtering you would get.. Its best if you forward to pick 1.

Yes.

@marcosm the patch can be applied on 25.07.1 and looks fine : [25.07.1-RELEASE][root@pfSense.bhf.tld]/root: pfSsh.php playback pfanchordrill ################ # ethernet rules ################ ether anchor "cpzoneid_2_auth" on igc1 l3 all { anchor "192.168.2.38_32" all { ether pass in quick proto 0x0800 from 32:e4:ee:0b:29:c8 l3 from 192.168.2.38 to any tag cpzoneid_2_auth dnpipe 2016 ether pass out quick proto 0x0800 to 32:e4:ee:0b:29:c8 l3 from any to 192.168.2.38 tag cpzoneid_2_auth dnpipe 2017 } anchor "192.168.2.42_32" all { ether pass in quick proto 0x0800 from 26:e4:a6:2f:22:15 l3 from 192.168.2.42 to any tag cpzoneid_2_auth dnpipe 2010 ether pass out quick proto 0x0800 to 26:e4:a6:2f:22:15 l3 from any to 192.168.2.42 tag cpzoneid_2_auth dnpipe 2011 } anchor "192.168.2.43_32" all { ether pass in quick proto 0x0800 from 9a:65:2b:20:a3:b3 l3 from 192.168.2.43 to any tag cpzoneid_2_auth dnpipe 2012 ether pass out quick proto 0x0800 to 9a:65:2b:20:a3:b3 l3 from any to 192.168.2.43 tag cpzoneid_2_auth dnpipe 2013 } anchor "192.168.2.44_32" all { ether pass in quick proto 0x0800 from ac:1e:9e:70:cd:2d l3 from 192.168.2.44 to any tag cpzoneid_2_auth dnpipe 2014 ether pass out quick proto 0x0800 to ac:1e:9e:70:cd:2d l3 from any to 192.168.2.44 tag cpzoneid_2_auth dnpipe 2015 } } ether anchor "cpzoneid_2_passthrumac" on igc1 l3 all { anchor "28704e6249e5" all { ether pass in quick from 28:70:4e:62:49:e5 l3 all tag cpzoneid_2_auth dnpipe 2000 ether pass out quick to 28:70:4e:62:49:e5 l3 all tag cpzoneid_2_auth dnpipe 2001 } anchor "28704e6260bd" all { ether pass in quick from 28:70:4e:62:60:bd l3 all tag cpzoneid_2_auth dnpipe 2002 ether pass out quick to 28:70:4e:62:60:bd l3 all tag cpzoneid_2_auth dnpipe 2003 } anchor "9c05d6320095" all { ether pass in quick from 9c:05:d6:32:00:95 l3 all tag cpzoneid_2_auth dnpipe 2004 ether pass out quick to 9c:05:d6:32:00:95 l3 all tag cpzoneid_2_auth dnpipe 2005 } anchor "d8b370834988" all { ether pass in quick from d8:b3:70:83:49:88 l3 all tag cpzoneid_2_auth dnpipe 2006 ether pass out quick to d8:b3:70:83:49:88 l3 all tag cpzoneid_2_auth dnpipe 2007 } } ether anchor "cpzoneid_2_allowedhosts" on igc1 l3 all { anchor "hostname_0" all { ether pass in quick l3 from any to <cpzoneid_2_hostname_0> tag cpzoneid_2_auth dnpipe 2008 ether pass in quick l3 from <cpzoneid_2_hostname_0> to any tag cpzoneid_2_auth dnpipe 2009 } } ################### # translation rules ################### nat-anchor "natearly/*" all { } nat-anchor "natrules/*" all { } rdr-anchor "tftp-proxy/*" all { } ############## # filter rules ############## anchor "openvpn/*" all { } anchor "ipsec/*" all { } anchor "userrules/*" all { } anchor "tftp-proxy/*" all { }

@SteveITS I didn't read everything yet, was busy trying to get the problem solved. As I said, I'll look at why since I use DHCP on a dozen networks at least.

@ivica.glavocic said in TAC support questions: For HA cluster do we have to buy two pfSense TAC support packages, or one is enough? Isn't "HA" always : "more then one" by default ? Both entities must be identical, where one acting as a master, and the other(s) is (are) acting as slave(s), all following all the interactions of the master. If the master detects a fail, a slave is elected and takes over. So, for me, 2 (identical devices !) at least. About bind : Have a look at this forum, there are pfSense users that use the pfSense bind package. Afaik : the bind GUI implementation isn't ... perfect. Loads of options are missing. And the version bind version used isn't the latest. I'm using bind myself as a autoritative domain name server, servings 10+ domain names, and have it synced to another (also mine) bind server, acting as the slave. It does DNSSEC, can do DDNS, and all kind of other nifty trick. My option is : it's 'impossible' to use a GUI to maintain the config of bind. Maybe with one domain name, and minimal settings ? Anyway, imho, pfSense is a firewall/router, not an autoritative domain name server. What about this solution : host your bind on another device with a real OS, like a rock solid Debian server, and set it up from there ? True, you have to edit the files (I actually rarely edit my bind's 20+ config files). I short : you're opting for a "HA" setup, so your installation becomes somewhat mission critical. In that case, divide important task over separate devices/hosts. The firewall != the proxy server != the DNS server != the file server etc. (!= = 'in not').

@stephenw10 That is correct. The adding of the second WAN/LAN was what caused it. I have not encountered this with only one WAN/LAN in play, which is why I ultimately pulled the second WAN/LAN completely and am (for the temporary present) not running it through pfSense.

Is it just me, or does it seem like the KISS (Keep It Simple [redacted]) answer is to install X-Ray on an officially supported platform or a VPS and tunnel traffic through that?

@dennypage Create an igmp rule on your floating rules, and do not set the direction to in. Set: Interface Leave: Direction to any Set: Protocol to IGMP only Set: Source to any Set: Destination to any Set: Quick Set: Adavanced Options, Allow IP options For example if you have pfblocker dnsbl auto rules (ping auto rule, permit auto rule) on top, it can cause trouble on the states. Check: the States of this rule. You should see tcp and upd packets as well, 443. If you set the direction on your lan intarfce to in, you should see igmp only, otherwise you have to place at the very top of all your other floating rules before everything else.

I have a WRT3200ACM running OpenWRT. Hard to recommend it though as the WiFi seems very unstable. I've never seen it stay up reliably across several versions.

Yes it will try if the remote side is configured as a single public IP. But behind CGNAT that usually isn't the case. It would work for the connection before failover as long as there is no nat in place to change the source ports.

@SteveITS Seems liek this was the issue! This option should be disabled by default. And of course it should be logged.

@thespirit I don't think it is really a bug. If it was changed so the auto-added rules were not overridden by a block all rule then that would be equally confusing as block all wouldn't mean block all. The way the code which generates the rules works it is pretty clear that user added rules should always take priority it probably just needs to be mentioned in the documentation somewhere.

@rpm5099 said in Fios DHCPv6 Issues: I'm assuming you are using the LLT method where your DUID is based on MAC and timestamp? I don't think the MAC is used. In those 7 years, I've changed both the computer I run pfSense on and my cable modem. Also, when my prefix changed, almost 7 years ago, it was because there was a problem at my ISP that messed up IPv6 for everyone connected to the CMTS I was. In my testing, I had identified the failing CMTS, but it took some effort to get them to fix it.

@njc :) here’s a couple

@marcosm Appreciate all this clarification. Thanks.

@johnpoz said in Custom options in unbound (dns resolver) cause syntax error: include wouldn't be part of it Oops. I corrected my post.

@patient0 Not a production environment just home environment. Thanks for your suggestion I'll give it a try. Best Regards and thanks again....

@kan84 Use also pfSense best interface : not the GUI, the console access ! You can see the state of your interfaces, and by inspecting the log file you can see what's going on.