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

@NollipfSense Excellent advise my friend and very well appreciated. I bought the first one. Fingers crossed it will work Ok :-) I checked the feedback earlier today and other buyers have reported that it works Ok with Pfsense. Again, many many thanks.

@stephenw10 Thank you very much, it works perfect!!! I don't know why I didn't think before at such simple solution

@stephenw10 Thank you very much, It works great .. however LACP had some issue with Firmware 23.05 once I upgraded to 23.09.1 that resolved too. [image: 1708230917779-0f4eb7f0-c82f-4934-8523-9ca214bf311f-image.png] Also as for record spoofing MAC Address in LACP breaks the connection so spoofing must be disabled.

@stephenw10 thank you very much. i will look into all this