Issue
The goal is to enable full access for VPN users to internal network resources after successful VPN authentication using RADIUS (against a Windows domain-joined server) on Cisco Secure Firewall FTD.
The VPN setup is already operational; users can download and install the VPN client and authenticate successfully. The issue is focused on configuring the necessary access control and NAT rules to permit the required internal resource access over the VPN.
Environment
- Product: Cisco Secure Firewall Firepower (FTD), version 7.6.0 (such as a CSF1220CX appliance)
- Management: Firepower Management Center (FMC), cloud-delivered FMC (cdFMC), or Firepower Device Manager (FDM)
- VPN: Configured with RADIUS authentication against a Windows domain-joined server (NPS)
- VPN Address Pool: 192.168.250.1 - 192.168.250.200
- Target Internal Subnet Example: 192.168.95.0/24
- Software Version: 9.22.1 (as referenced in workflow)
- Relevant interfaces: 'outside' interface for VPN ingress
- RDP and Active Directory access required over VPN connection
Resolution
These steps detail the configuration required to permit VPN users to access internal resources (such as RDP and Active Directory) on Cisco FTD. This includes creating access policy rules, configuring NAT exemptions and hairpin NAT for VPN traffic, and using troubleshooting commands to validate the configuration.
Step 1: Add an access-list entry to allow the VPN address pool to access internal resources.
access-list CSM_FW_ACL_ advanced permit ip object VPN_Pool any rule-id 268438528
access-list CSM_FW_ACL_ remark rule-id 268438528: ACCESS POLICY: Default Access Control Policy - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268438528: L7 RULE: Permit_VPN_Pool
Step 2: Add an access-list rule to allow internal resources to send return traffic to the VPN pool:
access-list CSM_FW_ACL_ advanced permit ip any object VPN_Pool
These rules can later be tightened to restrict specific sources and destinations as needed.
Step 3: Configure NAT Exemption or Hairpin NAT for VPN Traffic
There are two common approaches:
- Option A: NAT Exemption for VPN Pool to Internal Subnet
nat (outside,inside) source static VPN_Pool VPN_Pool destination static Net_192.168.95.1-24 Net_192.168.95.1-24 route-lookup
- Option B: Hairpin NAT for VPN Pool on Same Interface (no-proxy-arp)
nat (any,any) source static VPN_Pool VPN_Pool no-proxy-arp
- Option C: Dynamic Hairpin NAT for VPN Pool on Outside Interface
nat (outside,outside) dynamic VPN_Pool interface
The correct method depends on whether internal resources are on the same physical interface (requiring hairpin NAT) or different interfaces (NAT exemption).
Step 4: Use the packet-tracer command to simulate traffic flows from the VPN pool to internal resources and validate if the traffic is permitted by the intended rule, NAT, and route.
packet-tracer input outside icmp 192.168.250.1 8 0 192.168.95.1
packet-tracer input outside tcp 192.168.250.1 12345 192.168.95.1 80
packet-tracer input inside icmp 192.168.95.1 8 0 192.168.250.1
packet-tracer input inside tcp 192.168.250.1 54321 192.168.95.1 443
--
Phase 5
ID: 5
Type: ACCESS-LIST
Result: ALLOW
Config: access-group CSM_FW_ACL_ globalaccess-list CSM_FW_ACL_ advanced permit ip object VPN_Pool any rule-id 268438528 access-list CSM_FW_ACL_ remark rule-id 268438528: ACCESS POLICY: Default Access Control Policy - Mandatoryaccess-list CSM_FW_ACL_ remark rule-id 268438528: L7 RULE: Permit_VPN_Pool
Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached Forward Flow based lookup yields rule: in id=0x40009d6ae190, priority=12, domain=permit, deny=false hits=1300, user_data=0x0000000000000000, cs_id=0x0, use_real_addr, flags=0x0, protocol=0 src ip/id=240.0.0.0, mask=255.255.255.255, port=0, tag=any, ifc=any dst ip/id=240.5.0.2, mask=255.255.255.255, port=0, tag=any, ifc=any, dscp=0x0, input_ifc=any, output_ifc=any
Elapsed Time: 0 ns
--
Phase 7
ID: 7
Type: NAT
Result: ALLOW
Config: nat (outside,outside) dynamic VPN_Pool interface
Additional Information: Static translate 192.168.250.1/12345 to 192.168.250.1/12345 Forward Flow based lookup yields rule: in id=0x40009d6ad0a0, priority=6, domain=nat, deny=false hits=274, user_data=0x000040009963a2d0, cs_id=0x0, flags=0x0, protocol=0 src ip/id=192.168.250.1, mask=255.255.255.255, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dscp=0x0, input_ifc=any, output_ifc=any
Elapsed Time: 0 ns
Note: The packet-tracer output for the WebVPN phase could show a "DROP" for VPN traffic on the outside interface. This is expected behavior for plain text traffic on the outside interface and can still be used to validate NAT.
Additional Notes:
- It is possible that packet captures in the Threat Defense UI only show incoming requests. If no drops are observed, but the traffic does not reach the internal resource, check NAT and access-list rules.
- When SSH is not available, all troubleshooting can be performed via the Threat Defense UI features in cdFMC, but command usage is limited.
- It is possible that some modifications are needed on adjacent devices for end-to-end connectivity.
Cause
The root cause was insufficient access policy and NAT configuration for VPN-to-internal and internal-to-VPN pool traffic. The default configuration did not allow for full bidirectional communication from the VPN pool to internal resources and back, nor did it handle hairpin NAT requirements for traffic ingressing and egressing on the same interface.
Related Content
Feedback