01-11-2023 05:46 AM
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,
Solved! Go to Solution.
02-16-2023 11:31 AM
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.
01-11-2023 09:17 AM
can I see the topology, how DHCP server connect to FTD.
can I see the config ?
01-11-2023 09:37 AM
When you say config what parts are you looking for, anything in specific? CLI or SS from FMC?
Thanks
01-11-2023 10:46 AM
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 ?
01-11-2023 09:49 AM
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.
01-11-2023 12:10 PM
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.
01-11-2023 12:18 PM
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
01-11-2023 12:35 PM
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
01-11-2023 12:56 PM
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
01-11-2023 01:24 PM
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.
01-11-2023 01:30 PM
DHCP scope needed. add it and I hope this solve your issue.
01-11-2023 01:39 PM
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.
01-12-2023 12:54 AM
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.
01-12-2023 05:41 AM
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.
01-12-2023 12:47 AM
The IP Helper is not needed here, the FTD is the Relay-Agent.
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