Thank you so much for providing this information. Ever since Xfinity did their infrastructure upgrade in my area I would have intermittent connectivity with one of my WAN's. Currently, I am running two WANS (both Xfinity) and have them in a load balance configuration. When I initially set this up in Pfsense everything was working fine. After the Xfinity upgrade the non-default WAN would intermittently lose connectivity and show as 100% packet loss. The weird thing about this one it would only drop the non-default gateway. The default gateway was always up. So if I swapped the default, the packet loss would also follow the other non-default gateway. So I knew this wasn't a hardware problem, For the past 4 months I have been trying numerous troubleshooting steps including a complete reconfigure of my pfsense setup from scratch and nothing worked, at least not until I added 'supersede dhcp-server-identifier 255.255.255.255' under "Option Modifiers"

Thanks again, this saved my sanity. :)

@michmoor said in Captive portal - what am i missing:

Did i just need sleep?
Maybe staring at a problem fixed itself

Ha, well that can happen. I'd love to know what changed though. I guess something expired somewhere. Though you would have thought anything that could apply here would have already expired during testing.

What is logged in the system log when it fails?

USB Ethernet is generally not recommended though.

I use an external LTE modem, which is basically transparent to pfSense/FreeBSD.

https://www.netgear.com/home/mobile-wifi/lte-modems/

You will have to configure pfSense for WAN failover.

Found some time and took another look at this and discovered that the WG tunnel between the two relevant hosts was missing the allowed IP of 0.0.0.0/0 to route over the WG tunnel to the internet from one WG host to another. A quick fix then...

Frustratingly, i remembered this same issue for another fault from long ago and recalled the key text from the official documentation that "....when sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list." The differences are seldom drawn on in WG 'cheat sheets' but is essential for the routing - i suspect most people blindly following guides assumed it was only to force a default gateway for a WG host.

It's still a bug in current dev builds: https://redmine.pfsense.org/issues/15282

It would probably be better to pretend to be some other router or in fact to not expose anything that allows determining the router type at all. IMO 😉

@bavcon22
There is nothing special at all. The client (server in DMZ) has to pull the data from the NIS server on pfSense.

To let the NIS server listen on any interface IP, set it to 0.0.0.0. Add a firewall rule on DMZ to allow access to the port 3551, or which your NIS is using on, to the DMZ address.
And configure the client to pull the information from the pfSense DMZ IP.

Thnx

No issues for 9 days now, guess I will leave it in this configuration. Thanks for the suggestions.

@incith I didn't hear any response from you, but in case you are not monitoring the main NUT thread, a fix was posted there today for your issue.

FWIW, the issue was specific to the legacy Tripplite protocol and was not an issue with USB. Details can be found in the NUT thread.

@enrilor
Just noted that you need to set the servers verbosity level to 3 to log added routes.

And you have to restart the server as mentioned.
I'd expect to see a log line with the OpenVPN version, when the server is starting up. I'm missing this in your log snip.

The CSO is applied properly according the log. But remote networks, you've set there are is not reflected into the system routing table. This is only applied within OpenVPN.

As mentioned, it's the "Remote Networks" setting in the server configuration, which adds system routes. And the OpenVPN log should show this action.

OK then you probably need a VIP on the WAN in the modems subnet and an outbound NAT rule.

https://docs.netgate.com/pfsense/en/latest/recipes/modem-access.html?highlight=modem#configure-nat

@Gblenn said in Proxmox GUI on lan won't work:

With Proxmox on the same subnet, there is no reason hatsoever why it shouldn't be accessible...

Thought your Proxmox's management was already on the same LAN as pfSense. I run Proxmox on Virtualbox on my MacBook pro so I can look at Proxmox's interface wherever I am be it home, coffee shop or friends (just change the IP) to help others, hence the picture.

@dennypage said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

here: https://fc-ntp-100.toimii.fi.

Cool...thank you for sharing.

@Neosmith20

Did you check the file you've imported ?
I mean : open it, and 'read' it. Is very readable.

What happens when you install a clean pfSense, do minimal setups, just make it work with a WAN and LAN, and a new admin password, and then export the config.xml file (Diagnostics Backup & Restore Backup & Restore ).
Then import that file back in.

If that works fine, things start to point really to a faulty, 'wrong syntax' config file. You took the file from a crippled file system .. so .....

If that doesn't work neither, ditch the entire 'system', as issues are probably on a lower level, like file system ko etc..

Do you have access to Services > Auto Configuration Backup > Restore ? == backed up config files ?

@johnpoz said in why doesn't the "Firewall Maximum Table Entries" get set based on Ram of system:

alias

@rebootnz if you use Alias Native pfB just creates the alias, and you can create your own rules or use it as a source for NAT rules.

Ah, interesting! That's good to know. 👍

Yup try that. If you're on 2.7.0 also try running: certctl rehash

https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html?highlight=certctl#debug-pkg-metadata-update

Steve

@KOM The other record types make it resolve able but the record type is wrong for automatic KMS activation. So i did add the custom option as well to get the correct record type.

So i did the following:

server:
local-data: "_VLMCS._TCP 3600 IN SRV 0 0 1688 kms.dmz.ls.lan"
local-data: "_VLMCS._TCP.ls.lan 3600 IN SRV 0 0 1688 kms.dmz.ls.lan"
local-data: "_VLMCS._TCP.dmz.ls.lan 3600 IN SRV 0 0 1688 kms.dmz.ls.lan"

The first line is to make sure custom lines don't break the DNS resolver. I have 2 networks one (LAN) with the domain name ls.lan and the other (DMZ) with the name dmz.ls.lan i want machines to be able to activate from both networks. Firewall between both networks is oneway traffic only from LAN to DMZ not the other way around.

So the first local-data line is to make sure machine can activate when they are not aware in which network they are in. The other 2 are for the machines that do know that.

On windows machines you can test with nslookup if everything is setup correctly.
In my case all 3 return a service record.
nslookup -type=srv _vlmcs._tcp
nslookup -type=srv _vlmcs._tcp.ls.lan
nslookup -type=srv _vlmcs._tcp.dmz.ls.lan