Here is what even more awesome - I just fired up my first PF test install.
Same CentOS, same PF Version, same WLC Webauth, and it works for IOS.

But, what is interesting, is that on my first, test PF install, after
logging in at the captive portal, I got a server not found error, so you
had me do:

your issue is the end redirection.

a quick fix is to edit
html/captive-portal/lib/captiveportal/PacketFence/Controller/CaptivePortal.pm
And replace:

    if ( $c->request->secure ) {
        $c->response->redirect( "http://";
              . $Config{'general'}{'hostname'} . "."
              . $Config{'general'}{'domain'}
              . '/access?destination_url='
              . uri_escape($destination_url) );
    }

by:

    if ( $c->request->secure ) {
        $c->response->redirect( "http://10.3.0.3";
              . '/access?destination_url='
              . uri_escape($destination_url) );
    }



So, once that test install was all working,  i went ahead and installed on
the production hardware.  Same versions of everything, but, i did not have
to apply that fix above.  So other than the modifications you had me do to
get multiple webauth portals on my production install, they should be by
and large the same.  I would also add, that I did make a snapshot of my
production PF box before I made any of the multi web auth portal changes.
If i go back to that snapshot, IOS still doesnt work.  So, I have a working
instance on a low powered box, I just dont know what the difference is at
this point.

On Wed, May 27, 2015 at 9:48 AM, Fabrice DURAND <[email protected]> wrote:

>  In fact the WLC will probably have to intercept http://
> www.apple.com/library/test/success.html and reply a 302 to
> http://10.5.0.3/cep221d28 to see a popup on the apple device.
> If you can have a capture of the http traffic between the device and the
> wlc.
>
> Regards
> Fabrice
>
>
>
>
> Le 2015-05-27 10:22, J Nelson a écrit :
>
> no, what exactly would i ask them?  I dont understand the process enough
> to fully understand what I'd open a case on...
>
> On Wed, May 27, 2015 at 9:11 AM, Fabrice DURAND <[email protected]>
> wrote:
>
>>  Because the WLC do the redirection it suppose to answer the correct
>> stuff for iso portal detection.
>> Did you ask cisco about that ?
>>
>> Regards
>> Fabrice
>>
>> Le 2015-05-27 10:05, J Nelson a écrit :
>>
>> no, in httpd.portal.access, this is the output i see (below), I dont see
>> anything at all related to the IOS clients. 10.5.0.13 is a win7 client i've
>> been testing with.  But i see nothing at all for the IOS clients.  I
>> searched for '/library/test/success.html' in httpd.portal.access and
>> nothing is found.
>>
>>
>> 10.5.0.13 - - [26/May/2015:16:01:10 -0500] "GET /cepe7b74e HTTP/1.1" 302
>> 906 "-""
>>  "Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"
>> 10.5.0.13 - - [26/May/2015:16:01:19 -0500] "GET /cepe7b74e HTTP/1.1" 302
>> 906 "-""
>>  "Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"
>> 10.5.0.13 - - [26/May/2015:16:02:03 -0500] "GET /cepe7b74e HTTP/1.1" 302
>> 906 "-""
>>  "Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"
>> 10.5.0.13 - - [26/May/2015:16:03:42 -0500] "GET /cep221d28 HTTP/1.1" 302
>> 880 "-""
>>  "Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"
>> 10.5.0.13 - - [26/May/2015:16:03:43 -0500] "GET
>> /captive-portal?destination_url==
>> http://10.5.0.3/cep221d28&; HTTP/1.1" 200 3099 "-" "Mozilla/5.0 (Windows
>> NT 6.1;
>> rv:38.0) Gecko/20100101 Firefox/38.0"
>> 10.5.0.13 - - [26/May/2015:16:03:49 -0500] "POST /signup HTTP/1.1" 200
>> 11496 "htt
>> tp://10.5.0.3/captive-portal?destination_url=http://10.5.0.3/cep221d28&";
>> "Mozilll
>> a/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"
>> 10.5.0.13 - - [26/May/2015:16:10:47 -0500] "GET /cepe98b0a HTTP/1.1" 302
>> 880 "-""
>>  "Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"
>> 10.5.0.13 - - [26/May/2015:16:10:48 -0500] "GET
>> /captive-portal?destination_url==
>> http://10.5.0.3/cepe98b0a&; HTTP/1.1" 200 3099 "-" "Mozilla/5.0 (Windows
>> NT 6.1;
>> rv:38.0) Gecko/20100101 Firefox/38.0"
>> 10.5.0.13 - - [26/May/2015:16:10:56 -0500] "POST /signup HTTP/1.1" 200
>> 11496 "htt
>> tp://10.5.0.3/captive-portal?destination_url=http://10.5.0.3/cepe98b0a&";
>> "Mozilll
>> a/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"
>> 10.4.0.3 - - [27/May/2015:07:37:52 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>> 10.4.0.3 - - [27/May/2015:07:37:53 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>> 10.4.0.3 - - [27/May/2015:07:37:54 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>> 10.4.0.3 - - [27/May/2015:07:37:55 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>> 10.4.0.3 - - [27/May/2015:07:37:56 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>> 10.4.0.3 - - [27/May/2015:07:37:57 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>> 10.4.0.3 - - [27/May/2015:07:37:58 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>> 10.4.0.3 - - [27/May/2015:07:37:59 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>> 10.4.0.3 - - [27/May/2015:07:38:00 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>> 10.4.0.3 - - [27/May/2015:07:38:01 -0500] "OPTIONS * HTTP/1.0" 200 - "-"
>> "Apachee
>>  (internal dummy connection)"
>>
>> On Wed, May 27, 2015 at 8:44 AM, Fabrice DURAND <[email protected]>
>> wrote:
>>
>>>  Do you have some /library/test/success.html hit on the portal with a
>>> return code 200 ? (httpd.portal.access)
>>>
>>>
>>> Le 2015-05-27 08:49, J Nelson a écrit :
>>>
>>>  Fabrice,
>>>
>>>  well, I spoke too soon.
>>>
>>>  Just as I was feeling pretty good about things - i discovered that
>>> apple IOS will not load the captive web portal page.  It looks like the
>>> redirect is happening, just no love on the IOS side. I know OSX, Windows 7,
>>> and Droid are working, but not Apple IOS.
>>>
>>>  I have seen issues with packetfence server name being:
>>> servername.local. My packetfence server is: packetfence.mydomain.edu
>>> and is also resolvable by any internal client via DNS
>>>
>>>  I have also seen that using a secure redirect will also hinder IOS
>>> clients, I am not using a secure redirect either.  So, I've searched
>>> through the list serve, but the above solutions do not seem to help me
>>> out.  Any ideas?
>>>
>>> On Wed, May 27, 2015 at 5:48 AM, Durand fabrice <[email protected]>
>>> wrote:
>>>
>>>>  Hello Justin,
>>>>
>>>> Glad it works :-)
>>>>
>>>> It will be probably an interesting feature to add in PacketFence.
>>>>
>>>> Regards
>>>> Fabrice
>>>>
>>>>
>>>> Le 2015-05-26 13:58, J Nelson a écrit :
>>>>
>>>>  Fabrice,
>>>>
>>>>
>>>>  1st of all: thanks for all the help.
>>>>
>>>>  2nd: my issue wound up being my WLC access list - i forgot to permit
>>>> the guest network PF portal ip address ( 10.5.0.3) in my PreAuthACL.  So,
>>>> once I put that in, the loop on the guest side stopped, and its working
>>>> like I had wanted.  Testing so far looks good.
>>>>
>>>>  thanks again!
>>>>
>>>> On Mon, May 25, 2015 at 7:46 AM, Fabrice DURAND <[email protected]>
>>>> wrote:
>>>>
>>>>>  Hello Justin,
>>>>>
>>>>> to have radius in debug mode let's kill radius before (pkill radiusd)
>>>>> and retry.
>>>>>
>>>>> Other stuff, can you check in httpd.portal.access to see if it's the
>>>>> portal that loop or the wlc.
>>>>> If it's the wlc then you probably have to check the debug/acl.
>>>>>
>>>>> Regards
>>>>> Fabrice
>>>>>
>>>>>
>>>>>
>>>>> Le 2015-05-22 11:29, J Nelson a écrit :
>>>>>
>>>>>  Ok, so the headers looks something like this, it repeats forever
>>>>> when redirected:
>>>>>
>>>>> GET /cep0a5a10 HTTP/1.1
>>>>> Host: 10.5.0.3
>>>>> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 
>>>>> Firefox/38.0
>>>>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>>>> Accept-Language: en-US,en;q=0.5
>>>>> Accept-Encoding: gzip, deflate
>>>>> Connection: keep-alive
>>>>> Cache-Control: max-age=0
>>>>>
>>>>> HTTP/1.1 200 OK
>>>>> Location: http://10.5.0.3/cep0a5a10
>>>>> Content-Type: text/html
>>>>> Content-Length: 278
>>>>> ----------------------------------------------------------http://10.5.0.3/cep0a5a10
>>>>>
>>>>> GET /cep0a5a10 HTTP/1.1
>>>>> Host: 10.5.0.3
>>>>> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 
>>>>> Firefox/38.0
>>>>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>>>> Accept-Language: en-US,en;q=0.5
>>>>> Accept-Encoding: gzip, deflate
>>>>> Connection: keep-alive
>>>>> Cache-Control: max-age=0
>>>>>
>>>>> HTTP/1.1 200 OK
>>>>> Location: http://10.5.0.3/cep0a5a10
>>>>> Content-Type: text/html
>>>>> Content-Length: 278
>>>>> ----------------------------------------------------------http://10.5.0.3/cep0a5a10
>>>>>
>>>>> GET /cep0a5a10 HTTP/1.1
>>>>> Host: 10.5.0.3
>>>>> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 
>>>>> Firefox/38.0
>>>>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>>>> Accept-Language: en-US,en;q=0.5
>>>>> Accept-Encoding: gzip, deflate
>>>>> Connection: keep-alive
>>>>> Cache-Control: max-age=0
>>>>>
>>>>> As for the radius debug, there is quite a bit of output, what am i
>>>>> looking for?  I guess I can copy what I found interesting in it that would
>>>>> pertain to the WLC:
>>>>>
>>>>> rlm_sql (sql): Read entry
>>>>> nasname=172.16.4.4,shortname=172.16.4.4,secret=private
>>>>> rlm_sql (sql): Adding client 172.16.4.4 (172.16.4.4, server=<none>) to
>>>>> clients list
>>>>>
>>>>> adiusd: #### Opening IP addresses and Ports ####
>>>>> listen {
>>>>>      type = "auth"
>>>>>      virtual_server = "packetfence"
>>>>>      ipaddr = 10.10.1.13
>>>>>      port = 0
>>>>> Failed binding to authentication address 10.10.1.13 port 1812 as
>>>>> server packetfence: Address already in use
>>>>> /usr/local/pf/raddb//radiusd.conf[37]: Error binding to port for
>>>>> 10.10.1.13 port 1812
>>>>>
>>>>>  radiusd.conf line starting at line 37:
>>>>>
>>>>> listen {
>>>>>         type = auth
>>>>>         ipaddr = 10.10.1.13
>>>>>         port = 0
>>>>>         virtual_server = packetfence
>>>>> }
>>>>>
>>>>> listen {
>>>>>         ipaddr = 10.10.1.13
>>>>>         port = 0
>>>>>         type = acct
>>>>>         virtual_server = packetfence
>>>>> }
>>>>>
>>>>>
>>>>> On Thu, May 21, 2015 at 3:02 PM, Fabrice DURAND <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>  Ok so the problem is elsewhere.
>>>>>>
>>>>>> Can you check with radius in debug mode is the vsa are correct ?
>>>>>> radiusd -d /usr/local/pf/raddb/ -X
>>>>>>
>>>>>> And on the client side with Live HTTP Headers (firefox extension)
>>>>>> what contain the redirection ?
>>>>>>
>>>>>> Regards
>>>>>> Fabrice
>>>>>>
>>>>>>
>>>>>> Le 2015-05-21 15:46, J Nelson a écrit :
>>>>>>
>>>>>>   I'm running version 4.5.1
>>>>>>
>>>>>>  my subroutine looks like:
>>>>>> sub returnRadiusAccessAccept {
>>>>>>     my ($this, $vlan, $mac, $port, $connection_type, $user_name,
>>>>>> $ssid, $wasInline, $user_role) = @_;
>>>>>>     my $logger = Log::Log4perl::get_logger( ref($this) );
>>>>>>
>>>>>>     my $radius_reply_ref = {};
>>>>>>
>>>>>>     my $role = $this->getRoleByName($user_role);
>>>>>>     # Roles are configured and the user should have one
>>>>>>     if (defined($role) && isenabled($this->{_RoleMap})) {
>>>>>>         my $node_info = node_view($mac);
>>>>>>         if ($node_info->{'status'} eq $pf::node::STATUS_REGISTERED) {
>>>>>>             $radius_reply_ref = {
>>>>>>                 'User-Name' => $mac,
>>>>>>                 $this->returnRoleAttribute => $role,
>>>>>>             };
>>>>>>         }
>>>>>>         else {
>>>>>>             my (%session_id);
>>>>>>             pf::web::util::session(\%session_id,undef,6);
>>>>>>             $session_id{client_mac} = $mac;
>>>>>>             $session_id{wlan} = $ssid;
>>>>>>             $session_id{switch_id} = $this->{_id};
>>>>>>      my $portal_url;
>>>>>>             if ( $ssid eq "Webreg-Production") {
>>>>>>                 $portal_url='http://10.4.0.3';
>>>>>>             }elsif ( $ssid eq "Augie-Guest") {
>>>>>>                 $portal_url='http://10.5.0.3';
>>>>>>             } else {
>>>>>>                $portal_url=$this->{'_portalURL'};
>>>>>>             }
>>>>>>
>>>>>>             $radius_reply_ref = {
>>>>>>                 'User-Name' => $mac,
>>>>>>                 'Cisco-AVPair' =>
>>>>>> ["url-redirect-acl=$role","url-redirect=".$portal_url."/cep$session_id{_session_id}"],
>>>>>>             };
>>>>>>         }
>>>>>>         $logger->info("[$mac] (".$this->{'_id'}.") Returning ACCEPT
>>>>>> with role: $role");
>>>>>>     }
>>>>>>
>>>>>>  its different than what you posted.  If I put in the entire code
>>>>>> that you posted, neither of the SSID's will work anymore.  If I include
>>>>>> this code:
>>>>>> my $portal_url;
>>>>>>             if ( $ssid eq "Webreg-Production") {
>>>>>>                 $portal_url='http://10.4.0.3';
>>>>>>             }elsif ( $ssid eq "Augie-Guest") {
>>>>>>                 $portal_url='http://10.5.0.3';
>>>>>>             } else {
>>>>>>                $portal_url=$this->{'_portalURL'};
>>>>>>             }
>>>>>>
>>>>>>             $radius_reply_ref = {
>>>>>>                 'User-Name' => $mac,
>>>>>>                 'Cisco-AVPair' =>
>>>>>> ["url-redirect-acl=$role","url-redirect=".$portal_url."/cep$session_id{_session_id}"],
>>>>>>             };
>>>>>>         }
>>>>>>         $logger->info("[$mac] (".$this->{'_id'}.") Returning ACCEPT
>>>>>> with role: $role");
>>>>>>     }
>>>>>>
>>>>>>  then Webreg-Production works, and Augie-Guest appears to
>>>>>> continuously loop.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, May 21, 2015 at 12:05 PM, Fabrice DURAND <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>>  The function is like that ? :
>>>>>>>
>>>>>>> sub returnRadiusAccessAccept {
>>>>>>>     my ($this, $vlan, $mac, $port, $connection_type, $user_name,
>>>>>>> $ssid, $wasInline, $user_role) = @_;
>>>>>>>     my $logger = Log::Log4perl::get_logger( ref($this) );
>>>>>>>
>>>>>>>     my $radius_reply_ref = {};
>>>>>>>
>>>>>>>     my $role = $this->getRoleByName($user_role);
>>>>>>>     # Roles are configured and the user should have one
>>>>>>>     if (defined($role) && isenabled($this->{_RoleMap})) {
>>>>>>>         my $node_info = node_view($mac);
>>>>>>>          my $violation = pf::violation::violation_view_top($mac);
>>>>>>>         if ($node_info->{'status'} eq $pf::node::STATUS_REGISTERED
>>>>>>> && !defined($violation)) {
>>>>>>>             $radius_reply_ref = {
>>>>>>>                 'User-Name' => $mac,
>>>>>>>                 $this->returnRoleAttribute => $role,
>>>>>>>             };
>>>>>>>         }
>>>>>>>         else {
>>>>>>>             my (%session_id);
>>>>>>>             pf::web::util::session(\%session_id,undef,6);
>>>>>>>             $session_id{client_mac} = $mac;
>>>>>>>             $session_id{wlan} = $ssid;
>>>>>>>             $session_id{switch_id} = $this->{_id};
>>>>>>>              pf::locationlog::locationlog_set_session($mac,
>>>>>>> $session_id{_session_id});
>>>>>>>             my $portal_url;
>>>>>>>             if ( $ssid eq "Webreg-Production") {
>>>>>>>                 $portal_url='http://10.4.0.3';
>>>>>>>             }elsif ( $ssid eq "Augie-Guest") {
>>>>>>>                 $portal_url='http://10.5.0.3';
>>>>>>>             } else {
>>>>>>>                $portal_url=$this->{'_portalURL'};
>>>>>>>             }
>>>>>>>
>>>>>>>             $radius_reply_ref = {
>>>>>>>                 'User-Name' => $mac,
>>>>>>>                 'Cisco-AVPair' =>
>>>>>>> ["url-redirect-acl=$role","url-redirect=".$portal_url."/cep$session_id{_session_id}"],
>>>>>>>             };
>>>>>>>         }
>>>>>>>          $logger->info("[$mac] (".$this->{'_id'}.") Returning ACCEPT
>>>>>>> with role: $role");
>>>>>>>     }
>>>>>>>
>>>>>>>  Also check the httpd.admin... log files, you should be able to see
>>>>>>> what is the error.
>>>>>>>
>>>>>>> Regards
>>>>>>> Fabrice
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 2015-05-21 12:28, J Nelson a écrit :
>>>>>>>
>>>>>>>    Closer, but not quite.  So, my code now looks like:
>>>>>>>
>>>>>>>   my $portal_url;
>>>>>>>         if ( $ssid eq "Webreg-Production") {
>>>>>>>          $portal_url='http://10.4.0.3';
>>>>>>>         }elsif ( $ssid eq "Augie-Guest") {
>>>>>>>          $portal_url='http://10.5.0.3';
>>>>>>>         } else {
>>>>>>>         $portal_url=$this->{'_portalURL'};
>>>>>>> };
>>>>>>>
>>>>>>> $radius_reply_ref = {
>>>>>>> 'User-Name' => $mac,
>>>>>>> 'Cisco-AVPair' =>
>>>>>>> ["url-redirect-acl=$role","url-redirect=".$portal_url."/cep$session_id{_session_id}"],
>>>>>>> };
>>>>>>>         }
>>>>>>>
>>>>>>>  So this is what I am experiencing now:
>>>>>>>  Webreg-Production SSID works
>>>>>>>  Augie-Guest SSID continues to loop
>>>>>>>  in the packetfence GUI, under Network, when I click Switches i get:
>>>>>>> *Error!* An error occured while contacting the server. Please try
>>>>>>> again later.
>>>>>>>  I'm not seeing an error when packetfence starts.
>>>>>>>
>>>>>>> On Thu, May 21, 2015 at 10:40 AM, Fabrice DURAND <[email protected]
>>>>>>> > wrote:
>>>>>>>
>>>>>>>>  Hi Nelson,
>>>>>>>>
>>>>>>>> my bad:
>>>>>>>>
>>>>>>>> $portal_url="10.4.0.3"; => $portal_url='http://10.4.0.3';
>>>>>>>> $portal_url="10.5.0.3"; => $portal_url='http://10.5.0.3';
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Fabrice
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 2015-05-21 10:47, J Nelson a écrit :
>>>>>>>>
>>>>>>>>  Fabrice,
>>>>>>>>
>>>>>>>>  I tried to add what you provided to the code of WLC_http.pm, but
>>>>>>>> once I do it, I get put into an endless redirect loop on both 
>>>>>>>> networks.  I
>>>>>>>> do see that each network is trying to redirect to the proper portal IP.
>>>>>>>> I'm putting what I have in WLC_http.pm - i'm including some lines 
>>>>>>>> before
>>>>>>>> and after the code tweak you provided - just so you can see if 
>>>>>>>> anything is
>>>>>>>> missing before/after like a { or ; somewhere.
>>>>>>>>
>>>>>>>>   my $role = $this->getRoleByName($user_role);
>>>>>>>>     # Roles are configured and the user should have one
>>>>>>>>     if (defined($role) && isenabled($this->{_RoleMap})) {
>>>>>>>>         my $node_info = node_view($mac);
>>>>>>>>         if ($node_info->{'status'} eq $pf::node::STATUS_REGISTERED)
>>>>>>>> {
>>>>>>>>             $radius_reply_ref = {
>>>>>>>>                 'User-Name' => $mac,
>>>>>>>>                 $this->returnRoleAttribute => $role,
>>>>>>>>             };
>>>>>>>>         }
>>>>>>>>         else {
>>>>>>>>             my (%session_id);
>>>>>>>>             pf::web::util::session(\%session_id,undef,6);
>>>>>>>>             $session_id{client_mac} = $mac;
>>>>>>>>             $session_id{wlan} = $ssid;
>>>>>>>>             $session_id{switch_id} = $this->{_id};
>>>>>>>>     my $portal_url;
>>>>>>>>         if ( $ssid eq "Webreg-Production") {
>>>>>>>>         $portal_url="10.4.0.3";
>>>>>>>>         }elsif ( $ssid eq "Augie-Guest") {
>>>>>>>>         $portal_url="10.5.0.3";
>>>>>>>>         } else {
>>>>>>>>         $portal_url=$this->{'_portalURL'};
>>>>>>>>         }
>>>>>>>>
>>>>>>>>         $radius_reply_ref = {
>>>>>>>>         'User-Name' => $mac,
>>>>>>>>         'Cisco-AVPair' =>
>>>>>>>> ["url-redirect-acl=$role","url-redirect=".$portal_url."/cep$session_id{_session_id}"],
>>>>>>>>         };
>>>>>>>>
>>>>>>>>         }
>>>>>>>>         $logger->info("[$mac] (".$this->{'_id'}.") Returning ACCEPT
>>>>>>>> with role: $role");
>>>>>>>>     }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, May 20, 2015 at 9:33 AM, Fabrice DURAND <[email protected]
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>>  Hi John,
>>>>>>>>>
>>>>>>>>> so you will have to go in the code because there is only one
>>>>>>>>> portal url per switch config.
>>>>>>>>>
>>>>>>>>> So let's do a hack:
>>>>>>>>>
>>>>>>>>> https://github.com/inverse-inc/packetfence/blob/devel/lib/pf/Switch/Cisco/WLC_http.pm#L161
>>>>>>>>>
>>>>>>>>> my $portal_url;
>>>>>>>>> if ( $ssid eq "Staff") {
>>>>>>>>> $portal_url="10.4.0.3";
>>>>>>>>> }elsif ( $ssid eq "Guest") {
>>>>>>>>> $portal_url="10.5.0.3";
>>>>>>>>> } else {
>>>>>>>>> $portal_url=$this->{'_portalURL'};
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> $radius_reply_ref = {
>>>>>>>>> 'User-Name' => $mac,
>>>>>>>>> 'Cisco-AVPair' =>
>>>>>>>>> ["url-redirect-acl=$role","url-redirect=".$portal_url."/cep$session_id{_session_id}"],
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Fabrice
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 2015-05-20 09:40, J Nelson a écrit :
>>>>>>>>>
>>>>>>>>>     Fabrice, I am purely Web Auth via Cisco WLC.
>>>>>>>>>
>>>>>>>>>  So, in that configuration, I dont believe there is any way to
>>>>>>>>> change VLANs - as Web Auth is purely controlling access via ACL's on 
>>>>>>>>> the
>>>>>>>>> WLC.
>>>>>>>>>  - now if i'm wrong on this, I need to be pointed in the right
>>>>>>>>> direction.
>>>>>>>>>
>>>>>>>>>  So, I am trying to figure out how to basically have two
>>>>>>>>> registration interfaces in a pure WLC Web Auth setup:
>>>>>>>>>  Vlan4 - Staff/Fac
>>>>>>>>>  Vlan5 - Guest
>>>>>>>>>
>>>>>>>>>  but, it looks like I can only have portal, since i setup Vlan 4
>>>>>>>>> first - the portal exists on that address space/subnet.  So, the 
>>>>>>>>> issue I'm
>>>>>>>>> having, when i join the Guest network, a client in that network is 
>>>>>>>>> unable
>>>>>>>>> to get to the portal page.  It looks like a redirect is happening, 
>>>>>>>>> but i
>>>>>>>>> just cant get to it (the PF portal).  The ACL on the WLC is 
>>>>>>>>> indicating that
>>>>>>>>> the traffic is being passed, but I dont believe IPtables on the PF 
>>>>>>>>> box is
>>>>>>>>> allowing it. A client in the Guest network definitely cannot get to
>>>>>>>>> http/https on the PF portal ip address (confirming via an NMAP scan).
>>>>>>>>>
>>>>>>>>>  So i guess the question is, providing you understand what I'm
>>>>>>>>> trying to accomplish,can i have multiple Registration interfaces  
>>>>>>>>> that use
>>>>>>>>> the same PF portal? And what are the configuration requirements?  
>>>>>>>>> Throwing
>>>>>>>>> up two PF boxes - one for Staff/Fac/Student one for Guest would 
>>>>>>>>> certainly
>>>>>>>>> work, just curious if I can do it all in one box.
>>>>>>>>>
>>>>>>>>>  thanks..
>>>>>>>>>
>>>>>>>>> On Wed, May 20, 2015 at 8:23 AM, Fabrice DURAND <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>>  Hello Nelson,
>>>>>>>>>>
>>>>>>>>>> i am not sure to understand what you really want to do.
>>>>>>>>>>
>>>>>>>>>> Let's say you have a registration network: VLAN 4
>>>>>>>>>> A production network for the staff and a production network for
>>>>>>>>>> the guest (5).
>>>>>>>>>>
>>>>>>>>>> When a device is unreg then packetfence will return the vlan 5
>>>>>>>>>> and the device will hit the portal.
>>>>>>>>>> Then depending if it's a Staff or a guest then after registration
>>>>>>>>>> the device will be placed on his production network (depending of 
>>>>>>>>>> his role).
>>>>>>>>>>
>>>>>>>>>> Is it something like that you want to achieve ?
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Fabrice
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 2015-05-19 14:18, J Nelson a écrit :
>>>>>>>>>>
>>>>>>>>>>   any role configured on a different subnet other than the
>>>>>>>>>> native subnet where the captive portal is located will not work.
>>>>>>>>>>
>>>>>>>>>> So, what i do have working is my Fac-Staff SSID which is on VLAN
>>>>>>>>>> 4/10.4.0.0/24
>>>>>>>>>> captive portal is located at: 10.4.0.3
>>>>>>>>>> WLC is configured at Network | Switches | and is configured to do
>>>>>>>>>> Role by Switch Role, where WLC ACL’s are entered to define 
>>>>>>>>>> Registration and
>>>>>>>>>> then Fac-Staff access upon registration.
>>>>>>>>>>
>>>>>>>>>> The Portal URL is in the Fac-Staff registration network - IP
>>>>>>>>>> address, in this case: 10.4.0.3
>>>>>>>>>>
>>>>>>>>>> So, the problem I’m running into, is that i want Guests on a
>>>>>>>>>> different subnet and SSID other than where Fac-Staff reside.  So I 
>>>>>>>>>> create a
>>>>>>>>>> new interface, on a different subnet, as: Type - Registration, and
>>>>>>>>>> configure a new SSID on the WLC side.
>>>>>>>>>>
>>>>>>>>>> So, for now, I configure the WLC under switches with the same
>>>>>>>>>> ACL’s as Fac-Staff for the Guest role - just for simplicity i’m 
>>>>>>>>>> using the
>>>>>>>>>> same ACL’s for now, since I know they work.
>>>>>>>>>>
>>>>>>>>>> The Guest network info is: vlan 5 | 10.5.0.0
>>>>>>>>>>
>>>>>>>>>> So, when logging on as guest, it appears as though a redirect
>>>>>>>>>> attempts to happen, but doing a port scan shows that a computer 
>>>>>>>>>> attached to
>>>>>>>>>> the guest SSID does not have http/https available to them on 
>>>>>>>>>> 10.4.0.3 - the
>>>>>>>>>> captive portal.
>>>>>>>>>>
>>>>>>>>>> looking at the PF iptables config, it appears as though there is
>>>>>>>>>> a variable that says any
>>>>>>>>>>
>>>>>>>>>> ...
>
> [Message clipped]
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> PacketFence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
>


-- 
Justin Nelson
Network Engineer
Augustana College
------------------------------------------------------------------------------
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Reply via email to