Yup, you'd see broadcast traffic from the other firewall but unless you have something configured to do it (or misconfigured!) I wouldn't expect to see unicast between them.

@stephenw10
Thanks! It's working and I suspect I did that when I was trying to setup and test different VPNs. (Ended up with Tailscale - had issues with OpenVPN, PureVPN, and multiple others - either they couldn't do something or it was a feature trade that didn't work for me.)

That's how the xmlrpc for config sync works. It implies the secondary didn't respond for some reason. Perhaps it was down at the time?

Although the 2100 has a switch you don't need to have any config for it. By default it uses the two NICs (mvneta0/1) for WAN and LAN and without any specific switch config the switch just acts as a 5 port unmanaged switch on LAN. So if you only have two interfaces in your CE config you can import that to the 2100 and just reassign them. The same is true for the 3100. It is not true of the 1100 which requires the switch to be configured.
If you have more than two interfaces though you would need to configure the switch to separate the ports.

Steve

@fenster Sounds more like an AP problem than something to do with pfsense... Have you checked out the Ubiquiti forums for help? Perhaps take a look in your Unifi Controller for any clues...

Could be lot's of different radio problems. Do you have more than one AP, does it happen on both bands? What about neighbours with wifi?

@stephenw10 After a factory reset, it is working now. All my WAN rules are back in place, and I was able to install multiple packages from the GUI. Still not sure what the problem was.

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.