Dhcp proxy vs relay

What is the difference between dhcp relay and dhcp proxy with respect to ASAs?
Thanks,
Kashish

Hi Bro
DHCP relay listens to local broadcast messages from PC, and forwards these messages on another network towards the DHCP server. The DHCP server responds, and the replies is then forwarded back to the PC.
DHCP proxy is a fully-functional DHCP server and client built inside. The PC establishes IP leases from the DHCP server on one interface, and then keeps these addresses in a pool. On another interface, the server side of the implementation provides leases to other machines using that pool.
Cisco PIX/ASA Firewalls supports both method. In many of my previous implementations, the FW interface on which it behaves as a DHCP server has a dedicated, manually-configured address pool, and the only thing the proxy feature does is get configuration parameters from another upstream server e.g. equipment configuration, as shown below;
Router(config)#boot ?
bootstrap Bootstrap image file
config     Configuration file
host       Router-specific config file
network    Network-wide config file
system     System image file
P/S: If you think this comment was helpful, please do rate it nicely :-)

Similar Messages

ASA 5512-X - VPN & local clients DHCP relaying (DHCP Proxy vs. DHCP Relay conflict)

Hey all,
I have ASA-5512-X serving as general firewall/router. It also serves as AnyConnect SSL VPN gateway (webvpn).
It has ~10 VLANs connected over 1 trunk port. One of the VLANs has DHCP server that shall serve all the VLANs (192.168.16.2).
I'm trying to have the ASA relay DHCP requests from all VLANs to the DHCP server and to also serve VPN clients.
However, according to bug https://tools.cisco.com/bugsearch/bug/CSCsd22469 both DHCP Proxy (webvpn) and DHCP Relay (local interfaces) can't be enabled at the same time.
As VPN clients connect to the same VLANs as local users (eg. VLAN 2 - 192.168.2.0/24) I want to have the very same DHCP server serving both, otherwise it's gonna become a mess.
Note: if I configure DHCP Relay functionality and disable DHCP Proxy - local clients are served fine. If I configure DHCP Proxy (webvpn) and disable DHCP Relay VPN clients are served fine. I therefore consider setup to be correct, just the ASA limitation won't allow me to make it serve both.
Can DHCP Relay also serve VPN clients (no DHCP Proxy enabled)? did I miss something?
Thanks!

Hi,
The only workaround for this issue is to configure the ASA itself to act as DHCP server for vpn clients. You also have the flexibility of using local pool and AAA server. Why exactly do you want to use the same DHCP server for both?
AM

DHCP proxy not working

I have two WLC 4402 servicing several SSIDs. Every SSID represents a different VLAN with a different IP subnet.
Now I want to use one DHCP server for all SSIDs. So I configured the server (I disinguish the requests from the different networks by option 82), put him into the VLAN where the ap-manager and the management interfaces are residing in and configured the DHCP server address of the interfaces on the WLC appropriate to the new setup.
Now my problem: No request arrives at the server. I now tried nearly all options but without success.
I found out that relaying works if the DHCP server is on the SAME subnet. Then all requests are relayed (yes, relayed, unicasted by the controller).
DHCP debug of the WLC says:
DHCP received op BOOTREQUEST (1) (len 313, port 1, encap 0xec03)
DHCP selecting relay 1 - control block settings: dhcpServer: 10.22.72.3, dhcpNetmask: 255.255.248.0, dhcpGateway: 10.22.72.33, dhcpRelay: 10.22.72.1 VLAN: 22
DHCP selected relay 1 - 10.22.72.3 (local address 10.22.72.1, gateway 10.22.72.3, VLAN 22, port 1)
DHCP transmitting DHCP REQUEST (3)
If now I enter the DHCP server address of the new server (directly reachable though the ap-amanager and management interfaces) I get the following:
DHCP received op BOOTREQUEST (1) (len 308, port 1, encap 0xec03)
DHCP selecting relay 1 - control block settings: dhcpServer: 0.0.0.0, dhcpNetmask: 0.0.0.0, dhcpGateway: 0.0.0.0, dhcpRelay: 10.6.72.1 VLAN: 640
DHCP selected relay 1 - NONE
It just seems to ignore the entered DHCP server address.
I tried several software versions (v4.2, v5.2), all the same.
DHCP proxy is enabled - as mentioned, if the DHCP server is in the same subnet, it works fine.
Any suggestions?

Here's the debug data as requested. Its shows the complete connection try of a notebook.
As I took a look on it myself I noticed line 77 of the debug output:
DHCP selected relay 1 - 10.44.1.9 (local address 10.6.72.1, gateway 10.6.72.33, VLAN 640, port 1)
It obviously selected the correct ip of the DHCP server (10.44.1.9). But does the rest mean the Controller tries to forward the request via the standard gateway of the VLAN the client resides in? (10.6.72.33 is the standard gateway of the WLAN of the client). This will fail because the network the DHCP server resides in doesn't have a gateway and is therefor unreachable by other networks (by purpose).
Is there a way to make the controller send out the relayed request though its interface in the network of the DHCP server?

WLC DHCP Proxy - To Do or Not to Do?

What is the upside/downside of turning of the WLC's DHCP Proxy setting? I know the option is there now, but it still defaults to proxy mode, so whats the issues? I ask, because, I could make a current issue of a guest wlan getting to a dhcp server a lot easier, if the client requests it. I can then dhcp relay off of a pix and to my enterprise dhcp/dns server. But I'm concerned what effect this may have on my other wlans.

Dhcp proxy is required if the WLC is the dhcp server, if you disable this remember to add the ip-helper address to your L3 interfaces.
That part of the config is a holdover from the Airespace days that helped the WLC learn the ip access of the clients. This has been fixed updated in later releases of code. So to proxy or not to proxy is really up to if the WLC is the dhcp or not. Unless yopu are running 6.0.196.0 or 7.0.980. Where you could hit CSCth68708
Sent from Cisco Technical Support iPad App

DHCP Proxy

Hello,
I recently upgraded our WiSM software to version 4.2.99 from 4.1.171.0 to bypass the DHCP relay issues. However, I am still having issues with some clients not receiving DHCP addresses.
I am using a Microsoft 2k3 server for DHCP and disabled dhcp proxy on the CLI of both controllers. I currently only have DHCP identified on the WLAN dynamic interface, although I have tried for S&G to enable the DHCP override also. I continue to get the same results.
If I assign a static IP address I am able to browse intervlan, etc.
Has anyone ran into this before? Thanks in advance.
Kendall

The only time I have ever had DHCP issues when implementing wireless is if I forget the map the interface to the WLAN SSID. If you configure a port on the chassis for the same vlan the wireless users will be on, can you get an IP. this will eliminate issues on the network side. If you can then I would delete the WLAN and recreate it and see if that works. If that doesn't help, then reboot the WiSM blade.

Asr9k dhcp proxy question

Hi.
There's a propietery dhcp server that in certain cases, assigns yiaddr=127.0.0.1. The goal is to get rid of unwanted clients.
An asr9k configured as dhcp proxy sends a release for every ack for yiaddr=127.0.0.1, so client never gets this assignment and tries again and again multiplying traffic.
I know this dhcp server config doesn't make much sense, but I don't see any limitations about this on rfc2131 nor draft-ietf-dhc-proxyserver-opt-05.
Is there any way to workaround this?
Thanks!
Diego

DHCP Proxy uses the VIP and not the management IP of the WLC. Is one of the WLC ports connected to your internal network and the other port connected to the FW? Again with DHCP Proxy enabled, traffic will flow to your internal DHCP server as long as you have all the dhcp server address configured on the interfaces and have ip helper-address setup on the L3 interfaces.
Here is a doc regarding DHCP Proxy:
http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a0080af5d13.shtml#DHCP-Proxy

Asr9k dhcp proxy

Hi.
There's a propietery dhcp server that in certain cases, assigns yiaddr=127.0.0.1. The goal is to get rid of unwanted clients.
An asr9k configured as dhcp proxy sends a release for every ack for yiaddr=127.0.0.1, so client never gets this assignment and tries again and again multiplying traffic.
I know this dhcp server config doesn't make much sense, but I don't see any limitations about this on rfc2131 nor draft-ietf-dhc-proxyserver-opt-05.
Is there any way to workaround this?
Thanks!
Diego

hi vikas,
yeah that is the current existing limitation we have whereby the Prefix-Delegation with a local server is tied to all subscriber access interfaces.
If you need more granularity we can provide that by using radius and an offbox dhcp server if that is an option for you.
This way you have the ability also to load a dhcp class from radius to signal to the dhcp server this class so a more selective pool can be used.
Mixing local dhcp server with offbox is currently not available.
I would like to do this functionality, but it is not a quick fix unfortunately. So if that on a per access interface bases local DHCP pool is a requirement, I would need to redirect you to your account team and facilitate a discussion with our eng group to see what can be done when.
Today; (using) radius (for pool selection on an OFF-box server) is your best option.
cheers!
xander

Disable dhcp proxy for PPP VPN (outside DHCP server + NPS)

Hi,
Our VPN setup is to authenticate / authorize via RADIUS to a Microsoft NPS server / Active Directory and use our internal DHCP server to receive its information. We are running a Cisco 2811, with firmware release k9 15.1- 4.M5.
However, we have been having some issues with our setup for a dial-in VPN. We managed to get almost everything working.
The user can dial in and authenticate and it even builds the proper PPTP tunnel. However, the client machine when it sends out a DHCP requests seems to get forced to proxy through the Cisco router. Thus what the DHCP server sees is a encoded MAC address from the cisco all the time and sees the client as being the cisco router not the VPN client/user. This is rather frustrating, as in Active directory DNS tables it will show up as the router having x number of different IP addresses and the end client doesn't show up at all.
I have tried utilizing a bunch of different configuration options to test, all with the same outcome.
Utilizing "ip helper-address <dhcp server>", didn't work to forward correct. Thent trying to turn of all DHCP services, with the global command of "no service dhcp", didn't change any result. Neither did setting a global command of "ip dhcp-server <dhcp server>".
What i am trying to acchive is that the cisco does NOT mess with the dhcp request and just allows it to pass through.
Anyone have any idea?
Here are the parts of the current configuration in respect to this:
no service dhcp
aaa new-model
aaa authentication login CONSOLE local
aaa authentication ppp default group radius local
aaa authorization network default if-authenticated
aaa session-id common
no ip domain lookup
ip domain name <domain>
ip name-server xxx.xxx.xxx.xxx
ip dhcp-server xxx.xxx.xxx.xxx
vpdn enable
vpdn-group 1
! Default PPTP VPDN group
accept-dialin
protocol pptp
virtual-template 1
interface Virtual-Template1
ip unnumbered FastEthernet0/1 <-Internal Interface
no ip proxy-arp
ip nat inside
no ip virtual-reassembly in
peer default ip address dhcp
ppp encrypt mppe auto required
ppp authentication pap chap ms-chap ms-chap-v2
radius-server host xxx.xxx.xxx.xxx
radius-server key <private key>
And the problem that i am seeing when running a debug on dhcp:
*Jan 15 09:01:46.558: DHCP: proxy allocate request
*Jan 15 09:01:46.558: DHCP: new entry. add to queue, interface Virtual-Access5
*Jan 15 09:01:46.558: DHCP: Client socket is opened
*Jan 15 09:01:46.558: DHCP: SDiscover attempt # 1 for entry:
*Jan 15 09:01:46.558: DHCP: SDiscover: sending 284 byte length DHCP packet
*Jan 15 09:01:46.558: DHCP: SDiscover 284 bytes
*Jan 15 09:01:46.562: DHCP: XID MATCH in dhcpc_for_us()
*Jan 15 09:01:46.990: DHCP: Received a BOOTREP pkt
*Jan 15 09:01:46.990: DHCP: offer received from <DHCP SERVER>
*Jan 15 09:01:46.990: DHCP: SRequest attempt # 1 for entry:
*Jan 15 09:01:46.990: DHCP: SRequest- Server ID option: <DHCP SERVER>
*Jan 15 09:01:46.990: DHCP: SRequest- Requested IP addr option: 192.168.10.100
*Jan 15 09:01:46.990: DHCP: SRequest: 296 bytes
*Jan 15 09:01:46.990: DHCP: SRequest: 296 bytes
*Jan 15 09:01:46.994: DHCP: XID MATCH in dhcpc_for_us()
*Jan 15 09:01:46.994: DHCP: Received a BOOTREP pkt
*Jan 15 09:01:46.994: DHCP: Sending notification of ASSIGNMENT:
*Jan 15 09:01:46.994: Address 0.0.0.0 mask 0.0.0.0
*Jan 15 09:01:46.994: DHCP Proxy Client Pooling: ***Allocated IP address: 192.168.10.100
*Jan 15 09:01:46.994: DHCP: look up prim DNS for Vi5 from lease good ret: <DNS server 1>
*Jan 15 09:01:46.998: DHCP: look up prim NBNS for Vi5 from lease any ret: fail
*Jan 15 09:01:46.998: DHCP: look up sec DNS for Vi5 from lease good ret: <DHCP Server>
*Jan 15 09:01:46.998: DHCP: look up sec NBNS for Vi5 from lease any ret: fail
*Jan 15 09:01:47.018: DHCP: look up prim DNS for Vi5 from lease good ret: <DNS server 1>
*Jan 15 09:01:47.018: DHCP: look up sec DNS for Vi5 from lease good ret: <DHCP Server>
*Jan 15 09:01:47.038: DHCP: look up prim DNS for Vi5 from lease good ret: <DNS server 1>
*Jan 15 09:01:47.038: DHCP: look up sec DNS for Vi5 from lease good ret: <DHCP Server>
*Jan 15 09:01:56.826: DHCP: Interface Virtual-Access5 going down. Releasing: 192.168.10.100
*Jan 15 09:01:56.826: DHCP: start holddown for 192.168.10.100
*Jan 15 09:01:56.826: DHCP: Holddown and T1 remain 1792 sec
As one can see even with the configuration to turn of any proxy or dhcp, the cisco router still try's to interject and proxy the request, aka:
DHCP: proxy allocate request
If anyone has any idea, please let me know
Thanks
S.

Hello Stephen.
How is this behaviour in 7.5? It's weird because in the individual interfaces you might change the value, but it doesn't get accepted. So it still seems that it's a global setting... but then: why showing this item to be changed on each interface?
Kind regards,
Flavio.

DHCP Proxy broken with particular interface/server (7.0.235.3)

We are evaulating a NAC solution that wants to be the authoritative DHCP server for its quarantine vlans.
So we created a new interface on the controller, and set that interface to use this product as the DHCP server.
Systemwide, we are running with DHCP Proxy enabled because some years ago the passthrough option was not working reliably for us alongside DHCP_REQD. Since this is a global setting we are somewhat reluctant to go playing around with it.
The WiSM card sends the DHCP request to the alternate DHCP server, that server replies, and we can even see the DHCP offer being sent out the PortChannel to the controller via a span sniff. All the source and destination addresses on the offer look OK. However, clients assigned to this interface do not acquire a DHCP address.
A DHCP address can be successfully obtained from a wired client joined to the same VLAN (the helper address is there, too. This should not interfere, and doesn't, as we tried removing it just to be thorough and still the WLC does not work.)
In the debug logs we see that interface marked as dirty for failure to resolve DHCP. However we are not using interface groups so there should be no other alternative, and as far as we can tell delivery of the requests to the DHCP server is not being blocked by the failover mechanism:
*DHCP Proxy DTL Recv Task: Feb 21 13:58:24.70 9: %SIM-3-DHCP_SERVER_NO_REPLY: sim_interface.c:1039 Failed to get DHCP response
on interface 'regtest'. Marking interface dirty.
We've tried moving the APs temporarily and rebooting the controller with the interface configuration saved to flash. This did not jog anything loose. If we set the DHCP servers on the interface back to the same servers that all the other interfaces use, DHCP works for wireless clients.
The NAC appliance uses what appears to be a vanilla Linux server, as do we in production. We can see and even alter the config for that server, and it does not contain anything eclectic, just the run of the mill options.
We've tried using DHCP override on the test SSID to send all DHCP for every interface to the NAC appliance (not our desired final result, just as a test.) This fails as well.
Anybody have any other ideas as to how to jog this loose, how to ferret more information out of the controllers, something we may have missed configuration-wise, or a bug ID?

It's a hold over from the Airespace code. In the early versions, the way the WLC learned the client IP address to put them into a RUN state, was to proxy the DHCP request, so they could see the IP offered to the client.
Granted it wasn't ideal but it was the way they did it. Now it's learned a different way, but proxy is still the default, and required if the WLC acts as a DHCP server.
HTH,
Steve
Please remember to rate useful posts, and mark questions as answered

Guest DHCP Proxy function question

Starting Point: Multiple 5508 WLCs running recent software and required to run N+1 resilience. (No Guest Anchors, Guest and Corporate WLANs on same WLC...not ideal but we are where we are!)
Whats Changing?: Migrating Guest Access from simple xDSL for Guest with DHCP delivered by the xDSL router to a regular DMZ (DMZ has no DHCP servers)...beginning migration to a proper configuration.
Question: Will the WLC running as a DHCP proxy provide DHCP leases to clients in Guest VLAN from a properly configured (Guest scope) DHCP server accessible via the management interface?
Supplemental Question :Will this affect how N+1 resilience is configured?

hi Jim
So you're legging your controllers into the DMZ? Normally anchors are involved and you place the anchor in the DMZ and tunnel. But it sounds like you have foreign controller (inside) and using these as both internal wireless and guest.
I assume you are VLANng from your controller to the DSL router.
how proxy works ..on the wlc interface you have a guest interface. you give this an ip in the guest subnet and you also add the DHCP server IP. Wireless client comes on asks for a DHCP, controller intercepts it and UNIcast on behalf of the client for a IP address.
Does that help ?

Disable DHCP Proxy per WLAN - WLC v7.2

I have a DHCP server on a WLAN that does not support Cisco's native proxy mode. I need to use DHCP bridge mode for that WLAN only.
How do I disable DHCP Proxy and switch to DHCP bridge mode for one WLAN ?
Thanks

Hello Stephen.
How is this behaviour in 7.5? It's weird because in the individual interfaces you might change the value, but it doesn't get accepted. So it still seems that it's a global setting... but then: why showing this item to be changed on each interface?
Kind regards,
Flavio.

WLC4404 DHCP Proxy

Hello everybody...
How to disable dhcp proxy on controller and what is the impact of doing it in the middle?
We tried once by giving 'config dhcp proxy disable' command but seeing virtual ip again.(likely it gets back to proxy mode).
We also have ip helper address on the L3 interface.
We have only external dhcp servers configured..
Any help would be appreciated.

Is the dhcp server on a different vlan? I would also try to remove the client as it might be the client with the stuck info. You usually don't have to reboot the WLC, but it seems like something is hanging and a reboot might just be what you need to do in the middle of the night.
Thanks,
Scott
Help out other by using the rating system and marking answered questions as "Answered"

CSCeb43304 - dhcp doesnt send ack to source ip of req when dhcp-proxy enabled

I have this problem in versoin 7.5.102.0
https://tools.cisco.com/bugsearch/bug/CSCeb43304

Thanks for the link.. In link....
H-Reap design & Functional Limitation.. it is given (An H REAP access point can be deployed with either a static IP address or a DHCP address. In the case of DHCP, a DHCP server must be available locally and must be able to provide the IP address for the access point at bootup) This is only for LAP. In my case Access Point is already registered with WLC with Static IP.
On Clients cannot connect to H-Reap section...(Ensure clients on locally switched WLANs are properly IP addressed. If DHCP is used, make sure an upstream DHCP server is properly configured and providing addresses to the clients. If static addressing is used, ensure the clients are properly configured for the correct subnet.)
I am confused about upstream DHCP server.. is it locally configured DHCP server or DHCP server configured on WLC or DHCP server configured on Remote location.
In our scenario wireless client which is confgured on H-Reap should get IP address from WLC DHCP server.
Regards..Pramod.

PXE with IP Helpers/DHCP Relay

I'm a Sysadmin and I have a question about what is best practice in regards to PXE servers. We are currently using DHCP Options for PXE clients (options 66,67). This works for most clients but is not the recommended method from either of the vendors we have used (Microsoft or Symantec). They recommend using IP Helpers / DHCP relay to forward the DHCP discover request to the PXE servers so that the PXE server is getting the actual request. This is more of an issue now with UEFI-based machines where the boot file would be different based on if the client is UEFI.
My Network team is against using IP Helpers and thinks it can cause issues. This doesn't seem to make much sense to me, as from what I understand, all that happens is both the DHCP server and the PXE servers get the DHCP discover and respond with their relevant info. Can someone clarify what, if any, issues there are using multiple IP helpers/DHCP relay with PXE Servers like SCCM & Altiris? Is this not standard practice?

It's very common to use DHCP relays (IP helpers) in order to centralize DHCP infrastructure. Larger organizations will frequently use this approach in order to avoid having to manually edit DHCP configurations at the router or switch level. Having a few servers with a central DHCP configuration for all segments is a good management proposition.
In most environments, there isn't a problem with doing this, but it is a major architectural consideration and not something you just turn on without consideration. This is largely because DHCP works on a broadcast principle. The clients are going to broadcast for the first DHCP server that answers with an acceptable offer, which they will take. If you have a mixture of local DHCP servers and relays, the local servers will respond faster and may not provide the configuration you want to deploy... at best. At worst, you will have a mix of acceptable responses and a lot of potential for conflicting addresses. On any network segment where you're using DHCP relays, the local server needs to be disabled.
It might be worthwhile going back to your network team and asking what sorts of "issues" that they feel the implementation of DHCP relays would cause. There may be something unique to your environment that makes them reluctant to pursue this approach.

Wireless Access servers 5508's won't proxy a DHCP request

Hi
This question comes from our CSC Facebook Community.
http://www.facebook.com/CiscoSupportCommunity
Who knows about Wireless Access servers 5508's and why they don't seem to want to proxy a DHCP request from a wireless client to a DHCP server?

They do.
The feature dhcp proxy must be enabled (but it is by default) and if the DHCP server ip is configured in the interface to which the SSID is attached, then it should do it.
The contrary would require a "debug client < mac address>" showing the problem to understand what is wrong.
Regards,
Nicolas

Dhcp proxy vs relay

Similar Messages

Maybe you are looking for