Anyconnect VPN DHCP server issues

[Chris Coates]

Hi All,

I'm having some issues getting a DHCP address allocation for an Anyconnect VPN client. The network layout is as follows:

AnyConnect Client -----------> ASA -----------> Router ----------->DHCP server

I can ping the DHCP server from the ASA so routing seems to be ok and I have tried using both the dhcp subnet-selection and link-selection options with no luck. Here's the debug output of the ASA indicating it cannot get an address:

webvpn_cstp_parse_request_field()
...input: 'X-CSTP-Protocol: Copyright (c) 2004 Cisco Systems, Inc.'
Processing CSTP header line: 'X-CSTP-Protocol: Copyright (c) 2004 Cisco Systems, Inc.'
cstp_util_address_ipv4_accept: no address?!?
cstp_util_address_ipv6_accept: No IPv6 Address
No assigned address
Not calling vpn_remove_uauth: not IPv4!
webvpn_svc_np_tear_down: no IPv6 ACL

--------------------------------------------------------------

Here is the current pertinent config (sanitized):

---------------------------------------------------------------

vpn-addr-assign dhcp

group-policy TEST internal
group-policy TEST attributes
dhcp-network-scope 1.2.3.0
dns-server value 1.2.1.1
vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless
default-domain value test.com

tunnel-group TEST type remote-access
tunnel-group TEST general-attributes
default-group-policy TEST
dhcp-server subnet-selection 1.2.1.2
authentication-server-group testvpngrp

tunnel-group TEST webvpn-attributes
group-alias TEST enable

tunnel-group TEST ipsec-attributes
ikev1 pre-shared-key testkey

access-list inside_interface extended permit ip any4 any4 log

---------------------------------------------------

 I have set up the following packet capture with a source address of the inside interface of the ASA (1.2.5.1) to the DHCP server (1.2.1.2)

capture dhcptest match ip host 1.2.5.1 host 1.2.1.2

But when I try to connect up there are no hits on the capture. 

Am I missing something? I have read that I might need to do a 'no vpn-addr-assign local', but this would break the existing VPN config. Is it possible to have different groups configured one using local and one using dhcp addresses simultaneously?

Thanks in advance!

Chris

[Rahul Govindan]

Try running a "debug dhcpd packet 255" and "debug dhcpd event 255". Also, try changing your capture to:

capture dhcptest interface <inside-intf-name> match ip host 1.2.5.1 host 1.2.1.2

[Chris Coates]

Thanks Rahul, I tried running both debugs you mentioned and the amended capture but I get no hits on either. It seems like it's not sending the DHCP request at all, but I'm not sure what I could have missed. 

[Rahul Govindan]

Hey Chris,

It almost looks like the test user is not falling into the right group. I see that you have an Alias configured, so I am assuming that you are choosing TEST in the dropdown menu.

Also, small correction in the debug I sent earlier, could you try the below:

debug dhcpc packet 255

debug dhcpc error 255

In addition to this, apply a "debug aggregate-auth xml 255" during testing time.

[Chris Coates]

Hi Rahul,

I tried the first two debugs you mentioned and got some useful info:

DHCP: DHCPProxy_request
DHCP: Cannot enable DHCP Proxy on an interface running DHCP Relay, Relay Server, or Server.
DHCP Proxy Request failed.

That seems to relate to this article here, conveniently created yesterday!

https://quickview.cloudapps.cisco.com/quickview/bug/CSCsq84250

I can't disable DHCP relay as it's needed, so it looks like it's not going to happen with the current software build.

Out of interest, what would the last debug you mentioned have shown?

Many thanks for all your help.

Chris

[Rahul Govindan · Accepted solution]

Glad that you were able to locate the issue, but its unfortunate that you are running into this limitation. This limitation has been there for a while now - since they introduced the DHCP proxy for VPN users.

The last debug was more a generic debug for anyconnect sessions, which would have shown which tunnel-group was being hit by the user. If there was some other policy pushing users to another tunnel-group (say certificate-map to assign tunnel-group), we would have seen it in that debug.