cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
32520
Views
5
Helpful
17
Replies

ASA AnyConnect client fails to get IP from remote DHCP Server

I have and ASA with a dozen or so AnyConnect client profiles set up to get their IP address from my Windows DHCP server.

It was working great yesterday.

I saved the config and reloaded the device.

Now it won't issue IP's to my vpn clients.

I dont understand what is going on.

If I change the profiles to use a local pool it assigns an IP and works great.

But I can't use the local pools.  I have to use the DHCP server on the LAN.

The ONLY thing that was done recently was that a license enabling the AnyConnect Essentials was installed.

I get this in the debug:


6 Aug 30 2011 10:44:39      DAP: User test49, Addr 107.44.142.20, Connection AnyConnect: The following DAP records were selected for this connection: DfltAccessPolicy


6 Aug 30 2011 10:44:39      Group User IP <107.44.142.20> AnyConnect parent session started.


7 Aug 30 2011 10:44:39      IPAA: Received message 'UTL_IP_[IKE_]ADDR_REQ'


6 Aug 30 2011 10:44:39      IPAA: DHCP request attempt 1 succeeded


6 Aug 30 2011 10:44:39      IPAA: DHCP configured, request succeeded for tunnel-group 'MCSO-Mobiles'


6 Aug 30 2011 10:44:39  172.18.4.7 67 172.18.1.46 67 Built outbound UDP connection 30957 for Internal:172.18.1.46/67 (172.18.1.46/67) to identity:172.18.4.7/67 (172.18.4.7/67)


7 Aug 30 2011 10:44:39  192.168.6.1    Built local-host ISP1:192.168.6.1


6 Aug 30 2011 10:44:39  172.18.1.46 1 192.168.6.1 0 Built outbound ICMP connection for faddr 192.168.6.1/0 gaddr 172.18.1.46/1 laddr 172.18.1.46/1


6 Aug 30 2011 10:44:41  172.18.1.46 67 192.168.6.0 67 Built outbound UDP connection 30960 for ISP1:192.168.6.0/67 (192.168.6.0/67) to Internal:172.18.1.46/67 (172.18.1.46/67)


6 Aug 30 2011 10:44:42  192.168.6.1 0 172.18.1.46 1 Teardown ICMP connection for faddr 192.168.6.1/0 gaddr 172.18.1.46/1 laddr 172.18.1.46/1


7 Aug 30 2011 10:44:52      IPAA: Received message 'UTL_IP_DHCP_INVALID_ADDR'

4 Aug 30 2011 10:44:52      IPAA: Unable to get address from group-policy or tunnel-group local pools

1 Accepted Solution

Accepted Solutions

Well, your config looks good. Did you also upgrade the OS ? Perhaps you are hitting a new bug.

I havent heard of issues after installing a license but it might be worth opening a TAC case and find out if you are hitting a bug.

View solution in original post

17 Replies 17

raga.fusionet
Level 4
Level 4

Hi,

I would start by checking that the tunnel group has the DCHP server configured.

e.g.:

tunnel-group xxxx general-attributes

default-group-policy xxxx

dhcp-server 192.168.10.1

Also you need this commands:

no vpn-addr-assign aaa

no vpn-addr-assign local

The logs are showing that the ASA can get an IP address from the local pool or tunnel group:

"Unable to get address from group-policy or tunnel-group local pools"

I hope this helps.

Raga

I disabled the aaa and local as suggested.

The dhcp server is specified in all the policies.

Still no-go.

I can watch in the logs where the dhcp server issues the ip address, but it never makes it back to the vpn client.

The message you saw was where the asa tried to get an ip from the aaa  and the local (asa) but since I dont have nay configured it failed.

To reiterate:  This worked before a reboot of the asa.  Fully tested every profile and got an ip from each scope.

Here's a little more detail on the profiles (they all are the same with the exception of the scope):

group-policy DfltGrpPolicy attributes

dns-server value 172.18.1.46

vpn-simultaneous-logins 1

vpn-idle-timeout 120

vpn-session-timeout 750

vpn-filter value ToCadServers

vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless

pfs enable

split-tunnel-policy tunnelspecified

split-tunnel-network-list value Split

default-domain value MCCC.Secure

split-dns value mccc.secure mccc.local

intercept-dhcp 255.255.255.0 enable

webvpn

  http-proxy auto-start

  anyconnect ask enable default anyconnect timeout 90

group-policy GroupPolicy_MCSO-Offices internal

group-policy GroupPolicy_MCSO-Offices attributes

wins-server none

dns-server value 172.18.1.46

dhcp-network-scope 192.168.6.0

vpn-tunnel-protocol ikev2

group-lock value MCSO-Offices

default-domain value MCCC.Secure

webvpn

  anyconnect profiles value MCSO-Offices_client_profile type user

tunnel-group MCSO-Mobiles type remote-access

tunnel-group MCSO-Mobiles general-attributes

authentication-server-group Secure-radius

default-group-policy GroupPolicy_MCSO-Mobiles

dhcp-server 172.18.1.46

tunnel-group MCSO-Mobiles webvpn-attributes

radius-reject-message

proxy-auth sdi

group-alias MCSO-Mobiles enable

tunnel-group MCSO-Offices type remote-access

tunnel-group MCSO-Offices general-attributes

authentication-server-group Secure-radius

default-group-policy GroupPolicy_MCSO-Offices

dhcp-server 172.18.1.46

authentication-attr-from-server secondary

tunnel-group MCSO-Offices webvpn-attributes

radius-reject-message

proxy-auth sdi

group-alias MCSO-Offices enable

group-policy DfltGrpPolicy attributes

dns-server value 172.18.1.46 4.2.2.2

vpn-simultaneous-logins 1

vpn-idle-timeout 120

vpn-session-timeout 750

vpn-filter value ToCadServers

vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless

pfs enable

split-tunnel-policy tunnelspecified

split-tunnel-network-list value Split

default-domain value MCCC.Secure

split-dns value mccc.secure mccc.local

intercept-dhcp 255.255.255.0 enable

webvpn

  http-proxy auto-start

  anyconnect ask enable default anyconnect timeout 90

group-policy GroupPolicy_MCSO-Offices internal
group-policy GroupPolicy_MCSO-Offices attributes
wins-server none
dns-server value 172.18.1.46
dhcp-network-scope 192.168.6.0
vpn-tunnel-protocol ikev2
group-lock value MCSO-Offices
default-domain value MCCC.Secure
webvpn
  anyconnect profiles value MCSO-Offices_client_profile type user

tunnel-group MCSO-Offices type remote-access
tunnel-group MCSO-Offices general-attributes
authentication-server-group Secure-radius
default-group-policy GroupPolicy_MCSO-Offices
dhcp-server 172.18.1.46
authentication-attr-from-server secondary
tunnel-group MCSO-Offices webvpn-attributes
radius-reject-message
proxy-auth sdi
group-alias MCSO-Offices enable

Well, your config looks good. Did you also upgrade the OS ? Perhaps you are hitting a new bug.

I havent heard of issues after installing a license but it might be worth opening a TAC case and find out if you are hitting a bug.

I have been running the 8.4.2 ios for well over a month now.

I took your sugestion about it being a bug and decided to roll the ios back to 8.4.1.

The problem disappeared.

I reverted back and forth between 8.4.2 and 8.4.1 and was able to reproduce the issue every time.

So I would say it is a bug.

Thanks for the help.

Always good to bounce ideas off another person.

Hey Glad to hear that you figure it out .

So it's definetely a bug. Interesting .

Thanks sharing your findings with the comunity.

BTW I just pinged a couple of guys from the Cisco security team. Let's see what they say about this.

Thats a good idea.  Thanks for that.

Without changing anything but the boot order for the ios I was able to toggle the problem on and off.

I would be interested in hearing what they have to say.

I'd like to use the most current ios, but this is a bug that I can't live with.

I ran across this post earlier and it sounds like the exact same thing is happening to me.

https://supportforums.cisco.com/docs/DOC-3313

Perhaps the ios team grabbed an old version that still had this bug in it before configuring the 8.4.2.

Oww that's an old bug ... I doubt they grabbed such an old IOS but who knows ...

Lets hope that they read this part   "this is a bug that I can't live with" 

.

Please refer to http://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/118084-configure-anyconnect-00.html

If you are utilizing a setup similar to mine this should resolve your issue.

ANYCONNECT -> INTERNET -> ASA -> DHCP-SERVER

Add the following to your tunnel-group policy

dhcp-server subnet-selection x.x.x.x

x.x.x.x would be the internal DHCP-SERVER's IP address.

If you do not have a RFC 3011/3527 DHCP-SERVER please ensure that your have the "route-lookup" option added to your NAT statement for the vpn subnet ...

Example:  nat (inside,outside) source static obj-inside obj-inside destination static obj-vpnsubnet obj-vpnsubnet no-proxy-arp route-lookup

Andrew Devine
Level 1
Level 1

I can also vouch for this bug, also present in 8.4(3).  Reverted to 8.4(1) and was albe to obtain an IP from the DHCP server.

Hi, I ran into a very similar issue last night, upgrading from 8.4.1 to 8.4.3 on ASA 5540.

Customer uses IPSec VPN client, DHCP on the internal network to supply addresses to the client. Following the upgrade to the working system the client no longer received a DHCP address. If we configured a local pool on the ASA then all worked ok, so I was certain this was something to do with the DHCP set up.

After a TAC call and several hours debugging, this was traced to the way the DHCP proxy function has changed in 8.4.3.

Under the group policy seetings, I'll use the example posted above there is a setting for the DHCP network scope:

group-policy GroupPolicy_MCSO-Offices attributes

dhcp-network-scope 192.168.6.0

I changed this value to the first address in the scope range, in the example above this would be:

group-policy GroupPolicy_MCSO-Offices attributes

dhcp-network-scope 192.168.6.1

The client could then receive its IP address.

As this is a change to the DHCP proxy functionality in the ASA I'd expect this to resolve the problem with Any Connect as well.

This command isnt well documented in the command guide, but it would seem that it needs a real IP address, not a network address.

I'm running into a similar problem.  Using 8.4(4)1 on ASA5510 and cannot get the client to grab the dhcp address from a windows server.  It works fine on 8.4(1).  I have followed the above suggestions.  Any help would be greatly appreciated.

Might not be of much use to you, but I have started downgrading all our ASAs to 8.3(2) until 8.4 becomes more stable, far too buggy at the moment.

Right the local pools works OK, it just does not want to grap an IP from the Windows DHCP server.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: