Captive Portal is too Broad
-
I'm not sure if this is suppose to work this way but I have a network (a /24) that I have sub-netted into a /27. My in my example lets say that I took a 192.168.12.0/24 network broke that down into a bunch (8 to be exact) of /27. My lan is 192.168.12.0/27 and my wireless network is 192.168.12.32/27. I turned captive portal on for the LAN only, not the Wi-Fi however when ever a Wi-Fi user tries to user the internet they don't go to the captive portal page but they can't surf or ping at all. When I add 192.168.12.32/27 to the allowed IP list everything is working again. But When I setup captive portal I told it to only run on the LAN subnet only. What's the deal here? Is anyone else experiencing this issue. Below is the build that I'm running:
2.1-RC1 (i386)
built on Thu Aug 1 19:03:40 EDT 2013FreeBSD 8.3-RELEASE-p9
-
Captive portal works for an entire interface, not just one subnet at a time.
-
Separating networks by subnetting on the same interface is an…erm...interesting approach. Such a deployment might a nice funny idea for a hacking competition, because noone will believe that a challenge is based on such a stupid idea. ;-)
The safe solution is to use a separate physical interface for the WLAN network (can also be done via a VLAN-capable switch, if the box doesn't have enough physical NICs).
An unsafe (hackable) way would be to use one network for LAN and WLAN, with LAN clients using static IP addresses and and the pass-though feature of the Captive Portal for these.
-
Yes, if you're doing it with a bunch of IP aliases on a single interface on pfSense, then you may want to reconsider the design and to go with VLANs.
However, if you reach the multiple subnets via a Layer 3 switch or other router, it's a valid/fine setup to run that way, it just wouldn't be compatible with captive portal.
-
Okay just so that I'm clear on this. If I take a parent interface (em0) and I create two sub-interfaces: em0_vlan32, em0_vlan64 and I want to apply the captive portal on the em0_vlan32 (LAN) interface then I can only apply it on the em0 interface which would essentially apply it for both em0_vlan32(LAN), and em0_vlan64(Wireless) interfaces?
In the GUI of pfsense why does it give you a option for your sub-interface(s) if you can only use the parent interface? This is the behavior that I'm seeing. I hope you guys didn't think that I was just sub-netting without creating the Vlans to go along with the interface(s). If this is the intended behavior I have no problem with, however I believe I had this working on previous versions of PfSense (2.03) without any issues. If this is not the intended behavior it should be easy to duplicate in a lab environment.
-
If you activate it on a VLAN interface it would only be active on that one VLAN interface.
Using CP on an interface with the parent interface (untagged) also assigned has historically been a problem. Last I heard it worked OK but if you have issues, try turning that into a tagged interface also. (change em0 to em0_vlanX where vlanX is that port's default VLAN, change the switch to match if needed)
-
OK I will try this. Right now my LAN is untagged. I will report back with my findings. Just out of curiosity do you know if this behavior (making your LAN untagged) depends on the brand of NIC or is the behavior consistent across all brands of NICs? I know it is probably not a good idea but I like to keep the LAN untagged that way if something crazy were to happen with a switch I could simply plug my laptop into the LAN port directly and be able to communicate with PfSense, assuming I don't have a Comm Port or a VGA port.
-
Just out of curiosity do you know if this behavior (making your LAN untagged) depends on the brand of NIC or is the behavior consistent across all brands of NICs?
The brand of NIC should only affect the maximum MTU (which may be reduced if VLAN tagging is done in software).
I also use non-tagged networks along with VLANs. It makes no sense to add uneccessarily complex VLAN setups for the networks needed for device management - unless you want to deliberately make things more complicated, for whatever reason. There are downsides. One is that traffic on the tagged interface also appears on the traffic graphs of the (untagged) parent interface. Well, whatever - I have not yet encountered any serious downsides.
Note that I currently use this such VLAN/untagged setups only on the production systems which are still on 2.0.3.
-
Finally got around to getting back to the site where I was having this issue and it was indeed like jimp said. By not tagging the LAN port with a VLAN (other than 1) when I turned on the Captive portal it effected all my Interfaces that were vlans off the parent. The fix was to create another VLAN and attach it to my LAN interfaces. This got me to thinking though, could I fix this without creating another VLAN? The following is a exercise in my mind and is untested (But should work). Observe the network below:
1. Create a VLAN 1 under Interfaces->Assign->VLAN
2. Add it to LAN
3. Console over to your Cisco Switch and change the native VLAN on trunk Which will cause VLAN 1 to be Tagged. *
4. Enjoy (should be all good)- If you have a IOS device that supports the follwoing command: vlan dot1q tag native this will cause vlan 1 to be tagged on your trunk port. So you don't have to change the native VLAN.
I just found it easier to just make a new VLAN and make all the configuration changes needed.
