Bizzare issue with DHCP Relay - ASA5510

Unanswered Question
Mar 28th, 2007

Hello all,

we recently upgraded our DNS/DHCP servers with newer hardware and more up-to-date version of Linux.

The previous servers were not behind a firewall. The current servers are placed behind our ASA5510 appliance, and we have set up translations and access lists accordingly (please see config).

So we switched to the new servers.. and discovered that a number of our ADSL clients can NOT obtain an IP from the DHCP server behind the firewall, UNLESS: we have them assign their IP address to their PC or router statically; then if they switch back to dynamic IP they can obtain that same IP no problem.

Just to isolate the issue, we put the DHCP server on the outside and the problem went away (of course, we can't leave it on the outside for any extended amounts of time).

When I debugged DHCP relay, I can see that the firewall is passing the requests, and the DHCP server is replying, but the client never gets an IP unless we statically assign it first.

(In other words, "exchange complete" is the part that is missing prior to us having the customer statically assign the IP first).

Please help!

Thanks in advance!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
spejic Wed, 03/28/2007 - 07:47

hostname ASA5510


enable password xxx



name NS1

name NS2

name DNS1

name DNS2


interface Ethernet0/0

nameif outside

security-level 0

ip address 123.x.x.150

interface Ethernet0/1


nameif inside

security-level 100

ip address

interface Ethernet0/2

nameif DMZ

security-level 50

ip address

interface Ethernet0/3


no nameif

no security-level

no ip address

interface Management0/0


no nameif

no security-level

no ip address

ftp mode passive

object-group network WEBFTPSERVERS

network-object host

network-object host

network-object host

network-object host

network-object host

network-object host

network-object host

network-object host

object-group network DNSSERVERS

network-object host

network-object host

network-object host

network-object host

object-group service WEB_FTP tcp

port-object eq www

port-object eq ftp

port-object eq ftp-data

object-group service DNS_DHCP_RADIUS udp

port-object eq domain

port-object eq bootpc

port-object eq radius

port-object eq radius-acct

port-object eq bootps

access-list OUTSIDE-IN extended permit tcp any object-group WEBFTPSERVERS object

-group WEB_FTP log

access-list OUTSIDE-IN extended permit udp any object-group DNSSERVERS object-gr


access-list OUTSIDE-IN extended permit icmp any any

access-list DMZ-OUT extended permit ip any any

mtu outside 1500

mtu inside 1500

mtu DMZ 1500

ip verify reverse-path interface outside

ip audit name ProtectUs attack action alarm drop reset

ip audit interface outside ProtectUs

no failover

arp timeout 14400

global (outside) 1

nat (DMZ) 1

static (DMZ,outside) netmask

static (DMZ,outside) netmask

static (DMZ,outside) netmask

static (DMZ,outside) netmask

static (DMZ,outside) netmask

static (DMZ,outside) netmask

static (DMZ,outside) netmask

static (DMZ,outside) netmask

static (DMZ,outside) NS1 netmask

static (DMZ,outside) NS2 netmask

static (DMZ,outside) DNS1 netmask

static (DMZ,outside) DNS2 netmask

access-group OUTSIDE-IN in interface outside

access-group DMZ-OUT out interface DMZ

route outside 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00

timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00

no snmp-server enable

telnet timeout 5

ssh timeout 5

console timeout 0

dhcprelay server DNS2 DMZ

dhcprelay enable outside

dhcprelay timeout 60


class-map inspection_default

match default-inspection-traffic


policy-map global_policy

class inspection_default

inspect dns maximum-length 512

inspect ftp

inspect h323 h225

inspect h323 ras

inspect netbios

inspect rsh

inspect rtsp

inspect skinny

inspect esmtp

inspect sqlnet

inspect sunrpc

inspect tftp

inspect sip

inspect xdmcp

inspect http

inspect icmp


service-policy global_policy global

: end


David White Fri, 03/30/2007 - 13:42

This sounds like a bug, but we are not aware of any known issues in this area.

I would suggest opening a TAC case so it can be further diagnosed.

But you will need to get a capture of the dhcp-relay packets on both interfaces (using the capture feature). And collect both a bad, and good (when users first static the ip) captures.

You can also post the capture here and I will try to take a quick look.



spejic Fri, 03/30/2007 - 14:35

Hi David,

thank you for your reply!

I was hoping the issue was simply a mistake I made configuring the appliance; but if you think it might be a bug, then I will assume there's nothing wrong with the config (everything else works properly behind the firewall).

We had no choice but to put our DHCP server on the outside and harden the Linux system.

We'll have to leave it like this for now, as we can't afford any more customer downtime.

Therefore, I won't be able to perform packet capture any time soon..

but thanks very much for your offer!!




This Discussion