cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2917
Views
25
Helpful
16
Replies

DHCP Issues with Anyconnect

dcanady55
Level 3
Level 3

Hello,

I upgraded one of my FTDs from 7.0.2 to 7.2.2, and afterwards, when testing VPN, I couldn't get in. After some troubleshooting, I determined that I wasn't receiving an IP address from our internal DHCP server. I setup a local pool on the FTD as a workaround. I have since used Wireshark and saw the discover packets hitting the server, but there's no response. I have restarted services multiple times and rebooted the server with no luck. There's no error in any of the logs I've searched, and I deleted my scope and rebuilt. I have another FTD that points to this same DHCP server, and it's working just fine except that it's still on 7.0.2. Both the DHCP and FTD in question can communicate, as nothing has changed from my original configurations. I'm stuck right now and wondering if there's anything on the FMC or FTD that I'm overlooking. 

Thanks, 

1 Accepted Solution

Accepted Solutions

dcanady55
Level 3
Level 3

I wanted to follow up my last post as its been awhile. TAC told me we were running into a SSL bug causing the crash even though we were not using this feature. I have since upgraded to 7.3 as TAC informed me that 7.3 doesn't address the issue head on but they have not seen reports of this bug. I upgraded this past Monday and we have not had any random reboots thus far and my DHCP issue was resolved in 7.3. 

 

View solution in original post

16 Replies 16

can I see the topology, how DHCP server connect to FTD.
can I see the config ?

When you say config what parts are you looking for, anything in specific? CLI or SS from FMC? 

Thanks

CLI of FMC 
and please share the topology, are the DHCP server connect directly to INside or there is L3 between DHCP server and FTD ?

I had the same problem on the ASA in one of the 9.12 versions. Something changed on the handling with DHCP on the upgrade but I didn't have time to figure it out and I didn't find anything relevant in the RN and config guides. It's time to capture the two different discovers and compare them what is different in these two ASA/FTD versions.

Karsten,

I went through both a good and bad capture and discovered 3 items that need some more research.

1. Under the DHCP section and Relay agent IP it looks like this. "Relay agent IP address: 10.1.1.0 (10.1.1.0)" this is on the FTD that's having issues vs the good FTD doesn't have the extra IP inside the parenthesis (). 

2. Same scenario for source address under the IPv4 section bad FTD has "source address: 10.1.1.1 (10.1.1.1) and the good FTD doesn't have the extra IP inside the parenthesis again ()

3. I don't think this one matters, but I will post it anyways, as I do find it odd, but the mac addresses are the same. On the good FTD inside the Ethernet frame, the destination shows VMware_X:X:X (mac address), and the bad FTD cap shows destination to be the actual server name example DC1.test.local (mac address). I find this one odd because the name on the bad FTD cap is what I would expect to see on both captures. Since both Mac addresses are the same, I'm not overly concerned, but it must be something quirky within VM but I'm not a server guy. 

 

Yes I think this is issue here, 
the relay agent and IP address of DHCP packet source, 
but still I need to see the topology 

There are quite a few items between the FTD box and the actual DHCP server. This is our backup FTD at the backup datacenter, so it's going through FTD-Core Switch-WAN Rtr-through our WAN over to another WAN Rtr-L3 switch, and finally the DHCP server. Again, there is connectivity, and all my routing checks out, as I have double checked this. The client mac address inside the DHCP section is that of the inside interface of the FTD, just like it is on my good FTD, so I don't believe this is any kind of routing issue.  HTH 

you need IP helper in L3SW receive the DHCP discover message from FTD 
also are you config DHCP-scope ??
for more info. please check this link

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215854-configure-anyconnect-vpn-client-on-ftd.html

I will look the doc over but remember everything was already working prior to my upgrade as I've already made all the necessary steps for DHCP to flow through the network and back to the FTD. The one thing I have not tried which I'm doing now is blow away all DHCP settings on my AnyConnect profile on the FMC and rebuild those. I will let you know if that does anything. 

DHCP scope needed. add it and I hope this solve your issue. 

That did nothing. I will blow away the entire profile once and setup from scratch over the weekend and report back if I don't resolve it before then. 

I just tried to replicate the Issue on my FTD but it directly worked. This is the config that I ended up with:

tunnel-group DefaultWEBVPNGroup general-attributes
 address-pool POOL-56-32
 authentication-server-group ISE
 accounting-server-group ISE
 dhcp-server 10.255.192.101
 dhcp-server 10.255.192.102

 I still have a pool in my tunnel-group, but the Client IP didn't came from this pool, it's from my DHCP server.

group-policy DfltGrpPolicy attributes
 dhcp-network-scope 10.255.56.41

 My session shows an IP of 10.255.56.41 which is the one I see as a lease in the Windows 2019 DHCP-server:

SSL-Tunnel:
  Tunnel ID    : 16.2
  Assigned IP  : 10.255.56.41           Public IP    : 81.62.223.179
  Encryption   : AES-GCM-128            Hashing      : SHA256
  Ciphersuite  : TLS_AES_128_GCM_SHA256
  Encapsulation: TLSv1.3                TCP Src Port : 52465
  TCP Dst Port : 444                    Auth Mode    : userPassword
  Idle Time Out: 30 Minutes             Idle TO Left : 22 Minutes
  Client OS    : Mac OS X
  Client Type  : SSL VPN Client
  Client Ver   : Cisco AnyConnect VPN Agent for Mac OS X 5.0.01242
  Bytes Tx     : 6780                   Bytes Rx     : 0
  Pkts Tx      : 1                      Pkts Rx      : 0
  Pkts Tx Drop : 0                      Pkts Rx Drop : 0

 What is different ... I am running FTD 7.3 because I wanted to have TLS1.3 support and not version 7.2.x.

Thank you for that. If rebuilding the profile doesn't help, I will jump to 7.3, but I typically don't like to be on the latest software. I did discover that the information in my discover packet inside the () is normal because I had name resolution enabled. I was looking at the pcaps on separate PCs, so when comparing them on the instance of Wireshark that I captured them, both are exactly the same.

The IP Helper is not needed here, the FTD is the Relay-Agent.