its not dns broadcasting... It would be the client doing a netbios broadcast for the hostname... Hey who is called somehost.. So your clearly not doing dns redirection. So you want to set it up correctly.. Point your clients to pfsense, or some other local NS that will resolve all your local resources, and will then forward or resolve all your public dns needs. Pointing clients to outside NS is not going to allow you to actually resolve any local resources, nor will it give you the ability to block bad stuff.. You have no control over the dns at all when you tell client to use 8.8.8.8 for their dns.. But if you have them point to something local for dns, say pfsense - you then can control stuff by blocking stuff you don't want them to get to.. You can resolve say www.whatever.com to the local IP its hosted off of, vs getting the public IP for this fqdn and having to use nat reflection. Also pointing clients locally allow you save some bandwidth, because if client A looks up www.something.com, and then client B asks for it its already cached at your local dns, and doesn't have to be looked up again, etc. So fix it already - not really sure why we are stilling having this discussion ;)

Yeah it would be hard to do. Most things like that involve edits to multiple sections. You could maybe diff the configs against default and then apply it as a patch. But you would likely only be able to apply one patch as subsequent patches would not apply cleanly. Steve

@PhlMike said in Looking for syslogs to update my cyberattackmaps website: That is interesting, I have over 100 pfSense firewalls and I use pfmonitor as well, I could probably aggregate something if I can figure out how to automate it and remove anything sensitive. That could be interesting indeed. If you like to give it a try, maybe for just 1 one them, please let me know. If you want to I can also try make a TCP (ssl) port available instead of UDP. But then you will need some customization (syslog-ng forwarding?) in pfsense in order to send to that I believe.

@jvansyoc said in Allowing users to add/remove/modify additional user accounts but not admin accounts.: Using the FreeRadius server package on Pfsense is something I have used as will for MFA on VPN. I'd encourage you to try as - together with OpenVPN - you can actually use FR to implement things you normally would need CSO (client specific overrides) for such as handing out a static ip for specific users or time limits, logout times etc. So for every RAS VPN setup I always encourage our customers to use OVPN+FR together as it provides them more flexibility. I should clarify that I'm looking to allow the end-user access to add and remove VPN users without having to contact me or have system administrator access. The suggestion to use FreeRadius is a great idea and I will get back to this with my testing. Then I'd say go the route and couple OVPN with FR :) It will pay out in multiple ways ;)

Yes, to pfSense the packets are arriving when I try to do for example a ping from DC1. DC1: root@dc1:~# ping xmpp.domain.tld ping: xmpp.domain.tld: Name or service not known pfSense: Diagnostics/Packet Capture Host Address: 10.10.20.2 Protocol: Any Packets Captured 15:56:06.248804 IP 10.10.20.2.60725 > 10.10.20.1.53: UDP, length 51

Few different things, first, the SG-1100 works, we test it, we run it, we know it will update when the time comes. We stand behind our hardware if there is an issue, we will replace it. For another vendor, that make the j1800 when you run into a problem that is hardware based, you are relying on another company for their support. When you purchase from Netgate, you are buying from a small company, you support us.

Yeah. There are many things that someone with access to that box could do and you don't want any of them! I assume speedify give you a private IP when you connect to them so at least you are not directly accessible that way. If it's behind other routers on the WAN connections it may not have a public IP at all which at least reduces the risk. But...

@NogBadTheBad 192.168.1.1 is the IP of the pfSense. 192.168.1.2 is the IP of the wifi router. Everything else is 192.168.1.*

@fr334fr4nk Can you just hard code the IP of the server to use the failover gateway. It's only one. Disregard, I read "doesn't fix it for me"

@skee9679 said in After upgrade, problems loading certain websites: I guess my question is what counts as many? What I know is : When a "new DHCP device" pops up in the network, it request an IP (using DHCP DISCOVER operation). The new lease will be written in a file, that unbound (the Resolver) uses. unbound is not capable of detecting the "file change" and reading it in again, unbound has to be restarted (stopped, and started) so that the new lease is taken in account. That's why I advise you to remove the check for "DHCP Registration". If you want a device to be "known" on your network by it's host name, put in place a Static DHCP mapping on the DHCP server page. This way, unbound case resolve somethining like your-local LAN based printer.your-pfsense.tld to an IP. These devices never change their IP (== they always get the same IP from the DHCP server) so use that method : [image: 1562332099915-026f9511-d5c8-4554-bfed-c7c942bbc3e9-image.png] unbound not starting means also : it's cache becomes actually usefull (and you ask unbound to refresh cache items by itself when they time out - see below). This way the Resolver becomes also a good DNS cache ==> speeding up DNS treatment. DNSSEC : normally, DNSSEC should be totally transparent for you / your device / browser. DNSSEC will (or could, or shall, I don't know) give issues when a DNSSEC info is wrong or missing. If you have a doubt, use this site : http://dnsviz.net to test the domain in question. Btw : I've also set these on the Services => DNS Resolver => Advanced Settings page : [image: 1562334480324-5465154f-d167-4745-864e-e1e4c962b2b5-image.png] The last two options enforce DNSSEC handling, which means (to me) : if DNSSEC is wrong, then I can't visit that site. Not a problem for me, because sites admins that use DNSSEC better have settings correct. If not, their site will dissapaer from the net, for those who use DNSSEC for what it meant to be : getting correct DNS info - or nothing else ("domain not found error"). DNSSEC info is just like classic DNS info, although, because of the much bigger info records, the traffic - DNS requests and/or answers , will go TCP instead of UDP. (you permit DNS over TCP, right ?! DNS isn't only UDP port 53). Option "Prefetch Support" explains itself : it keeps my cache up to date - as I mentioned above. Use this site https://dnssec.vs.uni-due.de/ to test and see if DNSSEC functions correctly for you. This site also mentions other test sites - see bottom of the page.