Guest Anchors and external DHCP servers

Hi,
We are using guest anchors (GA) for supporting wireless guest user.
Until now we used internal DHCP server on the GA but now we want to move to external.
For example:
The guest will reside on 192.168.0.x, this is separated by a firewall from the inside network and is not routable on the inside.(this is the guest interface of the GA)
The DHCP server will be somewhere on the internal network only reachable by GA's management interface.
Is it possible for DHCP requests to be forwarded to the DHCP server originating from the management interface?
If this is not how it should happen, than what other options are there for placing the external DHCP servers?
Let me know if you need more information regarding our solution..
Thank you,
Laszlo

Hello Laszlo,
Yes, what you want to do can be done but there are few things that you have to consider.
First is that you are not going to use the WLC as the DHCP server so you should go to the interface configuration and point the DHCP server to the external one.
Now, what you want to do here is to make the wireless LAN controller a DHCP relay agent (or proxy), this way the wireless LAN controller is the one handling all the DHCP requests and it is going to be the one asking for an IP address in behalf of the client using the management interface. This behavior is enabled by default and I believe you have it already configured because it is necessary for the internal DHCP server of the WLC to work; it is configured on the "Controller" tab > Advanced > DHCP. On new versions of software this option is configurable by interface.
There is a catch though, if the DHCP server is an ASA or if the request has to go through an ASA or firewall, this might not work because by design some ASAs will drop every DHCP request comming from a relay agent so just consider this when you do these type of deployments.
If you have any questions let me know.
Best regards,
Marco Gonzalez
Cisco TAC TL

Similar Messages

  • WLC Internal and External DHCP

    I am currently using the Internal DHCP component within my 5508 Controller with software version 7.0.166.0.  This seems to be working fine as the Vlan Routed interface connected to it via the Dynamic Trunk Port is functioning as l have the ip-helper command setup on this specific vlan interface..
    My issue now is that we have a isolated ADSL Network which is configured off our Core 6513 but just as a Layer 2 Vlan so no traffic can be routed to other vlans.
    With our new WIFI environment which consists of the 5508 Controller and numerous 3502 AP's we wont to utilize this ADSL vlan with our new WIFI environment..  This ADSL Vlan has a dedicated Linksys Router which is currently running DHCP and assigning addresses to clients at the moment..
    What l want to do is configure the 5508 controller to use this ADSL vlan aswell but to also keep using the Linksys Router aswell for DHCP..
    I have setup a new dynamic interface and added the ADSL Vlan ID to the Trunk port of the 5508 and also setup its own SSID.  But for some reason l cannot get both the internal and External DHCP servers to work at the same time ?  If l enable DHCP Proxy option on the 5508 the internal DHCP server works and when l disable DHCP Proxy the ADSL Vlan DHCP works through the 5508 but not the internal DHCP Server ??
    Can l get both the internal and external DHCP servers to work in harmony or should l be focusing on using one method over the other ?

    Hey Scott l have just tried configuring another scope for the L2 Vlan but it doesn't seem to be working when l add the ip address of the management interface which is the internal DHCP Server to the dynamic interface of this adsl network l have setup l dont seem to get a ip address within this scope ?
    I am just wandering seeing it is just a L2 vlan without a routed interface would this be the problem and would need to set this up with the "ip helper-address" of the management interface ?
    Cheers SG

  • Web Auth using 5760 Guest Anchor and ISE

    I am trying to deploy a new guest wireless solution using a 3650s as the MA, a 5760 as the MC, and a 5760 as the guest anchor.  ISE is being used as the guest auth server.
    When no auth requirements are set on the guest wlan, everything works fine.  I get an IP address and can get to the internet, VPN, etc.  As soon as I enter the security web-auth command on the wlan, my client drops and goes into an Acquiring IP Address state.  When I check the client on the controller, it is in a Policy Manager State of START.
    As soon as I remove the security web-auth commamd from the wlan, I connect right up.  It is my understanding that in guest, the client gets an IP address first in order to get redirected to the spoofed external web page, in my case ISE.
    Any thoughts on what I am missing on my guest anchor, or MA config?  Do I need to make any changes to the wlan on the MC?  Any documentation about the relationship between the MA, MC, and guest anchor would be appreciated, I am not 100% sure which devices are required to have the client reach the guest anchor and get connected.

    I hope this may help you
    http://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/117742-configure-wlc-00.html
    HTH
    Rasika
    *** Pls rate all useful responses ****

  • Resolve.conf, dnsmasq and external DNS servers

    I am using dnsmasq to filter out ad urls, so my  /etc/resolv.conf looks like that:
    # Generated by dhcpcd from wlan0
    nameserver 127.0.0.1
    domain home
    nameserver 192.168.1.254
    # /etc/resolv.conf.tail can replace this line
    However, it looks like after getting through the url filtration layer of dnsmasq, the URLs are being resolved by a DNS sever of whatever Access Point I am connected to. This create problems, because they often render me unable to connect to services like sourceforge.net, etc.
    So, instead of that, I would like my system to fall back to Google and OpenDNS after filtering urls through dnsmasq.
    But how can I do that? This is a specific case and wiki does not cover it.
    Last edited by Lockheed (2013-05-19 16:50:43)

    $ cat /etc/resolv.conf
    # Generated by dhcpcd from wlan0
    nameserver 127.0.0.1
    nameserver 8.8.8.8
    domain home
    # /etc/resolv.conf.tail can replace this line
    The google DNS is what I put in there earlier to be able to use internet after dnsmasq stopped starting.
    $ cat /etc/resolvconf.conf
    # Configuration for resolvconf(8)
    # See resolvconf.conf(5) for details
    resolv_conf=/etc/resolv.conf
    # If you run a local name server, you should uncomment the below line and
    # configure your subscribers configuration files below.
    name_servers=127.0.0.1
    # Write out dnsmasq extended configuration and resolv files
    dnsmasq_conf=/etc/dnsmasq-conf.conf
    dnsmasq_resolv=/etc/dnsmasq-resolv.conf
    $ cat /etc/dnsmasq.conf
    # Configuration file for dnsmasq.
    # Format is one option per line, legal options are the same
    # as the long options legal on the command line. See
    # "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.
    # Listen on this specific port instead of the standard DNS port
    # (53). Setting this to zero completely disables DNS function,
    # leaving only DHCP and/or TFTP.
    #port=5353
    # The following two options make you a better netizen, since they
    # tell dnsmasq to filter out queries which the public DNS cannot
    # answer, and which load the servers (especially the root servers)
    # unnecessarily. If you have a dial-on-demand link they also stop
    # these requests from bringing up the link unnecessarily.
    # Never forward plain names (without a dot or domain part)
    #domain-needed
    # Never forward addresses in the non-routed address spaces.
    #bogus-priv
    # Uncomment this to filter useless windows-originated DNS requests
    # which can trigger dial-on-demand links needlessly.
    # Note that (amongst other things) this blocks all SRV requests,
    # so don't use it if you use eg Kerberos, SIP, XMMP or Google-talk.
    # This option only affects forwarding, SRV records originating for
    # dnsmasq (via srv-host= lines) are not suppressed by it.
    #filterwin2k
    # Change this line if you want dns to get its upstream servers from
    # somewhere other that /etc/resolv.conf
    #resolv-file=/etc/resolv-dnsmasq.conf
    # By default, dnsmasq will send queries to any of the upstream
    # servers it knows about and tries to favour servers to are known
    # to be up. Uncommenting this forces dnsmasq to try each query
    # with each server strictly in the order they appear in
    # /etc/resolv.conf
    strict-order
    # If you don't want dnsmasq to read /etc/resolv.conf or any other
    # file, getting its servers from this file instead (see below), then
    # uncomment this.
    #no-resolv
    # If you don't want dnsmasq to poll /etc/resolv.conf or other resolv
    # files for changes and re-read them then uncomment this.
    #no-poll
    # Add other name servers here, with domain specs if they are for
    # non-public domains.
    #server=/localnet/192.168.0.1
    server=208.67.222.222
    server=208.67.220.220
    # Example of routing PTR queries to nameservers: this will send all
    # address->name queries for 192.168.3/24 to nameserver 10.1.2.3
    #server=/3.168.192.in-addr.arpa/10.1.2.3
    # Add local-only domains here, queries in these domains are answered
    # from /etc/hosts or DHCP only.
    #local=/localnet/
    # Add domains which you want to force to an IP address here.
    # The example below send any host in double-click.net to a local
    # web-server.
    #address=/double-click.net/127.0.0.1
    # --address (and --server) work with IPv6 addresses too.
    #address=/www.thekelleys.org.uk/fe80::20d:60ff:fe36:f83
    # You can control how dnsmasq talks to a server: this forces
    # queries to 10.1.2.3 to be routed via eth1
    # server=10.1.2.3@eth1
    # and this sets the source (ie local) address used to talk to
    # 10.1.2.3 to 192.168.1.1 port 55 (there must be a interface with that
    # IP on the machine, obviously).
    # [email protected]#55
    # If you want dnsmasq to change uid and gid to something other
    # than the default, edit the following lines.
    #user=
    #group=
    # If you want dnsmasq to listen for DHCP and DNS requests only on
    # specified interfaces (and the loopback) give the name of the
    # interface (eg eth0) here.
    # Repeat the line for more than one interface.
    #interface=lo
    # Or you can specify which interface _not_ to listen on
    #except-interface=
    # Or which to listen on by address (remember to include 127.0.0.1 if
    # you use this.)
    #listen-address=127.0.0.1
    # If you want dnsmasq to provide only DNS service on an interface,
    # configure it as shown above, and then use the following line to
    # disable DHCP and TFTP on it.
    #no-dhcp-interface=
    # On systems which support it, dnsmasq binds the wildcard address,
    # even when it is listening on only some interfaces. It then discards
    # requests that it shouldn't reply to. This has the advantage of
    # working even when interfaces come and go and change address. If you
    # want dnsmasq to really bind only the interfaces it is listening on,
    # uncomment this option. About the only time you may need this is when
    # running another nameserver on the same machine.
    #bind-interfaces
    # If you don't want dnsmasq to read /etc/hosts, uncomment the
    # following line.
    #no-hosts
    # or if you want it to read another file, as well as /etc/hosts, use
    # this.
    addn-hosts=/etc/hosts.block
    #hostsfile=/etc/hosts.block
    # Set this (and domain: see below) if you want to have a domain
    # automatically added to simple names in a hosts-file.
    #expand-hosts
    # Set the domain for dnsmasq. this is optional, but if it is set, it
    # does the following things.
    # 1) Allows DHCP hosts to have fully qualified domain names, as long
    # as the domain part matches this setting.
    # 2) Sets the "domain" DHCP option thereby potentially setting the
    # domain of all systems configured by DHCP
    # 3) Provides the domain part for "expand-hosts"
    #domain=thekelleys.org.uk
    # Set a different domain for a particular subnet
    #domain=wireless.thekelleys.org.uk,192.168.2.0/24
    # Same idea, but range rather then subnet
    #domain=reserved.thekelleys.org.uk,192.68.3.100,192.168.3.200
    # Uncomment this to enable the integrated DHCP server, you need
    # to supply the range of addresses available for lease and optionally
    # a lease time. If you have more than one network, you will need to
    # repeat this for each network on which you want to supply DHCP
    # service.
    #dhcp-range=192.168.0.50,192.168.0.150,12h
    # This is an example of a DHCP range where the netmask is given. This
    # is needed for networks we reach the dnsmasq DHCP server via a relay
    # agent. If you don't know what a DHCP relay agent is, you probably
    # don't need to worry about this.
    #dhcp-range=192.168.0.50,192.168.0.150,255.255.255.0,12h
    # This is an example of a DHCP range which sets a tag, so that
    # some DHCP options may be set only for this network.
    #dhcp-range=set:red,192.168.0.50,192.168.0.150
    # Use this DHCP range only when the tag "green" is set.
    #dhcp-range=tag:green,192.168.0.50,192.168.0.150,12h
    # Specify a subnet which can't be used for dynamic address allocation,
    # is available for hosts with matching --dhcp-host lines. Note that
    # dhcp-host declarations will be ignored unless there is a dhcp-range
    # of some type for the subnet in question.
    # In this case the netmask is implied (it comes from the network
    # configuration on the machine running dnsmasq) it is possible to give
    # an explicit netmask instead.
    #dhcp-range=192.168.0.0,static
    # Enable DHCPv6. Note that the prefix-length does not need to be specified
    # and defaults to 64 if missing/
    #dhcp-range=1234::2, 1234::500, 64, 12h
    # Do Router Advertisements, BUT NOT DHCP for this subnet.
    #dhcp-range=1234::, ra-only
    # Do Router Advertisements, BUT NOT DHCP for this subnet, also try and
    # add names to the DNS for the IPv6 address of SLAAC-configured dual-stack
    # hosts. Use the DHCPv4 lease to derive the name, network segment and
    # MAC address and assume that the host will also have an
    # IPv6 address calculated using the SLAAC alogrithm.
    #dhcp-range=1234::, ra-names
    # Do Router Advertisements, BUT NOT DHCP for this subnet.
    # Set the lifetime to 46 hours. (Note: minimum lifetime is 2 hours.)
    #dhcp-range=1234::, ra-only, 48h
    # Do DHCP and Router Advertisements for this subnet. Set the A bit in the RA
    # so that clients can use SLAAC addresses as well as DHCP ones.
    #dhcp-range=1234::2, 1234::500, slaac
    # Do Router Advertisements and stateless DHCP for this subnet. Clients will
    # not get addresses from DHCP, but they will get other configuration information.
    # They will use SLAAC for addresses.
    #dhcp-range=1234::, ra-stateless
    # Do stateless DHCP, SLAAC, and generate DNS names for SLAAC addresses
    # from DHCPv4 leases.
    #dhcp-range=1234::, ra-stateless, ra-names
    # Do router advertisements for all subnets where we're doing DHCPv6
    # Unless overriden by ra-stateless, ra-names, et al, the router
    # advertisements will have the M and O bits set, so that the clients
    # get addresses and configuration from DHCPv6, and the A bit reset, so the
    # clients don't use SLAAC addresses.
    #enable-ra
    # Supply parameters for specified hosts using DHCP. There are lots
    # of valid alternatives, so we will give examples of each. Note that
    # IP addresses DO NOT have to be in the range given above, they just
    # need to be on the same network. The order of the parameters in these
    # do not matter, it's permissible to give name, address and MAC in any
    # order.
    # Always allocate the host with Ethernet address 11:22:33:44:55:66
    # The IP address 192.168.0.60
    #dhcp-host=11:22:33:44:55:66,192.168.0.60
    # Always set the name of the host with hardware address
    # 11:22:33:44:55:66 to be "fred"
    #dhcp-host=11:22:33:44:55:66,fred
    # Always give the host with Ethernet address 11:22:33:44:55:66
    # the name fred and IP address 192.168.0.60 and lease time 45 minutes
    #dhcp-host=11:22:33:44:55:66,fred,192.168.0.60,45m
    # Give a host with Ethernet address 11:22:33:44:55:66 or
    # 12:34:56:78:90:12 the IP address 192.168.0.60. Dnsmasq will assume
    # that these two Ethernet interfaces will never be in use at the same
    # time, and give the IP address to the second, even if it is already
    # in use by the first. Useful for laptops with wired and wireless
    # addresses.
    #dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.60
    # Give the machine which says its name is "bert" IP address
    # 192.168.0.70 and an infinite lease
    #dhcp-host=bert,192.168.0.70,infinite
    # Always give the host with client identifier 01:02:02:04
    # the IP address 192.168.0.60
    #dhcp-host=id:01:02:02:04,192.168.0.60
    # Always give the host with client identifier "marjorie"
    # the IP address 192.168.0.60
    #dhcp-host=id:marjorie,192.168.0.60
    # Enable the address given for "judge" in /etc/hosts
    # to be given to a machine presenting the name "judge" when
    # it asks for a DHCP lease.
    #dhcp-host=judge
    # Never offer DHCP service to a machine whose Ethernet
    # address is 11:22:33:44:55:66
    #dhcp-host=11:22:33:44:55:66,ignore
    # Ignore any client-id presented by the machine with Ethernet
    # address 11:22:33:44:55:66. This is useful to prevent a machine
    # being treated differently when running under different OS's or
    # between PXE boot and OS boot.
    #dhcp-host=11:22:33:44:55:66,id:*
    # Send extra options which are tagged as "red" to
    # the machine with Ethernet address 11:22:33:44:55:66
    #dhcp-host=11:22:33:44:55:66,set:red
    # Send extra options which are tagged as "red" to
    # any machine with Ethernet address starting 11:22:33:
    #dhcp-host=11:22:33:*:*:*,set:red
    # Give a fixed IPv6 address and name to client with
    # DUID 00:01:00:01:16:d2:83:fc:92:d4:19:e2:d8:b2
    # Note the MAC addresses CANNOT be used to identify DHCPv6 clients.
    # Note also the they [] around the IPv6 address are obilgatory.
    #dhcp-host=id:00:01:00:01:16:d2:83:fc:92:d4:19:e2:d8:b2, fred, [1234::5]
    # Ignore any clients which are not specified in dhcp-host lines
    # or /etc/ethers. Equivalent to ISC "deny unknown-clients".
    # This relies on the special "known" tag which is set when
    # a host is matched.
    #dhcp-ignore=tag:!known
    # Send extra options which are tagged as "red" to any machine whose
    # DHCP vendorclass string includes the substring "Linux"
    #dhcp-vendorclass=set:red,Linux
    # Send extra options which are tagged as "red" to any machine one
    # of whose DHCP userclass strings includes the substring "accounts"
    #dhcp-userclass=set:red,accounts
    # Send extra options which are tagged as "red" to any machine whose
    # MAC address matches the pattern.
    #dhcp-mac=set:red,00:60:8C:*:*:*
    # If this line is uncommented, dnsmasq will read /etc/ethers and act
    # on the ethernet-address/IP pairs found there just as if they had
    # been given as --dhcp-host options. Useful if you keep
    # MAC-address/host mappings there for other purposes.
    #read-ethers
    # Send options to hosts which ask for a DHCP lease.
    # See RFC 2132 for details of available options.
    # Common options can be given to dnsmasq by name:
    # run "dnsmasq --help dhcp" to get a list.
    # Note that all the common settings, such as netmask and
    # broadcast address, DNS server and default route, are given
    # sane defaults by dnsmasq. You very likely will not need
    # any dhcp-options. If you use Windows clients and Samba, there
    # are some options which are recommended, they are detailed at the
    # end of this section.
    # Override the default route supplied by dnsmasq, which assumes the
    # router is the same machine as the one running dnsmasq.
    #dhcp-option=3,1.2.3.4
    # Do the same thing, but using the option name
    #dhcp-option=option:router,1.2.3.4
    # Override the default route supplied by dnsmasq and send no default
    # route at all. Note that this only works for the options sent by
    # default (1, 3, 6, 12, 28) the same line will send a zero-length option
    # for all other option numbers.
    #dhcp-option=3
    # Set the NTP time server addresses to 192.168.0.4 and 10.10.0.5
    #dhcp-option=option:ntp-server,192.168.0.4,10.10.0.5
    # Send DHCPv6 option. Note [] around IPv6 addresses.
    #dhcp-option=option6:dns-server,[1234::77],[1234::88]
    # Send DHCPv6 option for namservers as the machine running
    # dnsmasq and another.
    #dhcp-option=option6:dns-server,[::],[1234::88]
    # Ask client to poll for option changes every six hours. (RFC4242)
    #dhcp-option=option6:information-refresh-time,6h
    # Set the NTP time server address to be the same machine as
    # is running dnsmasq
    #dhcp-option=42,0.0.0.0
    # Set the NIS domain name to "welly"
    #dhcp-option=40,welly
    # Set the default time-to-live to 50
    #dhcp-option=23,50
    # Set the "all subnets are local" flag
    #dhcp-option=27,1
    # Send the etherboot magic flag and then etherboot options (a string).
    #dhcp-option=128,e4:45:74:68:00:00
    #dhcp-option=129,NIC=eepro100
    # Specify an option which will only be sent to the "red" network
    # (see dhcp-range for the declaration of the "red" network)
    # Note that the tag: part must precede the option: part.
    #dhcp-option = tag:red, option:ntp-server, 192.168.1.1
    # The following DHCP options set up dnsmasq in the same way as is specified
    # for the ISC dhcpcd in
    # http://www.samba.org/samba/ftp/docs/textdocs/DHCP-Server-Configuration.txt
    # adapted for a typical dnsmasq installation where the host running
    # dnsmasq is also the host running samba.
    # you may want to uncomment some or all of them if you use
    # Windows clients and Samba.
    #dhcp-option=19,0 # option ip-forwarding off
    #dhcp-option=44,0.0.0.0 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)
    #dhcp-option=45,0.0.0.0 # netbios datagram distribution server
    #dhcp-option=46,8 # netbios node type
    # Send an empty WPAD option. This may be REQUIRED to get windows 7 to behave.
    #dhcp-option=252,"\n"
    # Send RFC-3397 DNS domain search DHCP option. WARNING: Your DHCP client
    # probably doesn't support this......
    #dhcp-option=option:domain-search,eng.apple.com,marketing.apple.com
    # Send RFC-3442 classless static routes (note the netmask encoding)
    #dhcp-option=121,192.168.1.0/24,1.2.3.4,10.0.0.0/8,5.6.7.8
    # Send vendor-class specific options encapsulated in DHCP option 43.
    # The meaning of the options is defined by the vendor-class so
    # options are sent only when the client supplied vendor class
    # matches the class given here. (A substring match is OK, so "MSFT"
    # matches "MSFT" and "MSFT 5.0"). This example sets the
    # mtftp address to 0.0.0.0 for PXEClients.
    #dhcp-option=vendor:PXEClient,1,0.0.0.0
    # Send microsoft-specific option to tell windows to release the DHCP lease
    # when it shuts down. Note the "i" flag, to tell dnsmasq to send the
    # value as a four-byte integer - that's what microsoft wants. See
    # http://technet2.microsoft.com/WindowsServer/en/library/a70f1bb7-d2d4-49f0-96d6-4b7414ecfaae1033.mspx?mfr=true
    #dhcp-option=vendor:MSFT,2,1i
    # Send the Encapsulated-vendor-class ID needed by some configurations of
    # Etherboot to allow is to recognise the DHCP server.
    #dhcp-option=vendor:Etherboot,60,"Etherboot"
    # Send options to PXELinux. Note that we need to send the options even
    # though they don't appear in the parameter request list, so we need
    # to use dhcp-option-force here.
    # See http://syslinux.zytor.com/pxe.php#special for details.
    # Magic number - needed before anything else is recognised
    #dhcp-option-force=208,f1:00:74:7e
    # Configuration file name
    #dhcp-option-force=209,configs/common
    # Path prefix
    #dhcp-option-force=210,/tftpboot/pxelinux/files/
    # Reboot time. (Note 'i' to send 32-bit value)
    #dhcp-option-force=211,30i
    # Set the boot filename for netboot/PXE. You will only need
    # this is you want to boot machines over the network and you will need
    # a TFTP server; either dnsmasq's built in TFTP server or an
    # external one. (See below for how to enable the TFTP server.)
    #dhcp-boot=pxelinux.0
    # The same as above, but use custom tftp-server instead machine running dnsmasq
    #dhcp-boot=pxelinux,server.name,192.168.1.100
    # Boot for Etherboot gPXE. The idea is to send two different
    # filenames, the first loads gPXE, and the second tells gPXE what to
    # load. The dhcp-match sets the gpxe tag for requests from gPXE.
    #dhcp-match=set:gpxe,175 # gPXE sends a 175 option.
    #dhcp-boot=tag:!gpxe,undionly.kpxe
    #dhcp-boot=mybootimage
    # Encapsulated options for Etherboot gPXE. All the options are
    # encapsulated within option 175
    #dhcp-option=encap:175, 1, 5b # priority code
    #dhcp-option=encap:175, 176, 1b # no-proxydhcp
    #dhcp-option=encap:175, 177, string # bus-id
    #dhcp-option=encap:175, 189, 1b # BIOS drive code
    #dhcp-option=encap:175, 190, user # iSCSI username
    #dhcp-option=encap:175, 191, pass # iSCSI password
    # Test for the architecture of a netboot client. PXE clients are
    # supposed to send their architecture as option 93. (See RFC 4578)
    #dhcp-match=peecees, option:client-arch, 0 #x86-32
    #dhcp-match=itanics, option:client-arch, 2 #IA64
    #dhcp-match=hammers, option:client-arch, 6 #x86-64
    #dhcp-match=mactels, option:client-arch, 7 #EFI x86-64
    # Do real PXE, rather than just booting a single file, this is an
    # alternative to dhcp-boot.
    #pxe-prompt="What system shall I netboot?"
    # or with timeout before first available action is taken:
    #pxe-prompt="Press F8 for menu.", 60
    # Available boot services. for PXE.
    #pxe-service=x86PC, "Boot from local disk"
    # Loads <tftp-root>/pxelinux.0 from dnsmasq TFTP server.
    #pxe-service=x86PC, "Install Linux", pxelinux
    # Loads <tftp-root>/pxelinux.0 from TFTP server at 1.2.3.4.
    # Beware this fails on old PXE ROMS.
    #pxe-service=x86PC, "Install Linux", pxelinux, 1.2.3.4
    # Use bootserver on network, found my multicast or broadcast.
    #pxe-service=x86PC, "Install windows from RIS server", 1
    # Use bootserver at a known IP address.
    #pxe-service=x86PC, "Install windows from RIS server", 1, 1.2.3.4
    # If you have multicast-FTP available,
    # information for that can be passed in a similar way using options 1
    # to 5. See page 19 of
    # http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf
    # Enable dnsmasq's built-in TFTP server
    #enable-tftp
    # Set the root directory for files available via FTP.
    #tftp-root=/var/ftpd
    # Make the TFTP server more secure: with this set, only files owned by
    # the user dnsmasq is running as will be send over the net.
    #tftp-secure
    # This option stops dnsmasq from negotiating a larger blocksize for TFTP
    # transfers. It will slow things down, but may rescue some broken TFTP
    # clients.
    #tftp-no-blocksize
    # Set the boot file name only when the "red" tag is set.
    #dhcp-boot=net:red,pxelinux.red-net
    # An example of dhcp-boot with an external TFTP server: the name and IP
    # address of the server are given after the filename.
    # Can fail with old PXE ROMS. Overridden by --pxe-service.
    #dhcp-boot=/var/ftpd/pxelinux.0,boothost,192.168.0.3
    # If there are multiple external tftp servers having a same name
    # (using /etc/hosts) then that name can be specified as the
    # tftp_servername (the third option to dhcp-boot) and in that
    # case dnsmasq resolves this name and returns the resultant IP
    # addresses in round robin fasion. This facility can be used to
    # load balance the tftp load among a set of servers.
    #dhcp-boot=/var/ftpd/pxelinux.0,boothost,tftp_server_name
    # Set the limit on DHCP leases, the default is 150
    #dhcp-lease-max=150
    # The DHCP server needs somewhere on disk to keep its lease database.
    # This defaults to a sane location, but if you want to change it, use
    # the line below.
    #dhcp-leasefile=/var/lib/misc/dnsmasq.leases
    # Set the DHCP server to authoritative mode. In this mode it will barge in
    # and take over the lease for any client which broadcasts on the network,
    # whether it has a record of the lease or not. This avoids long timeouts
    # when a machine wakes up on a new network. DO NOT enable this if there's
    # the slightest chance that you might end up accidentally configuring a DHCP
    # server for your campus/company accidentally. The ISC server uses
    # the same option, and this URL provides more information:
    # http://www.isc.org/files/auth.html
    #dhcp-authoritative
    # Run an executable when a DHCP lease is created or destroyed.
    # The arguments sent to the script are "add" or "del",
    # then the MAC address, the IP address and finally the hostname
    # if there is one.
    #dhcp-script=/bin/echo
    # Set the cachesize here.
    #cache-size=150
    # If you want to disable negative caching, uncomment this.
    #no-negcache
    # Normally responses which come from /etc/hosts and the DHCP lease
    # file have Time-To-Live set as zero, which conventionally means
    # do not cache further. If you are happy to trade lower load on the
    # server for potentially stale date, you can set a time-to-live (in
    # seconds) here.
    #local-ttl=
    # If you want dnsmasq to detect attempts by Verisign to send queries
    # to unregistered .com and .net hosts to its sitefinder service and
    # have dnsmasq instead return the correct NXDOMAIN response, uncomment
    # this line. You can add similar lines to do the same for other
    # registries which have implemented wildcard A records.
    #bogus-nxdomain=64.94.110.11
    # If you want to fix up DNS results from upstream servers, use the
    # alias option. This only works for IPv4.
    # This alias makes a result of 1.2.3.4 appear as 5.6.7.8
    #alias=1.2.3.4,5.6.7.8
    # and this maps 1.2.3.x to 5.6.7.x
    #alias=1.2.3.0,5.6.7.0,255.255.255.0
    # and this maps 192.168.0.10->192.168.0.40 to 10.0.0.10->10.0.0.40
    #alias=192.168.0.10-192.168.0.40,10.0.0.0,255.255.255.0
    # Change these lines if you want dnsmasq to serve MX records.
    # Return an MX record named "maildomain.com" with target
    # servermachine.com and preference 50
    #mx-host=maildomain.com,servermachine.com,50
    # Set the default target for MX records created using the localmx option.
    #mx-target=servermachine.com
    # Return an MX record pointing to the mx-target for all local
    # machines.
    #localmx
    # Return an MX record pointing to itself for all local machines.
    #selfmx
    # Change the following lines if you want dnsmasq to serve SRV
    # records. These are useful if you want to serve ldap requests for
    # Active Directory and other windows-originated DNS requests.
    # See RFC 2782.
    # You may add multiple srv-host lines.
    # The fields are <name>,<target>,<port>,<priority>,<weight>
    # If the domain part if missing from the name (so that is just has the
    # service and protocol sections) then the domain given by the domain=
    # config option is used. (Note that expand-hosts does not need to be
    # set for this to work.)
    # A SRV record sending LDAP for the example.com domain to
    # ldapserver.example.com port 389
    #srv-host=_ldap._tcp.example.com,ldapserver.example.com,389
    # A SRV record sending LDAP for the example.com domain to
    # ldapserver.example.com port 389 (using domain=)
    #domain=example.com
    #srv-host=_ldap._tcp,ldapserver.example.com,389
    # Two SRV records for LDAP, each with different priorities
    #srv-host=_ldap._tcp.example.com,ldapserver.example.com,389,1
    #srv-host=_ldap._tcp.example.com,ldapserver.example.com,389,2
    # A SRV record indicating that there is no LDAP server for the domain
    # example.com
    #srv-host=_ldap._tcp.example.com
    # The following line shows how to make dnsmasq serve an arbitrary PTR
    # record. This is useful for DNS-SD. (Note that the
    # domain-name expansion done for SRV records _does_not
    # occur for PTR records.)
    #ptr-record=_http._tcp.dns-sd-services,"New Employee Page._http._tcp.dns-sd-services"
    # Change the following lines to enable dnsmasq to serve TXT records.
    # These are used for things like SPF and zeroconf. (Note that the
    # domain-name expansion done for SRV records _does_not
    # occur for TXT records.)
    #Example SPF.
    #txt-record=example.com,"v=spf1 a -all"
    #Example zeroconf
    #txt-record=_http._tcp.example.com,name=value,paper=A4
    # Provide an alias for a "local" DNS name. Note that this _only_ works
    # for targets which are names from DHCP or /etc/hosts. Give host
    # "bert" another name, bertrand
    #cname=bertand,bert
    # For debugging purposes, log each DNS query as it passes through
    # dnsmasq.
    #log-queries
    # Log lots of extra information about DHCP transactions.
    #log-dhcp
    # Include a another lot of configuration options.
    #conf-file=/etc/dnsmasq-resolvconf.conf
    #conf-dir=/etc/dnsmasq.d
    domain-needed
    interface=lo
    # If dnsmasq is compiled for DBus then we can take
    # advantage of not having to restart dnsmasq.
    enable-dbus
    conf-file=/etc/dnsmasq-conf.conf
    resolv-file=/etc/dnsmasq-resolv.conf
    Logs:
    May 23 00:01:06 panzor systemd[1]: Failed to start A lightweight DHCP and caching DNS server.
    May 23 00:01:10 panzor dhcpcd[27267]: dhcpcd not running
    May 23 00:01:10 panzor kernel: [ 7771.282756] iwl4965 0000:03:00.0: Can't stop Rx DMA.
    May 23 00:01:10 panzor dhcpcd[27294]: dhcpcd not running
    May 23 00:01:11 panzor dhcpcd[27330]: dhcpcd not running
    May 23 00:01:14 panzor dhcpcd[27373]: wlan0: sendmsg: Cannot assign requested address
    May 23 00:01:18 panzor dhcpcd[27373]: wlan0: sendmsg: Operation not permitted
    May 23 00:01:22 panzor dhcpcd[27395]: wlan0: sendmsg: Operation not permitted
    May 23 00:01:26 panzor dhcpcd[27395]: wlan0: sendmsg: Operation not permitted
    For domain filtration, if I remember correctly, I am using this
    https://bbs.archlinux.org/viewtopic.php?id=139784

  • URL Logging for Guest Traffic using Guest Anchor and ISE

    Hi there all,
    I'm looking for a solution whereby I can log URL information for wireless guest users to ISE. The anchor WLC sits in a DMZ behind an ASA and the ISE is on the internal network. I found this document (see URL below) which is similar but using a NAC Guest Server and not an ISE.
    I'm wondering if anyone has managed to do this using ISE?
    http://www.cisco.com/en/US/products/ps6128/products_configuration_example09186a0080ac2fda.shtml#wlcc

    Hi, Sorry for the late reply, I have been busy with a Proof Of Concept with the ISE.
    I have tried your suggestion and I cannot get the same results as you.
    I notice that the logs in your report were generated by an ASA. Do you know whether the same can be done with a switch dACL?
    i have this configuration...
    dACL
    3k-access#sh ip access-list int fa0/1
         permit udp host 10.1.10.103 any eq domain
         permit icmp host 10.1.10.103 any
         permit tcp host 10.1.10.103 host 10.1.100.21 eq 8443
         permit tcp host 10.1.10.103 host 10.1.252.10 eq www log-input
         deny ip host 10.1.10.103 10.1.0.0 0.0.255.255
         permit ip host 10.1.10.103 any
    Logging config...
    logging esm config
    logging trap debugging
    logging origin-id ip
    logging host 10.1.100.21 transport udp port 20514
    with the above onfiguration, I get a report which shows the syslog messages of successful authentication and download of the dACL, but then when I access a URL, i do not see any events about the URL that was accessed or even the IP that was accessed.
    DO you know if this can be done? maybe I am looking at the wrong report? Can you help?
    Mario

  • NetBoot and Multiple DHCP Servers

    Hey everyone,
    We have a NetBoot machine running here at my school (where I work). It was working like a champ until a couple of weeks ago when our network got upgraded and there are now 2 DHCP servers on our network. That, for some reason, is totally screwing up our NetBooting process.
    Here's what I think is happening, and maybe someone can tell me if I right or wrong. NetBoot (or BSDP protocol) is a "broadcast" protocol. (That means it's always just floating around out there on the network. ) NetBoot (BSDP) protocol gets injected into the DHCP stream, and any machine that gets DHCP can get BSDP, and essentially NetBoot.
    The problem is with BSDP. BSDP protocol wants to have all of it's "broadcasts" come from the same server. So when we had 1 DHCP server, everything was fine, because client machines would get their whole NetBoot process from one machine... all of the BSDP broadcasts were coming from our 1 DHCP server.
    Now, we have 2 DHCP servers. What happens is, a client will get some of it's BSDP broadcasts from one DHCP server, and some from another... which it does not like at all.
    I recently read somewhere that it is possible to somehow make one of our DHCP servers the "authoritative" server, to which all of the clients will go to get their NetBooting info.
    Does this sound in any way right? Are we on the right track ? Has anyone seen this before? Any help would be greatly appreciated. Thanks a million.
    Mike

    Now, we have 2 DHCP servers. What happens is, a
    a client will get some of it's BSDP broadcasts from
    one DHCP server, and some from another... which it
    does not like at all.
    Not unless your new DHCP server is also a NetBoot server and is set to provide NetBoot services. BSDP and DHCP are not the same thing. If what you were saying were true, it wouldn't be possible to have DHCP and NetBoot offered by different servers.
    It IS possible, however, that the two DHCP servers are causing problems by both servicing DHCP requests for the same clients. If you've got multiple DHCP servers on the same subnet (or your router's configured to pass DHCP requests between subnets), you should make sure that only one of the DHCP servers answers requests from any given client. In our world, our Novell server is the default DHCP server on our subnet, but I keep a list of excluded MAC addresses on that server so that my Macintosh clients don't get addresses from it. On the Mac OS X server, I'm careful to limit my address ranges only to those machines which have static address maps in NetInfo. That way, our servers coexist, but they don't overlap.
    It's not clear from your message whether your previously solitary DHCP server was your Mac OS X server, or whether one of the two DHCP servers is that box. But whatever the servers are, it might be helpful to turn off one of them to see if the same problem occurs (assuming you can, without major network disruptions). If that's not possible, can you talk to your network admins to see if there's some way to isolate your clients and one of the servers--in other words, see if there's some way to keep DHCP servers from responding to the same requests.
    There may be any number of other reasons why this problem has cropped up. You may need to dust off a hub and a copy of Ethereal or EtherPeek to sniff what's happening on the network. You might also try NetBooting in verbose mode, to see where the process craps out. IIRC, there'a decent guide for this kind of troubleshooting over at Bombich's site (www.bombich.com).
    Good luck.
    David Walton

  • WLC 5508 and Multiple DHCP servers in different sites?

    Hi
    I work for health authority in our region and we just purchased a Cisco wlc 5508 controller along with 25 3500 AP's. We have multiple sites with different IP subnets in each, all connected by a frame relay (owned by ISP). Each site has its own DHCP server. I have the controller in our main site. So when I take an AP to a remote site, the Ap gets an DHCP address from local DHCP server (which is great) and contacts controller and joins controller. Everything is good. BUT, when a client joins at the remote site, it gets an address from a previous site which will not work because the client is now on a different subnet. We dont use Vlans as they dont transvers the frame relay. I need those clients to obtain DHCP from the local DHCP server from the site they are on. Is that possible??
    I have updated the controller to latest version as well.
    Thanks
    Bryan Yaciuk, CCNA
    Parkland Regional Health Authority

    We call this as HREAP LOCAL SWITCHING!! but here is the catch.. everytime the AP joins the new site.. we need to configure the VLAN mapping and this wil do it for you!! Here is the link which will resolve ur issue..
    http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00807cc3b8.shtml#ll
    Lemme know if this answered ur question and please dont forget to rate the usefull posts!!
    Regards
    Surendra

  • Guest Anchor N+1: Multiple guest WLANs and Mobility List

    Hi Experts,
    We are going to replace two guest anchor controllers WLC4402 sitting in different DMZs with two WLC5508 as N+1 redundant pair in one DMZ.
    I assume each guest anchor controller should support multiple guest WLANs. Is it correct?
    And between these two new anchor WLCs, do they need to add each other to Mobility List?
    Or maybe I should ask first, does it matter if they are in the same mobility group or not?
    Thanks
    Cedar

    N+1 for guest anchors isn't what N+1 was designed for.  N+1 was designed for redundancy for WLC's supporting access points, not mobility anchors.  This solution might work, but I really doubt Cisco will support this setup, but I can be wrong.... you can always talk with your local Cisco SE or open a TAC case and ask.
    Guest anchors should have a different mobility group name from the foreign WLC's.  You do need the foreign to have both guest anchors and the guest anchor to just have the foreign WLC(s).  The redundant guest anchors do not need to have each other in the mobility group list.
    Thanks,
    Scott
    Help out other by using the rating system and marking answered questions as "Answered"

  • Guest anchor WLAN and DHCP

    hi,
    I am trying to setup a guest WLAN using a local controller and  a controller in my DMZ using the mobility-anchor configuration.
    Ideally I'd like to use an external DHCP server in my DMZ, but for now, I'd be happy getting the local DHCP server on the DMZ controller working.
    Local Controller config
    Configured mobility-groups, verified mobility group is working
    Created WLAN called "guest" - assigned it to the management interface.
    Have tried the following with regards to DHCP on this WLAN.
         Set it to "override" and specified the DMZ controller's mangement interface
         Set DHCP to "assignment required" and specified the DMZ controller's management interface for the DHCP server for the local controller's management      interface
         Left DHCP server blank on the local controller's management interface
    Setup the DMZ controller as the mobility anchor for the "guest" WLAN
    DMZ controller config
    Configured mobility-groups, verified mobility group is working
    Created WLAN called "guest"
    Created a dynamic interface called "guest" associated to the "guest" WLAN
    Setup mobility anchor for the "guest" interface,  mobility-anchor = local controller
    Created an internal DHCP server scope and enabled it
    Have tried the following with regards to DHCP on the "guest" WLAN
         Set DHCP to "assignment required" and specified the IP address of the controllers management interface as the DHCP server on the "guest"      dynamic interface
         Set DHCP to "assignment required" and specified the IP address of the  controllers "guest" dynamic interface as the DHCP server on the "guest"       dynamic interface
         Set DHCP to "override" and specified the DMZ controller's management interface IP
         Set DHCP to "override" and specified the DMZ controller's "guest" interface IP
    After all this,  my client still cannot get an IP address via DHCP.  I verfiied the client is associating to the AP.
    Any help would be appreciated.
    Thanks
    Lee

    on the DMZ controller, what is the output of a debug client < mac address of the client>  You may also want to capture debug mobility handoff enable, from both WLC.
    For the guest, the DHCP is going to come from the DMZ controller, so there is no real need to configure anything on the internal WLC.  One thing of note, the WLAN config on both the DMZ and Internal must match exactly with the exception of the linked interface, otherwise you will not anchor.
    while runnign the debug, show dhcp proxy, for the WLC to be the DHCP server, proxy needs to be enabled.

  • Anchor Guest controller and DHCP configuration

    I checked the cisco documentation about the DHCP configuration but I´m not 100%sure which DHCP server address I must use.
    I  used as example the scope 10.240.97.0/24 for our Guest Users. In this range are the DHCP scope and the Guest interface configured. For the management I used as example the range 10.240.96.0/24.Now I configured our Guest WLC and I insert on the Guest interface as Primary DHCP address the Guest interface address. After I applied I got the message I can´t use this DHCP address. Now I checked the cisco and found following description:
    “If DHCP services are to be implemented locally on the anchor controller, populate the primary DHCP server field with the management IP address of the controller"
    Means it now I must insert as the IP for the Primary DHCP Server on the Guest interface  the IP from the management
    Interface and the controller will then forward the traffic to the internal DHCP scope on the Guest subnet and wil sent it back ?
    ( DHCP proxy is on the Guest WLC  enabled ) .
    Thanks
    Al

    For Anchor you can use either internal or external dhcp server.
    Means it now I must insert as the IP for the Primary DHCP Server on the Guest interface  the IP from the management
    Interface and the controller will then forward the traffic to the internal DHCP scope on the Guest subnet and wil sent it back ?
    Yes. WLC forwards the unicast dhcp req to management ip for guest interface. All cpu generated traffic by default uses management interface as source address i.e., snmp, radius, ping...
    Is your question whether you need routing between guest and management interface.
    No, routing is not required in this case bcoz the interface residing on WLC's management. Also for proxy it uses the virtual ip address for dhcp instead of actual dhcp ip. And only wireless client can get ip from WLC's internal dhcp server.
    If you're using dhcp proxy on wlc and having external dhcp server on different vlan then yes you need routing between the two vlans.

  • DHCP loadsharing with redundant Guest Anchor Controllers

    Hi
    I have 2 x Redundant Guest Anchor Controllers (5508) located in 2 separate Data Centres with all the management and guest user VLAN spanned between two. Everything is working fine with the Guest WiFi access except the DHCP functionality as the Controllers are acting themselves as the internal DHCP Servers.
    This is how I tried to distribute
    network. 10.1.0.0/23
    gateway: 10.1.1.254
    Controller 1, DHCP Server pool: 10.1.0.2 - 10.1.0.254 Gw: 10.1.1.254
    Controller 2, DHCP Server pool: 10.1.1.2 - 10.1.1.254 Gw: 10.1.1.254
    As the user loadbalancing between the Anchor Controllers cannot be controlled (i.e. they are active/active), the same client sometime getting 2 different IP addresses from both the Controllers (as they do not talk to each other in terms of DHCP) hence depleting the pool addresses.
    I guess one way of solving this is to just run 1 DHCP server in one of the controllers but that defeats the purpose of having N+1 Controllers. Is there a better way of doing the DHCP loadbalancing and having full redundancy at the same time?
    Any suggestion will be greatly appreciated.
    Regards

    Thanks Scott, I understand that it's quite obvious to get an external DHCP Server, unfortunately it's not an option for us The weired thing is, it seems when a client joins the guest WiFi, both the Anchor Controllers (both functioning as DHCP servers with mutually exclusive IP Address space) are providing IP addresses. While the client accepts only one the other Controller still reserves the IP address unused and hence depleting the DHCP Pool.
    I thought for load balancing (in the very beginning) the Foreign controller will forward the DHCP request to only one of tthe Anchor Controllers, but in reality it's forwarding it to both. I have tested this with only one test AP, so mobility doesn't seem to be an issue here. Any thoughts?

  • Can i use Internal DHCP on WLC Guest Anchor (5508) with Foreign HA 5508

    DHCP Proxy is required in order to use local WLC DHCP Pool (Guest Anchor), however reading Wireless Q&A (http://www.cisco.com/image/gif/paws/107458/wga-faq.pdf) states that both foreign and guest anchors must have :
    In a Wireless guest access setup, the DHCP proxy setting in the Guest Anchor controllers
    and the internal controller must match. Else, DHCP request from clients are dropped and you
    see this error message on the internal controller......
    However if you have N+1 you cannot use internal DHCP, does this also "grey" out the DHCP Proxy global setting? If so will the Guest Anchor still work with a internal DHCP pool even though foreign and guest controllers have a mismatch in DHCP Proxy (global) setting?
    Many Thanks
    Kam

    Well it should still work... dhcp proxy is required on the WLC that has a dhcp scope.  With the newer code versions, you can enable dhcp proxy on a per interface do this doens't have to be global.

  • Internal dhcp with anchor and foreign

    Greetings,
    trying to get dhcp going for guest clients.
    I can see dhcp requests coming through and getting dropped at the foreign controller.
    *DHCP Socket Task: Aug 10 16:19:54.075: 58:94:6b:1d:xx:yy DHCP received op BOOTREQUEST (1) (len 308,vlan 0, port 13, encap 0xec03)
    *DHCP Socket Task: Aug 10 16:19:54.075: 58:94:6b:1d:xx:yy DHCP dropping packet
    Could someone tell me;
    1. why would the DHCP requests processed by the foreign controller instead of the anchor ?
    2. do i need to configure dhcp server under the guest WLAN interface on foreign?
    I thought all L3 and security stuff is forwarded over eoip to anchor and therefore no need to configure the DHCP server under foreign.
    I'm trying to utilise the internal DHCP server (firmware 7.0.220) but so far its not going well.
    Thanks,
    silva

    Hi All,
    Steve you got me thinking and thanks to the debugs you provided, I  managed to fix the issue.The problem was caused by local EoIP tunnel that was configured on the foreign  and thus traffic was not getting forwarded.Strange thing I can't remember configuring that as it was not required.Anyway after I removed it, all worked as expected. I'm using internal DHCP and so far it is is working fine as well.
    With the ACLs, for guest WLAN, do we neded to configure for both foreign and anchors so that the WLAN configs are identical?
    Does not make any sense to me to configure the ACLS on the foreign but can someone confirm?
    Silva

  • 2500 wireless guest anchor, dhcp performance

    Hello,
    I just read that starting from version 7.4, the 2500 controller can be used to terminate guest anchor tunnels.
    This is great news, but i have a question regaring the performance of the internal DHCP server when used in guest environments.
    Can it be used and if so, what is its performance ? (ie requests / second)
    regards,
    Geert

    Take a look at the data sheet and it will give you a general understanding of the max client count which is 500 and the throughput which is 500mbps unless you run 7.4 and have LAG enabled which gives you 1gig.  I would only use this for small installs and if its a pretty medium to large guest network, then stick with the 5508.
    http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps11630/data_sheet_c78-645111.html
    Thanks,
    Scott
    Help out other by using the rating system and marking answered questions as "Answered"

  • Guest-Anchor-WLC and NAC integration guide

    I was trying to find some design reference for the Guest-WLC and NAC integration guide. Anyone can share some experience/cisco docs/links?

    User traffic is locally bridged on a 1030 in REAP mode so packet forwarded to the default gtw would follow the NAT rules on the firewall but the real challenge is the LWAPP control channel. In that past using 1:1 NAT I was successful with a CP firewall but I had to play tricks with the mobility group and use the FW logs to track and define the right ports.

Maybe you are looking for