@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 :

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 :

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.

@stephenw10 Seemingly peering at major IXPs around the USA, but it's a small local ISP. And it's not just a gimmick. The bandwidth is very stable and these routes seem to continue to function even when there's regional internet outages.

Of course with enough money, you can get your own fiber, but we're talking about each IX being thousands of miles away and the podunk ISP has ridiculously low prices. Private MPLS comes to mind, but I have always assumed that to be very expensive and reserved for high tech companies like Google or Amazon where latency matters.

I do enjoy when situations like "Battle.Net is down for the entire Midwest due to routing issues" and I'm unaffected. And peering disputes seem to be a thing of the past. It seemed like once every few months, some congestion issue between transit providers would occur in some of my routes. But now that most everything is just direct peering and all of the traffic is effectively "tunneled" over from private route, it's been an issue of the past.

Even without IX peering. Pick a game server on the west coast

1 <1 ms <1 ms <1 ms pfsense.localdomain [10.255.42.1]
2 <1 ms <1 ms <1 ms 192.168.1.1
3 2 ms 2 ms 2 ms redacted
4 2 ms 2 ms 2 ms redacted
5 3 ms 2 ms 2 ms ISP redacted
6 13 ms 13 ms 13 ms 4.71.102.197
7 62 ms 62 ms 62 ms 4.69.202.241
8 62 ms 62 ms 62 ms 4.28.172.102
9 62 ms 62 ms 61 ms 159.153.68.252

Routes look a lot different to me from just a year ago.

So magically my Hyper-V host now has an IPv6 address and IPv6-test.com seems to work for me 100% from it w/o making any changes, not even a reboot of either the host or FW. I still have the issue where my Win10 laptop performs intermittently, but works if I bounce to another access point and continues to work even if I bounce back. Just weird.

At any rate, I have noticed that from all machines the test results list my IPv4 WAN address, but all the IPv6 addresses are machine-specific. Is there a short answer to this or is it just how IPv6 works? The range assigned is not the same as the WAN v6 address. Thanks for any replies.