topic Bizzare issue with DHCP Relay - ASA5510 in Network Security

Bizzare issue with DHCP Relay - ASA5510

spejic — Mon, 11 Mar 2019 09:52:55 GMT

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!

Re: Bizzare issue with DHCP Relay - ASA5510

spejic — Wed, 28 Mar 2007 14:47:58 GMT

hostname ASA5510

domain-name xxx.com

enable password xxx

names

name 10.185.225.254 NEXTGEN

name 10.185.225.21 NS1

name 10.185.225.22 NS2

name 10.185.225.101 DNS1

name 10.185.225.110 DNS2

dns-guard

interface Ethernet0/0

nameif outside

security-level 0

ip address 123.x.x.150 255.255.255.0

interface Ethernet0/1

shutdown

nameif inside

security-level 100

ip address 192.168.110.1 255.255.255.0

interface Ethernet0/2

nameif DMZ

security-level 50

ip address 10.185.225.1 255.255.255.0

interface Ethernet0/3

shutdown

no nameif

no security-level

no ip address

interface Management0/0

shutdown

no nameif

no security-level

no ip address

ftp mode passive

object-group network WEBFTPSERVERS

network-object host 123.185.225.140

network-object host 123.185.225.141

network-object host 123.185.225.142

network-object host 123.185.225.143

network-object host 123.185.225.144

network-object host 123.185.225.145

network-object host 123.185.225.151

network-object host 123.185.225.152

object-group network DNSSERVERS

network-object host 123.185.225.21

network-object host 123.185.225.22

network-object host 123.185.225.10

network-object host 123.185.225.1

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

oup DNS_DHCP_RADIUS

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 123.185.225.139

nat (DMZ) 1 10.185.225.0 255.255.255.0

static (DMZ,outside) 123.185.225.140 10.185.225.140 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.141 10.185.225.141 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.142 10.185.225.142 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.143 10.185.225.143 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.144 10.185.225.144 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.145 10.185.225.145 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.151 10.185.225.151 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.152 10.185.225.152 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.21 NS1 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.22 NS2 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.1 DNS1 netmask 255.255.255.255

static (DMZ,outside) 123.185.225.10 DNS2 netmask 255.255.255.255

access-group OUTSIDE-IN in interface outside

access-group DMZ-OUT out interface DMZ

route outside 0.0.0.0 0.0.0.0 123.185.225.125 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

ASA5510#

Re: Bizzare issue with DHCP Relay - ASA5510

David White — Fri, 30 Mar 2007 20:42:21 GMT

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.

Sincerely,

David.

Re: Bizzare issue with DHCP Relay - ASA5510

spejic — Fri, 30 Mar 2007 21:35:16 GMT

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!!

Regards,

Sean