RA VPN FTD 6.2.3 - No SSL Connection

[ssambourg]

Hello,

I am configuring a new RA VPN Policy on FTD 6.2.3 software based on 2 x ASA 5500-X hardware.

I have two ISP connection with SLA monitor for route tracking. 

At first I made the configuration for the Security Zone (include my two ISP) and no result.

Then, I delete this configuration and create another one with an interface group which contains only the first ISP connection. For each case my problem is :

When connecting to https://public_ip : no SSL error, no connection, only a timeout.

I attach some screenshot of my RA VPN Policy.

Some CLI outputs :

show webvpn group-alias
Tunnel Group: VPN-********* Group Alias: VPN-********* enabled

show webvpn statistics
Total number of objects served 0
html 0
js 0
css 0
vb 0
java archive 0
java class 0
image 0
undetermined 0
Server compression statistics
Decompression success from server 0
Unsolicited compression from server 0
Unsupported compression algorithm used by server 0
Decompression failure for server responses 0

interface Port-channel1.220
vlan 220
nameif OUTSIDE-NOMINAL1
cts manual
propagate sgt preserve-untag
policy static sgt disabled trusted
security-level 0
ip address 46.X.X.X 255.255.255.240

webvpn
enable OUTSIDE-NOMINAL1
anyconnect image disk0:/csm/anyconnect-linux64-4.6.03049-webdeploy-k9.pkg 1 regex "Linux"
anyconnect image disk0:/csm/anyconnect-macos-4.6.03049-webdeploy-k9.pkg 2 regex "Mac OS"
anyconnect image disk0:/csm/anyconnect-win-4.6.03049-webdeploy-k9.pkg 3 regex "Windows"
anyconnect enable
tunnel-group-list enable
cache
no disable
error-recovery disable

group-policy POLICY-VPN-**** attributes
banner none
wins-server value 172.30.X.X 172.30.X.X
dns-server value 172.30.X.X 172.30.X.X
dhcp-network-scope none
vpn-simultaneous-logins 3
vpn-idle-timeout 30
vpn-idle-timeout alert-interval 1
vpn-session-timeout none
vpn-session-timeout alert-interval 1
vpn-filter none
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelspecified
ipv6-split-tunnel-policy tunnelspecified
split-tunnel-network-list value ACL-*********
default-domain value ***********
split-dns none
split-tunnel-all-dns enable
client-bypass-protocol disable
vlan none
address-pools value POOL-VPN

webvpn
anyconnect ssl dtls enable
anyconnect mtu 1406
anyconnect firewall-rule client-interface public none
anyconnect firewall-rule client-interface private none
anyconnect ssl keepalive 20
anyconnect ssl rekey time none
anyconnect ssl rekey method none
anyconnect dpd-interval client 30
anyconnect dpd-interval gateway 30
anyconnect ssl compression none
anyconnect dtls compression none
anyconnect modules value dart
anyconnect ask none default anyconnect
anyconnect ssl df-bit-ignore disable

I don't see what's wrong with my SSL port <> SSL VPN on this interface. Someone already encounter this behavior ? Any advice ?

[Marvin Rhoads]

That looks pretty much correct.

You don't happen to have any server also NATted to the outside interface with an incoming ACP allowing tcp/443 do you? That could take up the port number used by the VPN.

You can check the listening ports from the FTD cli with "show asp table socket | include 443".

[ssambourg]

Hello Marvin,

I don't have any NAT on this public IP.

The socket seems to be OK for my outside public IP and correctly in a listen state :

Cisco Fire Linux OS v6.2.3 (build 13)
Cisco ASA5516-X Threat Defense v6.2.3.6 (build 37)

> show asp table socket | include 443
SSL 010102d8 LISTEN 46.X.X.X:443 0.0.0.0:*
DTLS 00019b48 LISTEN 46.X.X.X:443 0.0.0.0:*

But no chance when I https my public IP from Internet (timeout).

If my understanding is correct, NAT on tcp/443 + incoming permit in ACP on this public IP tcp/443 take up the 443 configured in the RA VPN Policy ?

And If so, my socket table won't show SSL & DTLS process in LISTEN state on my public IP:443 ?  Or a debug of events on the public IP / tcp/443 ?

That's very strange. Is there a CLI that permit to check a NAT on this public IP tcp/443 ?

[Marvin Rhoads]

Your sockets indeed look ok. The ASA running TFD should be listening on tcp/443 for the Remote Access SSL VPN traffic.

You did mention you have two ISPs. Make sure the address you are testing is the one that is also handling the default route to the Internet.

You can run a packet capture for traffic from your test computer. Capture on the active ISP interface filtering on your PCs public address.

[ssambourg]

Yes the routing table correctly show the ISP I targeted:

> show route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 46.X.X.X to network 0.0.0.0

S* 0.0.0.0 0.0.0.0 [5/0] via 46.X.X.X, OUTSIDE-NOMINAL

[...]

From a packet-capture, I saw incoming packets. But two things are not expected:

- UN-NAT allow from DMZ to Outside

- ACP deny (result of unwanted NAT to egress interface DMZ)

1: 07:09:52.072887 802.1Q vlan#220 P0 88.X.X.X.12345 > 46.X.X.X.443: S 3920575806:3920575806(0) win 65535 <mss 1420,sackOK,timestamp 8648352 0,nop,wscale 8>

[...]

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (DMZ,OUTSIDE-NOMINAL) source static DMZ interface
Additional Information:
NAT divert to egress interface DMZ
Untranslate 46.X.X.X/443 to 192.168.2.0/443

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268434432 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: **********-ACC-POLICY - Default
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:

Result:
input-interface: OUTSIDE-NOMINAL
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

So packets are UN-NATED to DMZ interfaces but no rule permit that (which make sense).

When looking into the NAT configured rules, I saw:

> show running-config nat

!Outgoing NAT from DMZ and INSIDE zones

nat (DMZ,OUTSIDE-BACKUP) source static DMZ interface
nat (DMZ,OUTSIDE-NOMINAL) source static DMZ interface

!it seems I matched this rule from the packet capture output but don't know why because my traffic comes from OUTSIDE to OUTSIDE.
nat (INSIDE,OUTSIDE-BACKUP) source static any interface
nat (INSIDE,OUTSIDE-NOMINAL) source static any interface

!Incoming NAT from Any to published web resources

nat (OUTSIDE-BACKUP,DMZ) source static any any destination static SRVEXTRANET-Public SRVEXTRANET
nat (OUTSIDE-NOMINAL,DMZ) source static any any destination static SRVEXTRANET-Public SRVEXTRANET
nat (OUTSIDE-BACKUP,DMZ) source static any any destination static ADFS-PROXY1-PUBLIQUE SRVADFSProxy1
nat (OUTSIDE-NOMINAL,DMZ) source static any any destination static ADFS-PROXY1-PUBLIQUE SRVADFSProxy1
nat (OUTSIDE-BACKUP,DMZ) source static any any destination static ADFS-PROXY2-PUBLIQUE SRVADFSProxy2
nat (OUTSIDE-NOMINAL,DMZ) source static any any destination static ADFS-PROXY2-PUBLIQUE SRVADFSProxy2
nat (any,any) source static VPN_****_SSL VPN_****_SSL destination static all all description No Nat Rule for VPN SSL traffic

I checked all the object in DMZ Incoming NAT rules and no one match the ISP public IP address.

So I don't really understand why UN-NAT matches from DMZ to OUTSIDE.

I added no NAT rules from Any to my Outside public IP and now my capture is OK and from my test laptop browser too:

[...]

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 46.X.X.X using egress ifc identity

Phase: 4
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 46.X.X.X using egress ifc identity

[...]

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

[...]

Phase: 9
Type: CLUSTER-REDIRECT
Subtype: cluster-redirect
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: TCP-MODULE
Subtype: webvpn
Result: ALLOW
Config:
Additional Information:

[...]

New flow created with id 35556635, packet dispatched to next module

Result:
input-interface: OUTSIDE-NOMINAL
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
Action: allow

I don't see what I missed after reviewing my first NAT config and why it matched the OUTSIDE to OUTSIDE flow ?

[Marvin Rhoads · Accepted solution]

The NAT rule:

nat (DMZ,OUTSIDE-NOMINAL) source static DMZ interface

...will definitely give the problem you are seeing. If you make that a dynamic (vs. static) NAT I believe it should allow the SSL VPN to use tcp/443.

Otherwise the ASA things that all incoming tcp and udp ports should be untranslated to the host in the DMZ. As you observed, that will be the behavior even without an inbound ACL/ACP entry.