I am not using the WLC captive portal, but the web auth method detailed on
pages 79-83 of the Network Devices Configuration Guide specifically states
the production DNS server should be specified. The web auth method does
not use DNS poisoning to force clients to the PF captive portal. Instead,
the PF radius server sends a redirect url to the WLC as well as an ACL to
restrict access to only the captive portal. After registering, the client
remains in the same vlan so it does not obtain a new lease, which is why
the production DNS server needs to be specified in the original DHCP
lease. 

If I can get an interface into the DMZ, could I use PF as the DHCP server
in a registration vlan and have it specify my production DNS servers in
the lease? Also, is creating a routed registration vlan still a
possibility if I am not able to put an interface into the DMZ - again,
specifying the production DNS servers in the DHCP lease?
  
Thanks,
_______________________________________
Chris Mielke  |  Lead, ISS Network Systems
Drake Technology Services (DTS) | Drake University
 
T  515.271.4640
E  [email protected]




On 11/5/14, 10:05 AM, "Sallee, Jake" <[email protected]> wrote:

>If you were able to put an interface from you PF box into the DMZ then
>you could use that interface as the DHCP server and at least
>theoretically it would just work.  However, doing this establishes a
>route around your firewall (albeit a hard to exploit one) which may be
>unacceptable in your environment.
>
>You could set the DHCP server to be an internal interface on you PF box
>in which case you will need to make sure that the DMZ WLC can send the
>packets to the PF box, but then it should be fine.
>
>This may solve your DHCP problem, your DNS issue is different.
>
>Are you still planning to use the WLC for captive portal? Otherwise SOP
>is to set the DNS server in your DHCP scope to the PF server for the
>registration vlan and it just works.
>
>
>
>Jake Sallee
>Godfather of Bandwidth
>System Engineer
>University of Mary Hardin-Baylor
>WWW.UMHB.EDU
>
>900 College St.
>Belton, Texas
>76513
>
>Fone: 254-295-4658
>Phax: 254-295-4221
>
>________________________________________
>From: Christopher Mielke [[email protected]]
>Sent: Wednesday, November 05, 2014 9:02 AM
>To: [email protected]
>Subject: Re: [PacketFence-users] Portal access from a guest anchor
>controller in DMZ
>
>On the SSID configuration, there is an option for DHCP override where I
>can specify the IP address of a DHCP server. The DHCP request will then be
>unicast to the specified IP address. I assume this could be set to the
>PacketFence server and I would set up a routed registration vlan with
>PacketFence acting as the DHCP server. If I do this, how can I configure
>PacketFence to use the production DNS servers since web auth uses RADIUS
>NAC and ACLs to send clients to the captive portal instead of DNS
>poisoning.
>
>Also, let me know if the is the correct direction I should be headed or if
>I should be doing something other than a routed vlan.
>
>Thanks,
>_______________________________________
>Chris Mielke  |  Lead, ISS Network Systems
>Drake Technology Services (DTS) | Drake University
>
>T  515.271.4640
>E  [email protected]
>
>
>
>
>On 11/3/14, 2:48 PM, "Sallee, Jake" <[email protected]> wrote:
>
>>> If they can't bring the DHCP traffic to PF, how about bringing PF to
>>> the DHCP traffic?  If their site security policy will not let them add
>>> another interface to their PF server that connects to the DMZ, could
>>> they add another (independent) PF server on the DMZ just to handle
>>> guests???
>>
>>Unless I am quite mistaken, adding a PF server in the DMZ would not give
>>PF access to the all-important DHCP packets.  By the design he mentions
>>the connections are tunnelled to the DMZ by the internal WLC so even if
>>you had a PF server listening to the DMZ interface on the FW (which
>>should in theory see EVERYTHING)  the packets would be obfuscated and not
>>usable by PF.
>>
>>The simplest solution seems to be moving the DHCP service to another
>>device (PF can do it if you like).
>>
>>
>>Jake Sallee
>>Godfather of Bandwidth
>>System Engineer
>>University of Mary Hardin-Baylor
>>WWW.UMHB.EDU
>>
>>900 College St.
>>Belton, Texas
>>76513
>>
>>Fone: 254-295-4658
>>Phax: 254-295-4221
>>
>>________________________________________
>>From: Arthur Emerson [[email protected]]
>>Sent: Monday, November 03, 2014 2:24 PM
>>To: [email protected]
>>Subject: Re: [PacketFence-users] Portal access from a guest anchor
>>controller in DMZ
>>
>>On Nov 3, 2014, at 2:44 PM, Sallee, Jake <[email protected]> wrote:
>>>
>>> The key really is the DHCP, since your APs are most likely in central
>>>switching mode the data is tunnelled from the AP to the WLC so you
>>>cannot even sniff the traffic on the inside WLC... I'm not giving up,
>>>but you do have a head scratcher.
>>
>>If they can't bring the DHCP traffic to PF, how about bringing PF to
>>the DHCP traffic?  If their site security policy will not let them add
>>another interface to their PF server that connects to the DMZ, could
>>they add another (independent) PF server on the DMZ just to handle
>>guests???
>>
>>-Arthur
>>
>>-------------------------------------------------------------------------
>>Arthur Emerson III                 Email:      [email protected]
>>Network Administrator              InterNIC:   AE81
>>Mount Saint Mary College           MaBell:     (845) 561-0800 Ext. 3109
>>330 Powell Ave.                    Fax:        (845) 562-6762
>>Newburgh, NY  12550                SneakerNet: Aquinas Hall Room 11
>>
>>
>>-------------------------------------------------------------------------
>>-
>>----
>>_______________________________________________
>>PacketFence-users mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>
>>-------------------------------------------------------------------------
>>-
>>----
>>_______________________________________________
>>PacketFence-users mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
>
>--------------------------------------------------------------------------
>----
>_______________________________________________
>PacketFence-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
>--------------------------------------------------------------------------
>----
>_______________________________________________
>PacketFence-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/packetfence-users


------------------------------------------------------------------------------
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Reply via email to