Captive Portal attaching to all interfaces?
-
Hi all,
Odd situation that I've run across here that I have a workaround for but wanted to try and ID the root cause. My box has external client VPN connections for external routing and multiple vlans inside for zones. After moving my install to a new box it seems that for some reason captive portal, despite being checked for only attaching to the guest vlan, is trying to force authentication on all internal vlans. Oddly enough, when I restart the vpn client on the outside it actually kills the captive portal function.
These are distinct physical interfaces and the client is attached to the external interface specifically, but somehow they end up affecting each other. For now I expressly attached the captive portal to all interfaces and allowed the netblocks for those I don't want to be forced to authenticate, but it's not exactly the ideal solution.
Is there a good place to check for what might cause this?
-
That's very strange. ..
I am using pfsense in a similar setup (box with VPN enabled to the outside, multiple vlans on the inside) and i Never ran into your issue
Could this be related to https://redmine.pfsense.org/issues/7553 ?
-
I wouldn't suspect so, there are no variance for interfaces being tagged or not. The internal are all given express vlans while the externals each host one vpn client. If I was to take a guess it might have something to do with when I migrated machines and had to do some manual config edits to get the interfaces to be read correctly on the new server.
For now I'm actually not too worried on it, in a way it's nice to have it act as a psudo 802.1x system, if the device is not in the reserved IP space and takes a DHCP lease it gets caught in the captive portal. Would still be nice to figure where the bug is though.
-
Was digging into this some more today when I realized it is seemingly affecting external facing services, and it turns out the captive portal is even trying to bind to the WAN interface, though oddly enough it seems to skip the WAN2, although that one has no inbound traffic available anyhow so more a side-note.
I did a comparison between the configs when setting the interface to all those seemingly affected (left) and the desired state (right) aside from the expected things like time and RRD files the configs read identically. Yet somehow unless the portal is turned entirely off it holds open a socket on every available interface.
Most bizarrely perhaps is that in order for HA Proxy to be able to function normally and allow traffic inbound for 80/443 services I currently have to 'enable' the captive portal on the WAN interface, although it doesn't appear to actually capture anything (nobody outside has to login to the portal to reach the proxy served pages), even though the service still shows a listening socket and an external source wouldn't be able to get a service on the relevant 8002/8003 ports anyhow.
-
I didn't even know that we could select multiple interface for a captive portal :
I also thought the captive portal would use the interface that had the 'NAME' selected, like PORTAL in my case.
Not the internal name like OPT1 or OPT4 or LAN - although renaming interfaces isn't needed.<interface>opt1</interface>Which is correct PORTAL is the name for my OPT interface (not opt1 btw ..)
I guess what happens is : you changed systems, so there was a new NIC set. Interfaces names will get shuffled, and the old OPTx will get assigned a another NIC.
Not a big deal actually. When you move from hardware A to B, all settings have to be reviewed anyway. -
Yeah, and unfortunately after years of evolution in the environment (home lab, so subject to far more just-do-it variability) the original optX numbering is all over the place as interfaces have been split off and merged over time. So bit of a pain to keep track of. At least the current hardware should be good for a long time to come, running on a Dell R710.
Still, for whatever reason despite the config only recognizing opt10 as the valid portal interface in the config it tries to bind to multiple interfaces, which is extra weird because I don't recall ever having intentionally set it up that way. Another thing I noticed though when the box happened to spontaneously crash and restart this morning (rare but not unknown) is that the sockets where all shown as open, but the captive portal was not capturing anything until I manually restarted the service, which is scary if it where to happen and I wasn't in a spot to do so at the time of such an event.
Much as I hate the thought it might just be time to manually rebuild the system, soooo many lease reservations, aliases, and rules to configure by hand... Pretty sure this one has been kicked around since sometime before the 2.2 era though.
-
What about downloading (backup) the config.xml, edit the <interface> .... </interface> and import it.
pfSense will not (should not) auto select 'some interfaces' by itself. -
The interfaces are good, the modifications that where needed during the system migration where all for the physical links, ie: em0 became bge0, so switching the bindings of the existing optX interface and their associated vlans to the new links. Like in the screen above with the config comparison, the system isn't so much selecting interfaces, at least not in the config, but somewhere the interpretation of the config is telling it to bind the open socket and traffic capture function to other interfaces.
-
Well, update as it is. Ended up doing some testing with a fresh install and found the portal appears to open several sockets regardless of the interfaces even from base, so seeing that on the status was a bit of a red herring. The behavior though somehow still showed the others affected, however...
After reloading the existing config it no longer was binding to all the ports, until the portal stopped capturing again (still showed as running though), re-starting the config brought the multiple interface issue back. Interesting note that I'll have to keep testing though, Specifically attaching it to another interface, saving, then removing the second interface and save again and it behaves as expected.
I would consider using the portal on my APs, but they have no option for a allow-by-mac as the onboard one does which is very handy for things like the work laptop that I don't want on net, but don't particularly want to auth all the time either.
Whelp, nobody ever said having a fancy lab would be easy. Will keep poking at it and update in the rare chance that someone else runs into something similar later on. Might have to finally get more friendly with BSD as a system itself.
