@keyser said in How (and why) to create a management VLAN?: @ErniePantuso There is no “special” management VLAN entity. A management VLAN is merely a normal VLAN where you have defined Firewall rules on all pfsense Interfaces to block access to that particular VLAN/Interface. @keyser Got it. Thank you! I'm using the !RFC1918 rule on all my VLANS (with pass rules above it as necessary) so I think I pretty well have that covered. PFsense has no dependence on special interface naming, so you can just rename your LAN to MGMT if that makes sense to you according to the firewall setup. Cool. Thanks very much for the expertise and help!

The only thing I would be concerned about is the fact that igc1 lost link for some reason. Since it's connected to a switch directly it should not. Some of the early i225v revision (<rev3) chips had link issues. Try running: pciconf -lv igc1 `

Since I'm the OP I thought I'd chime in here. We changed what we do and don't clone anymore. Instead we keep a default config with 90% of the work done and have it import on a brand new install. That config does not contain the SSH keys or RRD data so we don't have to worry about it getting mixed up with other devices. Generally the only things we need to change at that point is the name and the WAN config and anything specific about that install. We leave the WAN to DHCP and plugged in upstream so that the packages reinstall on boot and then change when put in to place.

It seems far more likely that exhausting the available PHP memory causes #14061 rather than the other way around. This seems like a bug in the bind package and should be reported separately. If it hasn't been already. Steve

@stephenw10 @Gertjan Issue resolved thank you for you help. The Policy Routing Configuration doc was what I needed to follow.

@johnpoz Thank you for the quick reply. You are awesome, issue resolved!!

Actually my bad, I had to re-create all of the interfaces, etc under FreeRadius Service, its working fine now

@johnpoz said in AT&T screwed me over, now can't reach services behind pfSense from outside: One that that got my panties in a twist, is when I had an outage with comcast back in the day.. I wasn't getting an IP.. Which I clearly stated, and mentioned more than a few times.. I was showing link on the modem, but couldn't get an IP.. They wanted me to ping 8.8.8.8 - I was like how is that going to work, when I don't have an IP.. ugggghhh.. Just move me up the queue please! I feel your pain brother! Same with Spectrum (can't put what I call them). Phizix

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