Solved: DHCP for VPN

Nicholas Wysocki · ‎05-17-2010

I have users VPN from the outside currently i use a address pool. but i want to use the DHCP server instead. I have a test lab setup useing a asa5510 and a 3750 as the dhcp server. the interface between them are trunked: 3750: vlan4 10.0.4.1, vlan 5 10.0.5.1, vlan6 10.0.6.1 and the 5510: insidevlan4: 10.0.4.2, insidevlan5 10.0.5.2, insidevlan6 10.0.6.2, outside 65.0.0.1. ospf is enable between the 3750 and 5510 at the 10.0.0.0/8.

5510:

global

dhcprelay sever 10.0.6.1 insidevlan6

dhcprelay enable outside

dhcprelay setroute outside

group-policy

vlan 6

ip address pool none

-if i address a address-pool the connection works.

-if i remove the address-pool and put in the dhcp relay, the syslog on 5510 show the connection. DHCP enable, no response.

-the 3750 does not show the request from the firewall.

-right now for the test lab i am using a local username. i will end up using SDI for authx in production.

What am i missing, please help?

Jeffrey Schutt · ‎05-18-2010

Good Catch Nicholas!

Looks like you could be running into the same symptoms experienced in bug

CSCsf22066: ASA - dhcp-network-scope/DHCP-proxy giaddr issue with RFC2131

This was a duplicate of enhancement request CSCsm60591 which has been resolved in the latest ASA images. See bug toolkit for more details.

I also came across this in the configuration guide:

"When it receives a DHCP request, the security appliance sends a discovery message to the DHCP server. This message includes the IP address (within a subnetwork) configured with the dhcp-network-scope command in the group policy. If the server has an address pool that falls within that subnetwork, it sends the offer message with the pool information to the IP address—not to the source IP address of the discovery message.

•For example, if the server has a pool of the range 209.165.200.225 to 209.165.200.254, mask 255.255.255.0, and the IP address specified by the dhcp-network-scope command is 209.165.200.1, the server sends that pool in the offer message to the security appliance."

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/dhcp.html#wp1116296

This is why you stated that "I can see the 3750 sending the requested address back to 10.0.6.0". The ASA sets the GIADDR field in the DHCP Discover to be the dhcp-network-scope defined within your group-policy. It's my impression that by setting the ip address to 10.0.6.2 the DHCP Offer will be returned to a host address that the ASA can listen for as opposed to the subnet's network address which the ASA ignores.

View solution in original post

Jeffrey Schutt · ‎05-17-2010

Hey Nicholas,

Your DHCP relay configuration would be appropriate if you had hosts that were connecting directly to the outside interface and looking to receive an ip address via the DHCP server. But because you want to assign a DHCP address to vpn user you'll want to use the following configuration:

asa(config)# tunnel-group anyconnect_only general-attributes

asa(config-tunnel-general)# dhcp-server 10.0.0.6

Optionally you can configure the scope of addresses to match what the server is handing out:

asa(config)# group-policy anyconnect_only attributes

asa(config-group-policy)# dhcp-network-scope 192.168.1.0

If in production you end up using multiple DHCP servers that share a dhcp-network-scope value, then here's a bug that you'll want to make sure you're past when setting this up:

CSCsy56403 ASA stops accepting IP from DHCP when DHCP Scope option is configured

Look at the bug details to see other things you can try when troubleshooting this such as...

1) packet capture on dhcp-server facing interface

2) ASA logs set to level debugging at time of issue

3) turn on dhcp debugs on the ASA

Thanks,

Jeff

Nicholas Wysocki · ‎05-17-2010

Jeff,

Thank you for that, it helped. I removed the dhcprelay and int he tunnel-group general put the "dhcp-server 10.0.6.1". the dhcp server recived the request and issused an ip address. Now the 5510, its eaiser if i paste the log.

3750#
*Mar 10 19:36:25.007: DHCPD: incoming interface name is Vlan6
*Mar 10 19:36:25.007: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d
30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6933.2d69.6e73.6964.65
76.6c61.6e36.00 through relay 10.0.6.0.
*Mar 10 19:36:27.020: DHCPD: assigned IP address 10.0.6.8 to client 0063.6973.63
6f.2d30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6933.2d69.6e73.69
64.6576.6c61.6e36.00.
*Mar 10 19:36:27.020: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.303
1.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6933.2d69.6e73.6964.6576.6c6
1.6e36.00 (10.0.6.8).
*Mar 10 19:36:27.020: DHCPD: unicasting BOOTREPLY for client 001e.be79.692b to r
elay 10.0.6.0.
*Mar 10 19:36:28.002: DHCPD: incoming interface name is Vlan6
*Mar 10 19:36:28.002: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d
30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6933.2d69.6e73.6964.65
76.6c61.6e36.00 through relay 10.0.6.0.
*Mar 10 19:36:28.002: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.303
1.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6933.2d69.6e73.6964.6576.6c6
1.6e36.00 (10.0.6.8).
*Mar 10 19:36:28.002: DHCPD: unicasting BOOTREPLY for client 001e.be79.692b to r
elay 10.0.6.0.
*Mar 10 19:36:32.003: DHCPD: incoming interface name is Vlan6
*Mar 10 19:36:32.003: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d
30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6933.2d69.6e73.6964.65
76.6c61.6e36.00 through relay 10.0.6.0.
*Mar 10 19:36:32.003: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.303
1.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6933.2d69.6e73.6964.6576.6c6
1.6e36.00 (10.0.6.8).
*Mar 10 19:36:32.003: DHCPD: unicasting BOOTREPLY for client 001e.be79.692b to r
elay 10.0.6.0.
*Mar 10 19:36:37.003: DHCPD: incoming interface name is Vlan6
*Mar 10 19:36:37.003: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d
30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6933.2d69.6e73.6964.65
76.6c61.6e36.00 through relay 10.0.6.0.
*Mar 10 19:36:37.003: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.303
1.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6933.2d69.6e73.6964.6576.6c6
1.6e36.00 (10.0.6.8).
*Mar 10 19:36:37.003: DHCPD: unicasting BOOTREPLY for client 001e.be79.692b to r
elay 10.0.6.0.
3750#

test#5510
May 17 2010 03:08:59: %ASA-6-713172: Group = Remote_Operations_VPN6, IP = 65.0.0
.2, Automatic NAT Detection Status: Remote end is NOT behind a NAT device
This end is NOT behind a NAT device
May 17 2010 03:09:00: %ASA-6-113012: AAA user authentication Successful : local
database : user = root
May 17 2010 03:09:00: %ASA-6-113009: AAA retrieved default group policy (Remote_
Operations_VPN6) for user = root
May 17 2010 03:09:00: %ASA-6-113008: AAA transaction status ACCEPT : user = root

May 17 2010 03:09:00: %ASA-6-734001: DAP: User root, Addr 65.0.0.2, Connection I
PSec: The following DAP records were selected for this connection: DfltAccessPol
icy
May 17 2010 03:09:02: %ASA-5-713130: Group = Remote_Operations_VPN6, Username =
root, IP = 65.0.0.2, Received unsupported transaction mode attribute: 5
May 17 2010 03:09:02: %ASA-6-713184: Group = Remote_Operations_VPN6, Username =
root, IP = 65.0.0.2, Client Type: WinNT Client Application Version: 5.0.06.0160

May 17 2010 03:09:02: %ASA-6-737017: IPAA: DHCP request attempt 1 succeeded
May 17 2010 03:09:02: %ASA-6-737005: IPAA: DHCP configured, request succeeded fo
r tunnel-group 'Remote_Operations_VPN6'
May 17 2010 03:09:02: %ASA-6-302015: Built outbound UDP connection 232 for insid
evlan6:10.0.6.1/67 (10.0.6.1/67) to identity:10.0.6.2/67 (10.0.6.2/67)
May 17 2010 03:09:07: %ASA-5-713201: Group = Remote_Operations_VPN6, Username =
root, IP = 65.0.0.2, Duplicate Phase 2 packet detected. No last packet to retra
nsmit.
May 17 2010 03:09:12: %ASA-5-713201: Group = Remote_Operations_VPN6, Username =
root, IP = 65.0.0.2, Duplicate Phase 2 packet detected. No last packet to retra
nsmit.
May 17 2010 03:09:14: %ASA-4-737019: IPAA: Unable to get address from group-poli
cy or tunnel-group local pools
May 17 2010 03:09:14: %ASA-3-713132: Group = Remote_Operations_VPN6, Username =
root, IP = 65.0.0.2, Cannot obtain an IP address for remote peer
test5510#

What do you think?

Nicholas Wysocki · ‎05-17-2010

the sys message 713201 is not in the message lookup.

Jeffrey Schutt · ‎05-18-2010

Hi Nicholas,

Note that after a 5 second delay the ASA logs message %ASA-5-713201, and after another 5 seconds you see the same message logged. This message is coming from the VPN Client, it is the client's retransmission requests for a dhcp address. On the client logs you should see these same retransmits.

In your logs I see the outbound UDP connection build but I do not see a subsequent inbound UDP connection built. Apparently either the ASA is blocking the inbound UDP connection from the DHCP Server back to it (not likely because we don't see any deny messages in your logs), or the response from the 3750 is not making it back to the ASA. When I set this up in the lab I saw the following messages that differ from yours:

May 18 2010 09:22:41: %ASA-7-737001: IPAA: Received message 'UTL_IP_[IKE_]ADDR_REQ'
May 18 2010 09:22:41: %ASA-6-737017: IPAA: DHCP request attempt 1 succeeded
May 18 2010 09:22:41: %ASA-6-737005: IPAA: DHCP configured, request succeeded for tunnel-group 'anyconnect_only'
May 18 2010 09:22:41: %ASA-6-302015: Built outbound UDP connection 10806 for inside:192.168.5.100/67 (192.168.5.100/67) to identity:192.168.5.1/67 (192.168.5.1/67)
May 18 2010 09:22:41: %ASA-7-609001: Built local-host corp:192.168.255.3
May 18 2010 09:22:43: %ASA-6-302015: Built inbound UDP connection 10808 for inside:192.168.5.100/67 (192.168.5.100/67) to identity:192.168.255.0/67 (192.168.255.0/67)
May 18 2010 09:22:43: %ASA-7-737001: IPAA: Received message 'UTL_IP_DHCP_ADDR'
May 18 2010 09:22:43: %ASA-7-609001: Built local-host dmz:192.168.255.3
May 18 2010 09:22:43: %ASA-5-722033: Group User IP <172.18.254.122> First TCP SVC connection established for SVC session.
May 18 2010 09:22:43: %ASA-4-722051: Group User IP <172.18.254.122> Address <192.168.255.3> assigned to session

To further troubleshoot your problem I would check any access-groups configured on the inside interface and use the ASA's packet-capture functionality to see more details about the problem:

capture inside6 interface insidevlan6 buffer 1000000

show capture inside6

Nicholas Wysocki · ‎05-18-2010

I read that before and noticed the outbound with no inbound. I tried both ways this morning w/access-list and without. On interface insidevlan6 access in is:

extended permit udp any any eq 67

extended permit ip any any

extended deny any any log

I can see the 3750 sending the requested address back to 10.0.6.0

I did make sure: vpn-addr-assign dhcp

any ideas?

here is that capture from the 5510 insidevlan6:

3: 00:17:58.316038 802.1Q vlan#6 P0 10.0.6.2.67 > 10.0.6.1.67: udp 548
   4: 00:17:58.318861 802.1Q vlan#6 P0 arp who-has 10.0.6.20 tell 10.0.6.1
   5: 00:18:00.327818 802.1Q vlan#6 P0 10.7.10.2.67 > 255.255.255.255.67: udp 300
   6: 00:18:01.308638 802.1Q vlan#6 P0 10.0.6.2.67 > 10.0.6.1.67: udp 548
   7: 00:18:01.310317 802.1Q vlan#6 P0 10.7.10.2.67 > 255.255.255.255.67: udp 300
   8: 00:18:05.308638 802.1Q vlan#6 P0 10.0.6.2.67 > 10.0.6.1.67: udp 548
   9: 00:18:05.315138 802.1Q vlan#6 P0 10.7.10.2.67 > 255.255.255.255.67: udp 300
10: 00:18:07.341306 802.1Q vlan#6 P6 10.0.6.1 > 224.0.0.5: ip-proto-89, length 60
11: 00:18:07.898696 802.1Q vlan#6 P0 10.0.6.2 > 224.0.0.5: ip-proto-89, length 48
12: 00:18:10.308638 802.1Q vlan#6 P0 10.0.6.2.67 > 10.0.6.1.67: udp 548
13: 00:18:10.311965 802.1Q vlan#6 P0 10.7.10.2.67 > 255.255.255.255.67: udp 300

3750(config)#
*Mar 11 17:01:53.390: DHCPD: checking for expired leases.
3750(config)#
*Mar 11 17:01:55.101: DHCPD: incoming interface name is Vlan6
*Mar 11 17:01:55.101: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d
30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6931.312d.696e.7369.64
65.766c.616e.3600 through relay 10.0.6.0.
3750(config)#
*Mar 11 17:01:57.114: DHCPD: assigned IP address 10.0.6.22 to client 0063.6973.6
36f.2d30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6931.312d.696e.7
369.6465.766c.616e.3600.
*Mar 11 17:01:57.114: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.303
1.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6931.312d.696e.7369.6465.766
c.616e.3600 (10.0.6.22).
*Mar 11 17:01:57.114: DHCPD: unicasting BOOTREPLY for client 001e.be79.692b to r
elay 10.0.6.0.
*Mar 11 17:01:58.096: DHCPD: incoming int
3750(config)#erface name is Vlan6
*Mar 11 17:01:58.096: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d
30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6931.312d.696e.7369.64
65.766c.616e.3600 through relay 10.0.6.0.
*Mar 11 17:01:58.096: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.303
1.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6931.312d.696e.7369.6465.766
c.616e.3600 (10.0.6.22).
*Mar 11 17:01:58.096: DHCPD: unicasting BOOTREPLY for client 001e.be79.692b to r
elay 10.0.6.0.
3750(config)#
*Mar 11 17:02:02.097: DHCPD: incoming interface name is Vlan6
*Mar 11 17:02:02.097: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d
30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6931.312d.696e.7369.64
65.766c.616e.3600 through relay 10.0.6.0.
*Mar 11 17:02:02.097: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.303
1.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6931.312d.696e.7369.6465.766
c.616e.3600 (10.0.6.22).
*Mar 11 17:02:02.097: DHCPD: unicasting BOOTREPLY for cli
3750(config)#ent 001e.be79.692b to relay 10.0.6.0.
3750(config)#
*Mar 11 17:02:07.097: DHCPD: incoming interface name is Vlan6
*Mar 11 17:02:07.097: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d
30.3031.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6931.312d.696e.7369.64
65.766c.616e.3600 through relay 10.0.6.0.
*Mar 11 17:02:07.097: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.303
1.652e.6265.3739.2e36.3932.622d.6c6e.7779.736f.636b.6931.312d.696e.7369.6465.766
c.616e.3600 (10.0.6.22).
*Mar 11 17:02:07.097: DHCPD: unicasting BOOTREPLY for cli
3750(config)#ent 001e.be79.692b to relay 10.0.6.0.

Nicholas Wysocki · ‎05-18-2010

ok i got it to work by changing the dhcp-network-scope under the group-policy from 10.0.6.0 to 10.0.6.2.

both are in the same network, any ideas why that worked?

Jeffrey Schutt · ‎05-18-2010

Good Catch Nicholas!

Looks like you could be running into the same symptoms experienced in bug

CSCsf22066: ASA - dhcp-network-scope/DHCP-proxy giaddr issue with RFC2131

This was a duplicate of enhancement request CSCsm60591 which has been resolved in the latest ASA images. See bug toolkit for more details.

I also came across this in the configuration guide:

"When it receives a DHCP request, the security appliance sends a discovery message to the DHCP server. This message includes the IP address (within a subnetwork) configured with the dhcp-network-scope command in the group policy. If the server has an address pool that falls within that subnetwork, it sends the offer message with the pool information to the IP address—not to the source IP address of the discovery message.

•For example, if the server has a pool of the range 209.165.200.225 to 209.165.200.254, mask 255.255.255.0, and the IP address specified by the dhcp-network-scope command is 209.165.200.1, the server sends that pool in the offer message to the security appliance."

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/dhcp.html#wp1116296

This is why you stated that "I can see the 3750 sending the requested address back to 10.0.6.0". The ASA sets the GIADDR field in the DHCP Discover to be the dhcp-network-scope defined within your group-policy. It's my impression that by setting the ip address to 10.0.6.2 the DHCP Offer will be returned to a host address that the ASA can listen for as opposed to the subnet's network address which the ASA ignores.

JamieVarcadipane5776 · ‎05-19-2021

Hello,

I came across your response while weeding through pages of various google search results.... I think you may have just saved me from my 4 month nightmare of a ASAv configuration. You are awesome!! I am off to do some additional testing. Again, seriously THANK YOU!

Jeffrey Schutt · ‎05-19-2021

Wow! Over a decade later and this post is still adding value. Thanks for taking the time to post your feedback, Jamie

JamieVarcadipane5776 · ‎08-13-2021

Hello,

You are welcome, and this post did help me solve my issue.

Jamie