03-10-2016 11:06 AM - edited 02-21-2020 08:43 PM
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.
03-10-2016 11:51 AM
Hi Tim,
Could you check the output
show run all vpn-addr-assign
It should have this enabled:
vpn-addr-assign dhcp
On the ASA you can
Access-list
Access-list
Cap
Try connecting to anyconnect and check the captures.Also take simultaneous captures on the DHCP server.
Regards,
Aditya
Please rate helpful posts.
03-10-2016 11:56 AM
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
05-11-2017 09:34 AM
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
05-12-2017 11:33 AM
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
!
05-13-2017 08:39 AM
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
03-10-2016 12:07 PM
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
03-10-2016 12:12 PM
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
03-10-2016 12:18 PM
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.
03-10-2016 12:23 PM
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.
03-14-2016 11:15 AM
Anything else you can think of to help me with this issue?
Thanks
03-14-2016 11:26 AM
Hi Tim,
Apologies as I was not able to look into this.
Can you try taking
capture
Filter it on the basis of the DHCP server IP.
Sh cap asp | in <DHCP-server IP>
Make sure you remove the capture.
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.
03-14-2016 12:00 PM
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
03-14-2016 12:11 PM
Hi Tim,
This means the ASA is not dropping the traffic.
What about the NAT reordering ?
Regards,
Aditya
03-14-2016 12:13 PM
I did that as well but it didn't seem to make a difference.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide