-
In pfSense 2.1 snapshot builds you can enable captive portal on multiple interfaces. I suspect (haven't tried this) that each "zone" could have its own captive portal page.
Already pfSense 2.0.3 should be capable of enabling captive portal (CP) on multiple devices:
http://doc.pfsense.org/index.php/2.0_New_Features_and_Changes
Did you already try this feature? I've come across this point because I'm just thing about enabling CP for both one internal (cloned) WLAN interface and one SSID of my external access point (AP). My external OpenWRT AP is cloned with each of the two SSIDs serving one VLAN. However, I do not have any idea, if 2.0.3 can have its own portal page for each interface.Peter
-
I use 2.0.1, and there seems no way to have multiple portal pages. I don't really want to upgrade as I have made some changes to the captive portal script for my own needs, and don't want to have to tweak them to fit at this point!
It seems sensible to have different portal options available for different interfaces though.
There is an option for "bridges" on my interfaces page, so assume I can 'merge' two nics together then?
Thanks.
-
There are a few ways to arrange the bridge but the 'correct' way is to have the bridge interface assign as LAN and the two existing interfaces added as members of the bridge. They will then be OPT1 and OPT2. Set them up as type 'none' and do all the IP configuration on the bridge interface. It's very easy to get locked out of the box while doing this, I have done, repeatedly! ::) You should allow access form the WAN temporarily if you don't have it already so that you can still access the box. See my post here for a more detailed explanation of setting up a bridge: http://forum.pfsense.org/index.php/topic,48947.msg269592.html#msg269592
Steve
-
Great, thanks.
I have https access through the router to the GUI interface, so as long as the WAN interface is left well alone, I should be able to access and make any changes with ease. I will need to change the WAN interface first though (from PCI NIC to onboard), and make sure this comes back up, and remote GUI access is still possible before I change the other interfaces.
Not sure when I will be able to get around to this, but will report back with a smiley or a frown ;D
Thanks.
-
Actually, thinking about this.
The reason I wanted to seperate the two LANS was so I could determine which one was on use in the captive portal PHP script. If I bridge the two, I don't think I can determine which is being used? Using two seperate interfaces on the captive portal, I can see which is being used in the PHP script and do things accordingly. I can use the function portal_ip_from_client_ip($clientip) to determine which interface was being used, but would need different subnets on the interfaces.
I think when you add another interface and want to use it as another LAN, you need to setup some firewall rules to allow traffic, as the default LAN automatically adds rules?
Starting to confuse myself now!
-
I think when you add another interface and want to use it as another LAN, you need to setup some firewall rules to allow traffic, as the default LAN automatically adds rules?
Yes. When you add a new interface it will initially have no rules and hence will block everything. As you say only LAN has default rules to allow traffic.
Steve
-
Thanks.
Looking at the default LAN rule, I would set the new rule identical. I wonder if perhaps I should set the 'destination' to "WAN Subnet" instead of "all", so the AP clients only have access to the internet, and nothing else?
-
Thanks.
Looking at the default LAN rule, I would set the new rule identical. I wonder if perhaps I should set the 'destination' to "WAN Subnet" instead of "all", so the AP clients only have access to the internet, and nothing else?
That's probably not want you want. "All" is most likely want you want ;). With "WAN Subnet" you are restricted to the IP range that is dynamically attributed to your WAN interface. I remember that I once did the error as well during my numerous attempts with firewall rules :) So, hope, I didn't get you wrong.
Peter
-
Can I add a vlan tag to just the AP's in one building, leaving the others untagged like normal? Do I need to then change IP's? Can the Vlan share the same DHCP range as the untagged?
Yes you can have one AP tagged connecting to a VLAN interface in pfSense and the other untagged connecting to the normal interface. You would probably want them on different subnets so one or other would change their IP. If you wanted the tagged and untagged networks on the same subnet you would need to bridge the normal and VLAN interfaces in pfSense.
However the above setup is not recommended because some NICs/drivers do not handle tagged and untagged traffic simultaneously very well. You probably won't have any problems it's a rare case. It is better to set both APs to tag traffic to two different VLANs and then have two VLAN interfaces in pfSense. That way you will have all traffic arriving at that NIC tagged.Steve
How often do issues occur with putting tagged and untagged through a NIC? If there was issues, do they appear immediately and consistently, or is it one of those random and spasmodic type problems? I may opt for using a couple Vlans for the APs, and then use the LAN untagged still for a couple devices which sit directly on the network, and wont be able to put the tagging frame onto the packets sent.
Cheers for the support, it's greatly received!
-
Thanks.
Looking at the default LAN rule, I would set the new rule identical. I wonder if perhaps I should set the 'destination' to "WAN Subnet" instead of "all", so the AP clients only have access to the internet, and nothing else?
That's probably not want you want. "All" is most likely want you want ;). With "WAN Subnet" you are restricted to the IP range that is dynamically attributed to your WAN interface. I remember that I once did the error as well during my numerous attempts with firewall rules :) So, hope, I didn't get you wrong.
Peter
Ha!
No, that makes perfect sense when I think about it! Thanks for the pointer!
-
Thanks.
Looking at the default LAN rule, I would set the new rule identical. I wonder if perhaps I should set the 'destination' to "WAN Subnet" instead of "all", so the AP clients only have access to the internet, and nothing else?
That's probably not want you want.
I think that is almost certainly not what you want. For example, I suspect it is unlikely that www.google.com is on your WAN subnet.
A destination of "not LAN subnet" is probably closer to what you want but that is unlikely to be adequate if you add interfaces and subnets to your configuration. -
How often do issues occur with putting tagged and untagged through?
Not often. It's a glitch that shouldn't happen and I've never seen it. As I understand it some combinations of NIC and driver will use hardware VLAN tagging to off-load work from the CPU and incorrectly discard untagged packets. I would expect the consequence of this to be traffic from the non-VLAN network is blocked with no obvious cause. I only mention it because if you're unaware of it it could be very frustrating!
Steve
-
I've never seen a problem mixing untagged and tagged on a single port. Problems aren't why it's not a recommended practice. It can be possible to drop from a tagged VLAN into the untagged VLAN, which is why most switch vendors specifically recommend not using the untagged VLAN on trunk ports (amongst other possible reasons, none of which are related to functionality problems caused by doing so).
-
Thanks for the correction Chris. :)
No idea where I picked up that nugget of misinformation.Steve
-
@cmb:
I've never seen a problem mixing untagged and tagged on a single port. Problems aren't why it's not a recommended practice. It can be possible to drop from a tagged VLAN into the untagged VLAN, which is why most switch vendors specifically recommend not using the untagged VLAN on trunk ports (amongst other possible reasons, none of which are related to functionality problems caused by doing so).
Thanks for that.
Am I likely to run into problems do you think?
Basically, thinking of using the vlan feature of my access points to create two vlans, and leaving anything connected directly to the lan as untagged. No vlan switches as such (just the AP's), but guess this would count as a 'trunk' between the AP and the PFsense NIC? It does go through 1 or 2 unmanaged switches.
-
Well like I said I have never seen an issue but I've always been careful to avoid tagged and untagged traffic (for the wrong reason it turns out ::)). The worst that can happen is that something that isn't configured quite right strips the tags somewhere in the chain such that traffic arrives on the wrong interface in pfSense. If you are only handling tagged traffic on the NIC those packets will just be dropped.
You are very unlikely to see any issue if you have everything configured correctly.
You will need to investigate how your unmanaged switches handle VLAN tagged packets.
Steve
-
@cmb:
I've never seen a problem mixing untagged and tagged on a single port. Problems aren't why it's not a recommended practice. It can be possible to drop from a tagged VLAN into the untagged VLAN, which is why most switch vendors specifically recommend not using the untagged VLAN on trunk ports (amongst other possible reasons, none of which are related to functionality problems caused by doing so).
Thanks for that.
Am I likely to run into problems do you think?
Basically, thinking of using the vlan feature of my access points to create two vlans, and leaving anything connected directly to the lan as untagged. No vlan switches as such (just the AP's), but guess this would count as a 'trunk' between the AP and the PFsense NIC? It does go through 1 or 2 unmanaged switches.
Have I got you right that you connect your AP to pfSense via unmanaged switches? In theory your unmanaged switches do strip off the vlan tags form your AP traffic. This way network packets coming from your AP cannot be attributed to the right network within your pfSense box.
If your AP emitts vlan tagged traffic and you are not going to use a managed switch, you should connect your AP directly to pfSense. I've read about it in the pfSense forum but cannot find the thread anymore.
Peter
-
Have I got you right that you connect your AP to pfSense via unmanaged switches? In theory your unmanaged switches do strip off the vlan tags form your AP traffic. This way network packets coming from your AP cannot be attributed to the right network within your pfSense box.
If I recall correctly, at least one reader of these forums has reported that packets with VLAN tags go through their unmanaged switch with VLAN tags preserved. My suspicion is that an unmanaged switch probably wouldn't bother to strip VLAN tags. But it is better to check than assume.
-
I think I will just use an additional NIC to be safe. It will be easier in the long run, with any fault finding or replacing of failed APs etc.
I currently have one NIC as LAN, cabled to an 8 way switch, 4 Poe ports on this feed 4 APs in one building, spread around. There is then a cable from here to another building over the road, which connects to an identical Poe switch which itself feeds two APs. There is then a couple bits if kit (jukebox and tv) connected directly to the switches on non Poe ports.
I think I will use a second NIC, and have one feeding one switch, and one feeding the other. That way the APs in one building will be on one NIC, and those in the other building on the other NIC.
I currently use the DHCP range 192.168.11.1-192.168.15.254, the interface being 192.168.8.1/21
I would put the second range as 192.168.18.1-192.168.23.254, this interface being 192.168.16.1/21Ideally I would swap to a 172.16.x.x range, but the jukebox has hardcoded IP, subnet, gateway and DNS, and only the jukebox company can change this, so easier to leave at 192.168.x.x
-
If I recall correctly, at least one reader of these forums has reported that packets with VLAN tags go through their unmanaged switch with VLAN tags preserved. My suspicion is that an unmanaged switch probably wouldn't bother to strip VLAN tags. But it is better to check than assume.
Thanks, wallabybob, you're absolutely right.
Peter
-
Exactly.
You might think that any switch capable of handling jumbo frames would also be able to cope with VLAN tags. However I guess it is up to the firmware author to correctly identify/deal with them.
It's an interesting topic though with no definitive answer after a few minutes Googling. There are many people saying 'absolutely definitely not, will never work' and also, more rational, people saying 'it might'. Here a good post:
http://blog.pressure.net.nz/2008/11/the-amazing-unmanaged-trunk-mode-switch/I agree that adding a separate NIC will be better in almost every way if you have that ability. :)
Steve
-
Indeed from experiences of others, it seems most unmanaged switches will pass through 802.1Q tags with no problem. I've seen several customer networks doing so for years with no issues. I would never rely on that in any network of mine though and can't say I'd recommend it.
-
Ok.
I have split the network across two interfaces now, and it is all up and running.
I add some static IP mappings to some MAC's to force them to keep the same IP, for particular staff members iPhones etc. In the DHCP stats, it shows these users as being "online" with BOTH IP's, one for one interface and one for the other. I have added them to both DHCP config pages as a static mapping. Is this going to cause issues?
Thanks.
-
Ok.
I have split the network across two interfaces now, and it is all up and running.
I add some static IP mappings to some MAC's to force them to keep the same IP, for particular staff members iPhones etc. In the DHCP stats, it shows these users as being "online" with BOTH IP's, one for one interface and one for the other. I have added them to both DHCP config pages as a static mapping. Is this going to cause issues?
Thanks.
I've configured multiple static dhcp mappings for the same MAC address in different networks. This setup is running for more than a year now without issues. I'm observing as well that often a MAC address is shown "online" in multiple networks at the same time. But that's so far the only "issue".
Peter
-
Yes, It seems to work fine and as expected. I didn't notice the DHCP status page showing multiple entries until I was off-site and looking at them remotely, and so could not check. I have since gone past the site and checked, and all seems to work just fine.
Thanks.