cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8402
Views
0
Helpful
15
Replies

AnyConnect Remote DHCP Issue

tim829
Level 1
Level 1

We cannot get AnyConnect VPN clients to retrieve an IP address from our primary DHCP server. If we setup a local pool in the VPN profile the client can connect and gets an IP address fine. I've looked at multiple articles addressing this issue including documentation from Cisco on configuring the VPN to use a remote DHCP server but nothing seems to work. I feel like it might have something to do with a NAT or an ACL blocking the response coming from the DHCP server. The ASA doesn't have an issue communicating with that server though because it's also using it for RADIUS authentication which is working fine.

I ran a debug on the VPN connection and I see this in the output:

cstp_util_address_ipv6_accept: No IPv6 Address
cstp_util_address_ipv4_accept: no address?!?
No assigned address
Not calling vpn_remove_uauth: not IPv4!
webvpn_svc_np_tear_down: no IPv6 ACL

Here is the NAT we are using for the VPN clients:

nat (inside,outside) source static any any destination static NETWORK_OBJ_10.15.65.0_24 NETWORK_OBJ_10.15.65.0_24 no-proxy-arp route-lookup description *DO NOT DELETE* NAT for AnyConnect VPN

Here is the config from webvpn:

webvpn
enable outside
anyconnect image disk0:/anyconnect-macosx-i386-4.2.02075-k9.pkg 1
anyconnect image disk0:/anyconnect-win-4.2.02075-k9.pkg 2 regex "Windows NT"
anyconnect profiles VPN_client_profile disk0:/VPN_client_profile.xml
anyconnect enable
tunnel-group-list enable
cache
disable
error-recovery disable
group-policy DfltGrpPolicy attributes
vpn-tunnel-protocol l2tp-ipsec
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT_VPN_TUNNEL
group-policy GroupPolicy_VPN internal
group-policy GroupPolicy_VPN attributes
wins-server none
dns-server value 172.17.1.1 172.17.2.1
dhcp-network-scope 10.15.65.0
vpn-tunnel-protocol ikev2 ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT_VPN_TUNNEL
default-domain value **********
webvpn
anyconnect profiles value vpn.gwdcity.com_client_profile type user
dynamic-access-policy-record DfltAccessPolicy
username tim.stumbo password VlWsX6rJpka5QVbt encrypted
username tim.stumbo attributes
vpn-group-policy GroupPolicy_VPN
password-storage disable
tunnel-group VPN type remote-access
tunnel-group VPN general-attributes
authentication-server-group RADIUS
default-group-policy GroupPolicy_VPN
dhcp-server 172.17.1.1
tunnel-group VPN webvpn-attributes
group-alias *********** enable

Thanks for the help.

15 Replies 15

Aditya Ganjoo
Cisco Employee
Cisco Employee

Hi Tim,

Could you check the output of :

show run all vpn-addr-assign

It should have this enabled:

vpn-addr-assign dhcp

Also if you take captures on the ASA do you see the DHCP server sending the offer ?

On the ASA you can configure :

Access-list capin permit ip host <asa's inside intf ip> host <dhcp server ip>
Access-list capin permit ip host <dhcp server ip> host <asa's inside intf ip>

Cap capin interface inside access-list capin

Try connecting to anyconnect and check the captures.Also take simultaneous captures on the DHCP server.

Regards,

Aditya 

Please rate helpful posts.

Here is the output you requested, I'm working on the captures now.

asa# show run all vpn-addr-assign
no vpn-addr-assign aaa
vpn-addr-assign dhcp
no vpn-addr-assign local

Tim, 

I'm seeing this issue for a client on an HA pair of ASAs on 9.6(2). Did you ever resolve this? 

Thanks!

kyler

I can't remember what was done to fix the issue. I put in a case and a TAC assisted in getting it resolved. I looked back over the e-mails and the solution wasn't in them. 

It seems like I remember maybe having the VPN subnet somewhere in the config where it wasn't needed. 

I looked in my routing table and noticed the VPN subnet was the only route for all our subnets that wasn't in the table. Look over yours and see if you have it in there, see below example.

Example: route inside 10.15.65.0(VPN DHCP Subnet) 255.255.255.0 172.17.1.250 1


Here's the output of the VPN config on our firewall, hopefully it can help as well.


nat (inside,outside) source static any any destination static NETWORK_OBJ_10.15.65.0_24 NETWORK_OBJ_10.15.65.0_24 no-proxy-arp route-lookup description *DO NOT DELETE* NAT for AnyConnect VPN

no vpn-addr-assign aaa
no vpn-addr-assign local
no ipv6-vpn-addr-assign aaa
no ipv6-vpn-addr-assign local
dhcpd auto_config outside

webvpn
enable outside
anyconnect image disk0:/anyconnect-macosx-i386-4.2.02075-k9.pkg 1
anyconnect image disk0:/anyconnect-win-4.2.02075-k9.pkg 2 regex "Windows NT"
anyconnect profiles vpn.XXXXXXX.com_client_profile disk0:/vpn.XXXXXXXX.com_client_profile.xml
anyconnect enable
tunnel-group-list enable
cache
disable
error-recovery disable
group-policy DfltGrpPolicy attributes
vpn-tunnel-protocol l2tp-ipsec
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT_VPN_TUNNEL
group-policy GroupPolicy_vpn.XXXXXXXX.com internal
group-policy GroupPolicy_vpn.XXXXXXXX.com attributes
wins-server none
dns-server value 172.17.1.1 172.17.2.1
dhcp-network-scope 10.15.65.0
vpn-tunnel-protocol ikev2 ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT_VPN_TUNNEL
default-domain value XXXXXXXXX
webvpn
anyconnect profiles value vpn.XXXXXXX.com_client_profile type user
dynamic-access-policy-record DfltAccessPolicy
username tim.stumbo password XXXXXXXXXXXXXXXXX encrypted
username tim.stumbo attributes
vpn-group-policy GroupPolicy_vpn.XXXXXXX.com
password-storage disable
tunnel-group vpn.XXXXXXXcom type remote-access
tunnel-group vpn.XXXXXXX.com general-attributes
authentication-server-group RADIUS
default-group-policy GroupPolicy_vpn.XXXXXXXX.com
dhcp-server 172.17.1.1
tunnel-group vpn.XXXXXXX.com webvpn-attributes
group-alias vpn.XXXXXXXX.com enable
!

Hey Tim, 

Thanks for getting back to me! We escalated to tier3 of TAC, and each engineer validated our dhcp, tunnel-group and webvpn configs. 

In the end, we rebooted the ASA and it resolved the issue. I'm not confident in the fix, because a simple failover between HA pairs didn't resolve it. 

The ASAs are 5525Xs on 9.6(2), and our TAC engineer informed us that this bug is not confirmed resolved within TAC even on the newest versions of 9.6(x) or on 9.7(x). 

Good luck out there. 

kyler

Here's the capture:

1: 20:04:45.948101 172.17.1.254.67 > 172.17.1.1.67: udp 548
2: 20:05:16.348843 172.17.1.254.28686 > 172.17.1.1.1645: udp 591
3: 20:05:16.351010 172.17.1.1.1645 > 172.17.1.254.28686: udp 78
4: 20:05:22.547991 172.17.1.254.67 > 172.17.1.1.67: udp 548
5: 20:05:25.538119 172.17.1.254.67 > 172.17.1.1.67: udp 548
6: 20:05:29.538119 172.17.1.254.67 > 172.17.1.1.67: udp 548
7: 20:05:34.538103 172.17.1.254.67 > 172.17.1.1.67: udp 548
8: 20:05:35.018401 172.17.1.254.67 > 172.17.1.1.67: udp 548
9: 20:05:38.018141 172.17.1.254.67 > 172.17.1.1.67: udp 548
10: 20:05:42.018157 172.17.1.254.67 > 172.17.1.1.67: udp 548
11: 20:05:47.018141 172.17.1.254.67 > 172.17.1.1.67: udp 548
12: 20:05:47.498387 172.17.1.254.67 > 172.17.1.1.67: udp 548
13: 20:05:50.498127 172.17.1.254.67 > 172.17.1.1.67: udp 548
14: 20:05:54.498127 172.17.1.254.67 > 172.17.1.1.67: udp 548
15: 20:05:59.498127 172.17.1.254.67 > 172.17.1.1.67: udp 548
16: 20:05:59.978342 172.17.1.254.67 > 172.17.1.1.67: udp 548
17: 20:06:02.978098 172.17.1.254.67 > 172.17.1.1.67: udp 548
18: 20:06:06.978114 172.17.1.254.67 > 172.17.1.1.67: udp 548
19: 20:06:11.978114 172.17.1.254.67 > 172.17.1.1.67: udp 548

The RADIUS request is getting back to the firewall for authentication but not the DHCP request.

Thanks

I've also referenced this article which states it's a routing issue, looks to be about the exact same problem.

http://www.petenetlive.com/KB/Article/0001053

Thanks

Hi Tim,

I am not sure about the topology of your network.

But if it is similar we can try the same.

If the offer does not reach the ASA we need to check the internal routing.

Regards,

Aditya

Please rate helpful posts.

I guess my question is that the ASA is communicating with the same server for RADIUS authentication fine, so it would seem like it's not a routing issue because that's communicating fine. 

Anything else you can think of to help me with this issue?

Thanks

Hi Tim,

Apologies as I was not able to look into this.

Can you try taking asp captures on ASA ?

capture asp type asp-drop all 

Filter it on the basis of the DHCP server IP.

Sh cap asp | in <DHCP-server IP>

Make sure you remove the capture.

Also could you remove this NAT statement and put it on line 1:

no nat (inside,outside) source static any any destination static NETWORK_OBJ_10.15.65.0_24 NETWORK_OBJ_10.15.65.0_24 no-proxy-arp route-lookup description *DO NOT DELETE* NAT for AnyConnect VPN

nat (inside,outside) 1 source static any any destination static NETWORK_OBJ_10.15.65.0_24 NETWORK_OBJ_10.15.65.0_24 no-proxy-arp route-lookup description *DO NOT DELETE* NAT for AnyConnect VPN

Regards,

Aditya

Please rate helpful posts.

I turned on the capture above while trying to connect to the VPN, I filtered the results and didn't have any entries for the DHCP server 172.17.1.1

Hi Tim,

This means the ASA is not dropping the traffic.

What about the NAT reordering ?

Regards,

Aditya

I did that as well but it didn't seem to make a difference.