Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Hello Felipe, Le 19-06-11 à 13 h 08, Felipe Rodrigues via PacketFence-users a écrit : Hi guys, Just help me to clarify one thing: - The registration interface is isolated in packetfence right? Does this interface need internet access or need to access the ip adress configured on the network detection page? Yes the registration interface is isolated from the other interfaces by iptables (except if you enable passthrough) and devices on the registration network doesn't need to go on internet or on the network detection ip address. I ask this because apparently the CoA process is working properly. I can see the disconnect packets being forwarded via Wireshark and via packetfence log (Both ways), but the device is taking a while to do the VLAN exchange. With this delay, I believe the device tries to do the "network detection", but it's still in the vlan of registration, so I'm seeing this error. After the CoA, do you see a new radius authentication coming from the WLC ? Regards Fabrice Detail: I'm just doing tests on MAC devices (Iphone and Macbook Pro). I will try to test with an Android device to validate this question. Thanks! *De:* Ivan Saliu via PacketFence-users *Enviado:* terça-feira, 11 de junho de 2019 10:58 *Para:* packetfence-users@lists.sourceforge.net *Cc:* Ivan Saliu *Assunto:* Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Fabrice, Thanks for the tip, changed the parameter and now also this is working fine Ivan *From:*Durand fabrice via PacketFence-users [mailto:packetfence-users@lists.sourceforge.net] *Sent:* martedì 11 giugno 2019 03:24 *To:* packetfence-users@lists.sourceforge.net *Cc:* Durand fabrice *Subject:* Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hello Ivan, Le 19-06-10 à 15 h 01, Ivan Saliu via PacketFence-users a écrit : Hi Nicholas and Felipe (hopefully you stuck with us), So now I’ve understood what I was doing wrong and it was just so stupid that I can’t even… Basically I did two things: -I put the custom port for CoA (1700 on Cisco WLCs…why use standards…) on the field Disconnect Port (Policies and Access Control -> Network Devices -> Switches -> My WLC). I found from the packetfence.log file that it was working only the authentication, but the VLAN switch was of course not working since it does a CoA de-authentication to move the VLAN. -Also the second step was also to put Advanced Access Configuration -> Captive Portal in the IP field the Registration interface IP otherwise it wouldn’t recognize in any case internet access. Right now the captive portal is working fine, I do have some more things that worries me that I noticed from the packetfence.log file like the following error: Unable to extract SSID of Called-Station-ID, which if persist actually makes more difficult for me to distinguish between SSID and present a different captive portal for other users, but these are a lot less painful issues than the one that I’ve just solved. You just need to fix the format of the Called-Station-Id attribute in the WLC config. Regards Fabrice Thanks again Nicholas for your support, as you said it was indeed a configuration issue, Hope you all had a nice day, Ivan *From:*Ivan Saliu *Sent:* lunedì 10 giugno 2019 15:47 *To:* packetfence-users@lists.sourceforge.net <mailto:packetfence-users@lists.sourceforge.net> *Cc:* 'Nicholas Pier' <09np...@gmail.com> <mailto:09np...@gmail.com> *Subject:* RE: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Nicholas, The issue is the second one you pointed out: * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. They get the proper IP address….so the issue is when PacketFence needs to update the VLAN via Radius? Still don’t get why the behavior is this one, I’ve checked and the Deauthentication Method is set as RADIUS, Use CoA is enabled, and I even put into the CoA port 1700 since Cisco’s WLC uses that. The only thing that is missing is the Controller IP address field but I don’t think this should cause the issue. Ivan *From:*Nicholas Pier [mailto:09np...@gmail.com] *Sent:* lunedì 10 giugno 2019 13:58 *To:* Ivan Saliu mailto:ivan.sa...@kikocosmetics.com>> *Cc:* packetfence-users@lists.sourceforge.net <mailto:packetfence-users@lists.sourceforge.net> *Subject:* Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Ivan, Let's st
Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Hi guys, Just help me to clarify one thing: - The registration interface is isolated in packetfence right? Does this interface need internet access or need to access the ip adress configured on the network detection page? I ask this because apparently the CoA process is working properly. I can see the disconnect packets being forwarded via Wireshark and via packetfence log (Both ways), but the device is taking a while to do the VLAN exchange. With this delay, I believe the device tries to do the "network detection", but it's still in the vlan of registration, so I'm seeing this error. Detail: I'm just doing tests on MAC devices (Iphone and Macbook Pro). I will try to test with an Android device to validate this question. Thanks! De: Ivan Saliu via PacketFence-users Enviado: terça-feira, 11 de junho de 2019 10:58 Para: packetfence-users@lists.sourceforge.net Cc: Ivan Saliu Assunto: Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Fabrice, Thanks for the tip, changed the parameter and now also this is working fine Ivan From: Durand fabrice via PacketFence-users [mailto:packetfence-users@lists.sourceforge.net] Sent: martedì 11 giugno 2019 03:24 To: packetfence-users@lists.sourceforge.net Cc: Durand fabrice Subject: Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hello Ivan, Le 19-06-10 à 15 h 01, Ivan Saliu via PacketFence-users a écrit : Hi Nicholas and Felipe (hopefully you stuck with us), So now I’ve understood what I was doing wrong and it was just so stupid that I can’t even… Basically I did two things: - I put the custom port for CoA (1700 on Cisco WLCs…why use standards…) on the field Disconnect Port (Policies and Access Control -> Network Devices -> Switches -> My WLC). I found from the packetfence.log file that it was working only the authentication, but the VLAN switch was of course not working since it does a CoA de-authentication to move the VLAN. - Also the second step was also to put Advanced Access Configuration -> Captive Portal in the IP field the Registration interface IP otherwise it wouldn’t recognize in any case internet access. Right now the captive portal is working fine, I do have some more things that worries me that I noticed from the packetfence.log file like the following error: Unable to extract SSID of Called-Station-ID, which if persist actually makes more difficult for me to distinguish between SSID and present a different captive portal for other users, but these are a lot less painful issues than the one that I’ve just solved. You just need to fix the format of the Called-Station-Id attribute in the WLC config. Regards Fabrice Thanks again Nicholas for your support, as you said it was indeed a configuration issue, Hope you all had a nice day, Ivan From: Ivan Saliu Sent: lunedì 10 giugno 2019 15:47 To: packetfence-users@lists.sourceforge.net<mailto:packetfence-users@lists.sourceforge.net> Cc: 'Nicholas Pier' <09np...@gmail.com><mailto:09np...@gmail.com> Subject: RE: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Nicholas, The issue is the second one you pointed out: * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. They get the proper IP address….so the issue is when PacketFence needs to update the VLAN via Radius? Still don’t get why the behavior is this one, I’ve checked and the Deauthentication Method is set as RADIUS, Use CoA is enabled, and I even put into the CoA port 1700 since Cisco’s WLC uses that. The only thing that is missing is the Controller IP address field but I don’t think this should cause the issue. Ivan From: Nicholas Pier [mailto:09np...@gmail.com] Sent: lunedì 10 giugno 2019 13:58 To: Ivan Saliu mailto:ivan.sa...@kikocosmetics.com>> Cc: packetfence-users@lists.sourceforge.net<mailto:packetfence-users@lists.sourceforge.net> Subject: Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Ivan, Let's start with what's supposed to happen immediately after a login: Packetfence should reauthorize the user and send a message to the controller to change the role / vlan. This re-authroization is configured on both the controller and "switch" object in packetfence. Once this comes, the client needs to obtain a new IP address on the new subnet. A few questions then: * Does the client lose network access immediately after the re-authorization? This might indicate a client/controller-side issue if they're not getting a new dhcp lease quickly enough. * If they disconnect and reconnect to the wireless, are they assigned the co
Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Hi Fabrice, Thanks for the tip, changed the parameter and now also this is working fine Ivan From: Durand fabrice via PacketFence-users [mailto:packetfence-users@lists.sourceforge.net] Sent: martedì 11 giugno 2019 03:24 To: packetfence-users@lists.sourceforge.net Cc: Durand fabrice Subject: Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hello Ivan, Le 19-06-10 à 15 h 01, Ivan Saliu via PacketFence-users a écrit : Hi Nicholas and Felipe (hopefully you stuck with us), So now I’ve understood what I was doing wrong and it was just so stupid that I can’t even… Basically I did two things: - I put the custom port for CoA (1700 on Cisco WLCs…why use standards…) on the field Disconnect Port (Policies and Access Control -> Network Devices -> Switches -> My WLC). I found from the packetfence.log file that it was working only the authentication, but the VLAN switch was of course not working since it does a CoA de-authentication to move the VLAN. - Also the second step was also to put Advanced Access Configuration -> Captive Portal in the IP field the Registration interface IP otherwise it wouldn’t recognize in any case internet access. Right now the captive portal is working fine, I do have some more things that worries me that I noticed from the packetfence.log file like the following error: Unable to extract SSID of Called-Station-ID, which if persist actually makes more difficult for me to distinguish between SSID and present a different captive portal for other users, but these are a lot less painful issues than the one that I’ve just solved. You just need to fix the format of the Called-Station-Id attribute in the WLC config. Regards Fabrice Thanks again Nicholas for your support, as you said it was indeed a configuration issue, Hope you all had a nice day, Ivan From: Ivan Saliu Sent: lunedì 10 giugno 2019 15:47 To: packetfence-users@lists.sourceforge.net<mailto:packetfence-users@lists.sourceforge.net> Cc: 'Nicholas Pier' <09np...@gmail.com><mailto:09np...@gmail.com> Subject: RE: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Nicholas, The issue is the second one you pointed out: * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. They get the proper IP address….so the issue is when PacketFence needs to update the VLAN via Radius? Still don’t get why the behavior is this one, I’ve checked and the Deauthentication Method is set as RADIUS, Use CoA is enabled, and I even put into the CoA port 1700 since Cisco’s WLC uses that. The only thing that is missing is the Controller IP address field but I don’t think this should cause the issue. Ivan From: Nicholas Pier [mailto:09np...@gmail.com] Sent: lunedì 10 giugno 2019 13:58 To: Ivan Saliu mailto:ivan.sa...@kikocosmetics.com>> Cc: packetfence-users@lists.sourceforge.net<mailto:packetfence-users@lists.sourceforge.net> Subject: Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Ivan, Let's start with what's supposed to happen immediately after a login: Packetfence should reauthorize the user and send a message to the controller to change the role / vlan. This re-authroization is configured on both the controller and "switch" object in packetfence. Once this comes, the client needs to obtain a new IP address on the new subnet. A few questions then: * Does the client lose network access immediately after the re-authorization? This might indicate a client/controller-side issue if they're not getting a new dhcp lease quickly enough. * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. My "gut" is that this isn't a problem with the way packetfence is deployed (I prefer multiple interfaces, even in VMware), but rather with the controller or "switch" configuration in packetfence. I'd work to verify that SNMP or Radius messages are being sent from packetfence to re-authroize the user and move them to the right VLAN. I think the preferred re-authorization is Radius or CoA since the network configuration guide doesn't mention SNMO read-write configuration. Can you look at the audit tab and verify that packetfence sends a radius message to the controller after login? Similarly, the "switch" config object should have Radius selected from the drop-down for re-authroization. As for the switch, I think it's easiest to not give the switch an SVI IP (vlan interface) and let packetfence do the work. This way you don't need to worry about the routing imp
Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Hello Ivan, Le 19-06-10 à 15 h 01, Ivan Saliu via PacketFence-users a écrit : Hi Nicholas and Felipe (hopefully you stuck with us), So now I’ve understood what I was doing wrong and it was just so stupid that I can’t even… Basically I did two things: -I put the custom port for CoA (1700 on Cisco WLCs…why use standards…) on the field Disconnect Port (Policies and Access Control -> Network Devices -> Switches -> My WLC). I found from the packetfence.log file that it was working only the authentication, but the VLAN switch was of course not working since it does a CoA de-authentication to move the VLAN. -Also the second step was also to put Advanced Access Configuration -> Captive Portal in the IP field the Registration interface IP otherwise it wouldn’t recognize in any case internet access. Right now the captive portal is working fine, I do have some more things that worries me that I noticed from the packetfence.log file like the following error: Unable to extract SSID of Called-Station-ID, which if persist actually makes more difficult for me to distinguish between SSID and present a different captive portal for other users, but these are a lot less painful issues than the one that I’ve just solved. You just need to fix the format of the Called-Station-Id attribute in the WLC config. Regards Fabrice Thanks again Nicholas for your support, as you said it was indeed a configuration issue, Hope you all had a nice day, Ivan *From:*Ivan Saliu *Sent:* lunedì 10 giugno 2019 15:47 *To:* packetfence-users@lists.sourceforge.net *Cc:* 'Nicholas Pier' <09np...@gmail.com> *Subject:* RE: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Nicholas, The issue is the second one you pointed out: * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. They get the proper IP address….so the issue is when PacketFence needs to update the VLAN via Radius? Still don’t get why the behavior is this one, I’ve checked and the Deauthentication Method is set as RADIUS, Use CoA is enabled, and I even put into the CoA port 1700 since Cisco’s WLC uses that. The only thing that is missing is the Controller IP address field but I don’t think this should cause the issue. Ivan *From:*Nicholas Pier [mailto:09np...@gmail.com] *Sent:* lunedì 10 giugno 2019 13:58 *To:* Ivan Saliu <mailto:ivan.sa...@kikocosmetics.com>> *Cc:* packetfence-users@lists.sourceforge.net <mailto:packetfence-users@lists.sourceforge.net> *Subject:* Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Ivan, Let's start with what's supposed to happen immediately after a login: Packetfence should reauthorize the user and send a message to the controller to change the role / vlan. This re-authroization is configured on both the controller and "switch" object in packetfence. Once this comes, the client needs to obtain a new IP address on the new subnet. A few questions then: * Does the client lose network access immediately after the re-authorization? This might indicate a client/controller-side issue if they're not getting a new dhcp lease quickly enough. * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. My "gut" is that this isn't a problem with the way packetfence is deployed (I prefer multiple interfaces, even in VMware), but rather with the controller or "switch" configuration in packetfence. I'd work to verify that SNMP or Radius messages are being sent from packetfence to re-authroize the user and move them to the right VLAN. I think the preferred re-authorization is Radius or CoA since the network configuration guide doesn't mention SNMO read-write configuration. Can you look at the audit tab and verify that packetfence sends a radius message to the controller after login? Similarly, the "switch" config object should have Radius selected from the drop-down for re-authroization. As for the switch, I think it's easiest to not give the switch an SVI IP (vlan interface) and let packetfence do the work. This way you don't need to worry about the routing implications of packetfence having multiple NICs with their own routes, and the ACLs that are required to isolate a client and only allow communication to packetfence. It's just easier. However, if you need to scale to a multi-site deployment and can't tag the registration VLAN end to end, a routed deployment may become necessary. Best wishes, *Nicholas P. Pier* Network & Virtualization Engineer /CCNP RS, PCSNSE7, VCI
Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Felipe, What are you using to de-authorize the port? Radius? CoA? SNMP? Also, what's the make of the switch? I've had the best luck with physical ports using SNMP because it typically "downs" the port before "upping" it. This causes the client to request a new DHCP lease and avoids some of the issues with CoA. A caveat is devices connected through phone switchports. It can be inconvenient if someone is on the phone with the helpdesk when their phone and PC go up/down. I hope this is helpful, *Nicholas P. Pier* Network & Virtualization Engineer *CCNP RS, PCSNSE7, VCIX6-DCV, VCIX6-NV* On Mon, Jun 10, 2019 at 9:50 AM Felipe Rodrigues via PacketFence-users < packetfence-users@lists.sourceforge.net> wrote: > Hi guys, > > I have the same problem here. I have been using one physical interface in > my scenario with a Registration and Isolation VLAN associated to this > interface. The portal works great and I can see the Disconnect-Request and > Disconnect-ACK via Wireshark. > > The problem is the same: The client is not redirected to the new VLAN. If > I disconnected and connected again, than I received the correct VLAN. > > Any Ideia? > > > -- > *De:* Ivan Saliu via PacketFence-users < > packetfence-users@lists.sourceforge.net> > *Enviado:* segunda-feira, 10 de junho de 2019 05:51 > *Para:* packetfence-users@lists.sourceforge.net > *Cc:* Ivan Saliu > *Assunto:* Re: [PacketFence-users] Issues with PacketFence Captive Portal > configuration > > > Hi Nicholas, > > > > I do agree with you that the flow should be that one. > > So far I’ve noticed that these points works perfectly: > >- User connects to SSID and is sent to registration VLAN if their node >isn't pre-registered. If the node has been registered, the go immediately >to the VLAN associated with their role and this flow stops. >- If they're sent to the registation VLAN: > - Packetfence provides DHCP and DNS for registration VLAN. > - DNS queries from the client are leveraged to redirect them to > packetfence for captive portal. Most modern browsers and OSs should > do this automatically. > > > > After these one though I get to the login page, I log in successfully but > I get the error: Unable to detect network connectivity try restarting your > web browser or opening a new tab to see if your access has been > successfully enabled. > > After this I’m stuck, the client is not redirected to the new VLAN and I > keep the old IP Address. > > > > PacketFence is deployed in the following way: > > > > 2 NICs, one NIC operates as a Management interface with Radius and DHCP > Daemons listening here. The 2nd NIC operates as a Registration Interface, > does DNS and DHCP. > > > > This is deployed in Hyper-V so this is a forced mode, I cannot use a > single interface and build on top VLANs since Hyper-V doesn’t support > multiple tagging on this. > > Also another question: the Registration VLAN, should PacketFence handle > the routing? Because right now there is a Cisco 4500 in VSS that is doing > the routing. > > What I’ve also noticed is that the second NIC it is not reachable from > outside the subnet but honestly I think this should be how it works since > it is supposed to be in an Isolated VLAN. > > > > Cannot wrap my head around what I’m missing/what I do wrong. > > > > Ivan > > > > *From:* Nicholas Pier [mailto:09np...@gmail.com] > *Sent:* domenica 9 giugno 2019 03:06 > *To:* packetfence-users@lists.sourceforge.net > *Cc:* Ivan Saliu > *Subject:* Re: [PacketFence-users] Issues with PacketFence Captive Portal > configuration > > > > Hi Ivan, > > > > I think this is mostly likely a configuration issue. It sounds like you > may be expecting the controller to receive information about the captive > portal. This may be possible, but it's not how I've deployed packetfence in > the past. Instead, Radius and DNS do most of the work I've only worked with > 7.x controller code and don't know what's changed since... however the > typical workflow I've experienced is as follows: > > > >- User connects to SSID and is sent to registration VLAN if their node >isn't pre-registered. If the node has been registered, the go immediately >to the VLAN associated with their role and this flow stops. >- If they're sent to the registation VLAN: > > >- Packetfence provides DHCP and DNS for registration VLAN. > - DNS queries from the client are leveraged to redirect them to > packetfence for captive portal. Most modern browsers and OSs should do > this > automatically. > - If the us
Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Hi Nicholas and Felipe (hopefully you stuck with us), So now I’ve understood what I was doing wrong and it was just so stupid that I can’t even… Basically I did two things: - I put the custom port for CoA (1700 on Cisco WLCs…why use standards…) on the field Disconnect Port (Policies and Access Control -> Network Devices -> Switches -> My WLC). I found from the packetfence.log file that it was working only the authentication, but the VLAN switch was of course not working since it does a CoA de-authentication to move the VLAN. - Also the second step was also to put Advanced Access Configuration -> Captive Portal in the IP field the Registration interface IP otherwise it wouldn’t recognize in any case internet access. Right now the captive portal is working fine, I do have some more things that worries me that I noticed from the packetfence.log file like the following error: Unable to extract SSID of Called-Station-ID, which if persist actually makes more difficult for me to distinguish between SSID and present a different captive portal for other users, but these are a lot less painful issues than the one that I’ve just solved. Thanks again Nicholas for your support, as you said it was indeed a configuration issue, Hope you all had a nice day, Ivan From: Ivan Saliu Sent: lunedì 10 giugno 2019 15:47 To: packetfence-users@lists.sourceforge.net Cc: 'Nicholas Pier' <09np...@gmail.com> Subject: RE: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Nicholas, The issue is the second one you pointed out: * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. They get the proper IP address….so the issue is when PacketFence needs to update the VLAN via Radius? Still don’t get why the behavior is this one, I’ve checked and the Deauthentication Method is set as RADIUS, Use CoA is enabled, and I even put into the CoA port 1700 since Cisco’s WLC uses that. The only thing that is missing is the Controller IP address field but I don’t think this should cause the issue. Ivan From: Nicholas Pier [mailto:09np...@gmail.com] Sent: lunedì 10 giugno 2019 13:58 To: Ivan Saliu mailto:ivan.sa...@kikocosmetics.com>> Cc: packetfence-users@lists.sourceforge.net<mailto:packetfence-users@lists.sourceforge.net> Subject: Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Ivan, Let's start with what's supposed to happen immediately after a login: Packetfence should reauthorize the user and send a message to the controller to change the role / vlan. This re-authroization is configured on both the controller and "switch" object in packetfence. Once this comes, the client needs to obtain a new IP address on the new subnet. A few questions then: * Does the client lose network access immediately after the re-authorization? This might indicate a client/controller-side issue if they're not getting a new dhcp lease quickly enough. * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. My "gut" is that this isn't a problem with the way packetfence is deployed (I prefer multiple interfaces, even in VMware), but rather with the controller or "switch" configuration in packetfence. I'd work to verify that SNMP or Radius messages are being sent from packetfence to re-authroize the user and move them to the right VLAN. I think the preferred re-authorization is Radius or CoA since the network configuration guide doesn't mention SNMO read-write configuration. Can you look at the audit tab and verify that packetfence sends a radius message to the controller after login? Similarly, the "switch" config object should have Radius selected from the drop-down for re-authroization. As for the switch, I think it's easiest to not give the switch an SVI IP (vlan interface) and let packetfence do the work. This way you don't need to worry about the routing implications of packetfence having multiple NICs with their own routes, and the ACLs that are required to isolate a client and only allow communication to packetfence. It's just easier. However, if you need to scale to a multi-site deployment and can't tag the registration VLAN end to end, a routed deployment may become necessary. Best wishes, Nicholas P. Pier Network & Virtualization Engineer CCNP RS, PCSNSE7, VCIX6-DCV, VCIX6-NV On Mon, Jun 10, 2019 at 4:51 AM Ivan Saliu mailto:ivan.sa...@kikocosmetics.com>> wrote: Hi Nicholas, I do agree with you that the flow should be that one. So far I’ve noticed that these points works perfec
Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Hi Nicholas, The issue is the second one you pointed out: * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. They get the proper IP address….so the issue is when PacketFence needs to update the VLAN via Radius? Still don’t get why the behavior is this one, I’ve checked and the Deauthentication Method is set as RADIUS, Use CoA is enabled, and I even put into the CoA port 1700 since Cisco’s WLC uses that. The only thing that is missing is the Controller IP address field but I don’t think this should cause the issue. Ivan From: Nicholas Pier [mailto:09np...@gmail.com] Sent: lunedì 10 giugno 2019 13:58 To: Ivan Saliu Cc: packetfence-users@lists.sourceforge.net Subject: Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Ivan, Let's start with what's supposed to happen immediately after a login: Packetfence should reauthorize the user and send a message to the controller to change the role / vlan. This re-authroization is configured on both the controller and "switch" object in packetfence. Once this comes, the client needs to obtain a new IP address on the new subnet. A few questions then: * Does the client lose network access immediately after the re-authorization? This might indicate a client/controller-side issue if they're not getting a new dhcp lease quickly enough. * If they disconnect and reconnect to the wireless, are they assigned the correct VLAN / IP ? This might mean that packetfence is properly associating the new role with the user, but the controller isn't getting dynamically updated. My "gut" is that this isn't a problem with the way packetfence is deployed (I prefer multiple interfaces, even in VMware), but rather with the controller or "switch" configuration in packetfence. I'd work to verify that SNMP or Radius messages are being sent from packetfence to re-authroize the user and move them to the right VLAN. I think the preferred re-authorization is Radius or CoA since the network configuration guide doesn't mention SNMO read-write configuration. Can you look at the audit tab and verify that packetfence sends a radius message to the controller after login? Similarly, the "switch" config object should have Radius selected from the drop-down for re-authroization. As for the switch, I think it's easiest to not give the switch an SVI IP (vlan interface) and let packetfence do the work. This way you don't need to worry about the routing implications of packetfence having multiple NICs with their own routes, and the ACLs that are required to isolate a client and only allow communication to packetfence. It's just easier. However, if you need to scale to a multi-site deployment and can't tag the registration VLAN end to end, a routed deployment may become necessary. Best wishes, Nicholas P. Pier Network & Virtualization Engineer CCNP RS, PCSNSE7, VCIX6-DCV, VCIX6-NV On Mon, Jun 10, 2019 at 4:51 AM Ivan Saliu mailto:ivan.sa...@kikocosmetics.com>> wrote: Hi Nicholas, I do agree with you that the flow should be that one. So far I’ve noticed that these points works perfectly: * User connects to SSID and is sent to registration VLAN if their node isn't pre-registered. If the node has been registered, the go immediately to the VLAN associated with their role and this flow stops. * If they're sent to the registation VLAN: * Packetfence provides DHCP and DNS for registration VLAN. * DNS queries from the client are leveraged to redirect them to packetfence for captive portal. Most modern browsers and OSs should do this automatically. After these one though I get to the login page, I log in successfully but I get the error: Unable to detect network connectivity try restarting your web browser or opening a new tab to see if your access has been successfully enabled. After this I’m stuck, the client is not redirected to the new VLAN and I keep the old IP Address. PacketFence is deployed in the following way: 2 NICs, one NIC operates as a Management interface with Radius and DHCP Daemons listening here. The 2nd NIC operates as a Registration Interface, does DNS and DHCP. This is deployed in Hyper-V so this is a forced mode, I cannot use a single interface and build on top VLANs since Hyper-V doesn’t support multiple tagging on this. Also another question: the Registration VLAN, should PacketFence handle the routing? Because right now there is a Cisco 4500 in VSS that is doing the routing. What I’ve also noticed is that the second NIC it is not reachable from outside the subnet but honestly I think this should be how it works since it is supposed to be in an Isolated VLAN. Cannot wrap my head around what I’m missing/what I do wrong. Ivan From: N
Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Hi Nicholas, I do agree with you that the flow should be that one. So far I’ve noticed that these points works perfectly: * User connects to SSID and is sent to registration VLAN if their node isn't pre-registered. If the node has been registered, the go immediately to the VLAN associated with their role and this flow stops. * If they're sent to the registation VLAN: * Packetfence provides DHCP and DNS for registration VLAN. * DNS queries from the client are leveraged to redirect them to packetfence for captive portal. Most modern browsers and OSs should do this automatically. After these one though I get to the login page, I log in successfully but I get the error: Unable to detect network connectivity try restarting your web browser or opening a new tab to see if your access has been successfully enabled. After this I’m stuck, the client is not redirected to the new VLAN and I keep the old IP Address. PacketFence is deployed in the following way: 2 NICs, one NIC operates as a Management interface with Radius and DHCP Daemons listening here. The 2nd NIC operates as a Registration Interface, does DNS and DHCP. This is deployed in Hyper-V so this is a forced mode, I cannot use a single interface and build on top VLANs since Hyper-V doesn’t support multiple tagging on this. Also another question: the Registration VLAN, should PacketFence handle the routing? Because right now there is a Cisco 4500 in VSS that is doing the routing. What I’ve also noticed is that the second NIC it is not reachable from outside the subnet but honestly I think this should be how it works since it is supposed to be in an Isolated VLAN. Cannot wrap my head around what I’m missing/what I do wrong. Ivan From: Nicholas Pier [mailto:09np...@gmail.com] Sent: domenica 9 giugno 2019 03:06 To: packetfence-users@lists.sourceforge.net Cc: Ivan Saliu Subject: Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration Hi Ivan, I think this is mostly likely a configuration issue. It sounds like you may be expecting the controller to receive information about the captive portal. This may be possible, but it's not how I've deployed packetfence in the past. Instead, Radius and DNS do most of the work I've only worked with 7.x controller code and don't know what's changed since... however the typical workflow I've experienced is as follows: * User connects to SSID and is sent to registration VLAN if their node isn't pre-registered. If the node has been registered, the go immediately to the VLAN associated with their role and this flow stops. * If they're sent to the registation VLAN: * Packetfence provides DHCP and DNS for registration VLAN. * DNS queries from the client are leveraged to redirect them to packetfence for captive portal. Most modern browsers and OSs should do this automatically. * If the user successfully authenticates, packetfence sends a radius message back to the controller to change their VLAN and place them on a different subnet. * Client obtains a new lease and can access the network. I don't know much about your setup, but if its not routed, and clients are placed on the same vlan as packetfence (not a routed deployment). Are you leveraging packetfence for DHCP and DNS on the registration VLAN? Best wishes, Nicholas P. Pier Network & Virtualization Engineer CCNP RS, PCSNSE7, VCIX6-DCV, VCIX6-NV On Sat, Jun 8, 2019 at 7:45 PM Ivan Saliu via PacketFence-users mailto:packetfence-users@lists.sourceforge.net>> wrote: Hello Guys, I’m experiencing a lot of issues in configuring PacketFence’s Captive Portal (Version 9.0.1) with Cisco’s WLC (5508, software version 8.1). Basically I’ve tried to deploy the solution in two ways: - The “Network Guide” one, where there is only 1 VLAN with ACLs on the WLC to permit only traffic to DHCP/DNS servers and PacketFence Portal. The issue here is the fact that the redirection does not work at all. The Radius parameter with the URL redirection is not filled with data and so the WLC doesn’t redirect at all the traffic. This is an issue because I do not like the user experience, since being force to type an URL to log in and register the device is not good. - The second type of deployment I’ve tried to do is an interface in Registration mode, on a dedicated VLAN managed entirely by PacketFence, trying to use the VLAN change to grant internet access. In this case the Captive Portal works fine, but once I log into it is not recognized internet access and I get an error saying that internet access cannot be validated. If I try to disconnect the client and reconnect it, the VLAN is changed properly and everything works fine, but again this is not a good user experience and I cannot put in a production environment something that doesn’t work properly. This would also be my preferred solution since it grants the best approach to
Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Hi Ivan, I think this is mostly likely a configuration issue. It sounds like you may be expecting the controller to receive information about the captive portal. This may be possible, but it's not how I've deployed packetfence in the past. Instead, Radius and DNS do most of the work I've only worked with 7.x controller code and don't know what's changed since... however the typical workflow I've experienced is as follows: - User connects to SSID and is sent to registration VLAN if their node isn't pre-registered. If the node has been registered, the go immediately to the VLAN associated with their role and this flow stops. - If they're sent to the registation VLAN: - Packetfence provides DHCP and DNS for registration VLAN. - DNS queries from the client are leveraged to redirect them to packetfence for captive portal. Most modern browsers and OSs should do this automatically. - If the user successfully authenticates, packetfence sends a radius message back to the controller to change their VLAN and place them on a different subnet. - Client obtains a new lease and can access the network. I don't know much about your setup, but if its not routed, and clients are placed on the same vlan as packetfence (not a routed deployment). Are you leveraging packetfence for DHCP and DNS on the registration VLAN? Best wishes, *Nicholas P. Pier* Network & Virtualization Engineer *CCNP RS, PCSNSE7, VCIX6-DCV, VCIX6-NV* On Sat, Jun 8, 2019 at 7:45 PM Ivan Saliu via PacketFence-users < packetfence-users@lists.sourceforge.net> wrote: > Hello Guys, > > > > I’m experiencing a lot of issues in configuring PacketFence’s Captive > Portal (Version 9.0.1) with Cisco’s WLC (5508, software version 8.1). > > Basically I’ve tried to deploy the solution in two ways: > > > > - The “Network Guide” one, where there is only 1 VLAN with ACLs > on the WLC to permit only traffic to DHCP/DNS servers and PacketFence > Portal. The issue here is the fact that the redirection does not work at > all. The Radius parameter with the URL redirection is not filled with data > and so the WLC doesn’t redirect at all the traffic. This is an issue > because I do not like the user experience, since being force to type an URL > to log in and register the device is not good. > > - The second type of deployment I’ve tried to do is an interface > in Registration mode, on a dedicated VLAN managed entirely by PacketFence, > trying to use the VLAN change to grant internet access. In this case the > Captive Portal works fine, but once I log into it is not recognized > internet access and I get an error saying that internet access cannot be > validated. If I try to disconnect the client and reconnect it, the VLAN is > changed properly and everything works fine, but again this is not a good > user experience and I cannot put in a production environment something that > doesn’t work properly. This would also be my preferred solution since it > grants the best approach to security of course since I would be able to > isolate the Registration VLAN and then with Access-List prohibit access to > corporate network once the client in registered. > > > > Do you have any idea on how to solve these issues? I do think it is most > likely a misconfiguration on PacketFence or maybe I’m trying to implement > something that it is not supported by Cisco with its WLC?! > > > > Any help on this would be greatly appreciated, > > Ivan > ___ > PacketFence-users mailing list > PacketFence-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/packetfence-users > ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
Re: [PacketFence-users] Issues with PacketFence Captive Portal configuration
Hello Guys, I'm experiencing a lot of issues in configuring PacketFence's Captive Portal (Version 9.0.1) with Cisco's WLC (5508, software version 8.1). Basically I've tried to deploy the solution in two ways: - The "Network Guide" one, where there is only 1 VLAN with ACLs on the WLC to permit only traffic to DHCP/DNS servers and PacketFence Portal. The issue here is the fact that the redirection does not work at all. The Radius parameter with the URL redirection is not filled with data and so the WLC doesn't redirect at all the traffic. This is an issue because I do not like the user experience, since being force to type an URL to log in and register the device is not good. - The second type of deployment I've tried to do is an interface in Registration mode, on a dedicated VLAN managed entirely by PacketFence, trying to use the VLAN change to grant internet access. In this case the Captive Portal works fine, but once I log into it is not recognized internet access and I get an error saying that internet access cannot be validated. If I try to disconnect the client and reconnect it, the VLAN is changed properly and everything works fine, but again this is not a good user experience and I cannot put in a production environment something that doesn't work properly. This would also be my preferred solution since it grants the best approach to security of course since I would be able to isolate the Registration VLAN and then with Access-List prohibit access to corporate network once the client in registered. Do you have any idea on how to solve these issues? I do think it is most likely a misconfiguration on PacketFence or maybe I'm trying to implement something that it is not supported by Cisco with its WLC?! Any help on this would be greatly appreciated, Ivan ___ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
