Hi all,
I'm working on a PoC utilizing an FTD virtual appliance for Anyconnect VPN connectivity; the customer is wanting to migrate from legacy ASA to FPWR and I thought this should be a relatively easy migration, though it's proven to be more challenging than I expected.
The actual topology is a pretty vanilla 3-legged appliance deployment with inside, outside, and DMZ zones/interfaces. The inside consists of a routed /30 transit network between the FTDv and an SVI terminating on a 3560-X L3 switch (the 3560-X switch has a handful of network segments on the inside that I'm utilizing basic static routing for reachablility).
The VPN configuration is a full-tunnel deployment (SSL only no DTLS), with RADIUS + X.509 for the AAA backended with an ISE 2.6 virtual appliance and a Windows Server 2016 VM running the AD, DNS/DHCP, CA, and OCSP responder roles installed. The dual auth is working as intended, as the VPN client does connect and is assigned an IP address from the correct DHCP pool on the Windows server.
That's where the PoC success more or less ends; once connected, the client is unable to access any resources either inside or outside the perimeter of the secure network.
I thought perhaps my NAT policy was missing something, however I've gone over it a million times and it's bitwise identical to the known working configuration on the ASA that I've always used and have never had an issue with.
Inside subnets (top 3 rules) --> VPN Client subnet == NO NAT (Manual static NAT exemption)
VPN Client subnet --> VPN Client subnet == NO NAT (Manual static NAT exemption)
VPN Client subnet --> Internet == Hairpin interface PAT on the outside (After-auto)
I also reviewed the Access Control policy and am logging the default rule (set to block all communications) for any sign of the AC policy dropping the traffic, and I'm not using the sys-opt vpn bypass, so my Access Control policy has specific permit statements to allow the ingress / egress traffic both to the internal hosts, as well as to the Internet. I also have a Null0 route configured for the VPN client subnet and uRPF enabled as per best practives for VPN deployment, and I do see the explicit /32 host routes in the RIB on the FTDv when the client connects.
When I do a Capture w/Trace in full tree view, the traffic is passing all of the requisite checks and is being allowed by AC, NAT, inspection, SNORT, IP-Options, etc.
Thinking perhaps it was something possibly routing / L3 related, I attempted to simply ping the VPN client by it's private address FROM the FTDv appliance, however even this times out (although I can see the RX counter increment on the client with each successive ping from the FTDv).
This isn't platform specific for the clients, as the behavior is identical on a Mac, Windows, and iOS client platform.
For reference, the software in use is FMCv / FTDv 6.4.0.8 on an ESXi 6.5 U3 host, with AnyConnect 4.8.02045 on the Mac/Win platforms, and whatever the latest AnyConnect iOS client version is today.
I would be very interested to know if any of the community folks have encountered similar behavior and what would need to be done to correct it? I haven't tried building this on a physical FTD as I don't have one handy for sandbox / dev work at the moment, and I don't see this being a hypervisor or switching issue as the traffic does seem to be passing through the FTDv.