sslvpn to ipsec tunnel traffic

[ccna_don]

I have an ipsec tunnel on my Cisco ASA 5516-x that I am trying to add the ability of the sslvpn network to traverse. I tried achieving this by using an IP on the local LAN to NAT the sslvpn traffic destined for the remote network so that it appears that the sslvpn traffic is also coming from the allowed local office network. The reason I am doing this is because I have no management access to the other end of the tunnel. I created objects for the sslvpn network and the srcnatIP. I added the new objects to the crypto map and created a NAT. I can see the NAT receiving hits and the access-list however I get a reverse route lookup error when the traffic returns. 

[Cristian Matei]

Hi,

  Since you're NAT'ing the SSLVPN traffic into an IP which is already included in the VPN protected network, i don't see why you would need to do changes on the crypto-map? What needs to be done is:

         - same-security-traffic permit intra-interface

         - nat (outside,outside) 1 source dynamic VPN_POOL_RANGE LAN_IP_TO_NAT_INTO destination static REMOTE_VPN REMOTE_VPN no-proxy-arp

Can you post a packet-tracer output, simulating that traffic?

Regards,

Cristian Matei.

[ccna_don]

fwh-hq-asa# packet-tracer input outside tcp 10.10.1.253 echo 192.168.149.131 e$

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (any,outside) source dynamic n-10.10.0.0_16 InternalNets-to-PH-OverloadNAT destination static PH-Endpoints PH-Endpoints
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.149.131/7 to 192.168.149.131/7

Phase: 2
Type: SUBOPTIMAL-LOOKUP
Subtype: suboptimal next-hop
Result: ALLOW
Config:
Additional Information:
ifc selected is not same as preferred ifc
Doing route lookup again on ifc outside

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 12.150.119.113 using egress ifc outside

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (rpf-violated) Reverse-path verify failed

[Cristian Matei]

Hi,

  Are both of these VPN POOl ranges? AS you simulate traffic in between:

10.10.1.253 and 192.168.149.131

Regards,

Cristian Matei.

[ccna_don]

So I added a global configuration command to the ASA

ASA#same-security-traffic permit intra-interface

I ran another trace using the 10.100.254.138 ip address which is the vpn client machine I am testing from. The packet trace is as follows:

packet-tracer input outside tcp 10.100.254.138 http 192.168.149.13 http

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,outside) source static FWH_sslvpn FWH-sslvpn-srcnat destination static PH-192.168.149.131 PH-192.168.149.131 no-proxy-arp
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.149.131/80 to 192.168.149.131/80

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 12.150.119.113 using egress ifc outside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group FWH_sslvpn in interface outside
access-list FWH_sslvpn extended permit ip any host 192.168.149.131
Additional Information:

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (outside,outside) source static FWH_sslvpn FWH-sslvpn-srcnat destination static PH-192.168.149.131 PH-192.168.149.131 no-proxy-arp
Additional Information:
Static translate 10.100.254.138/80 to 10.10.1.253/80

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

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: SFR
Subtype:
Result: ALLOW
Config:
class-map Sfr-Module
match access-list Cisco-Spark
policy-map global_policy
class Sfr-Module
sfr fail-open
service-policy global_policy global
Additional Information:

Phase: 8
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

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

[ccna_don]

I re-read your first reply again and see what you were saying. I went in and removed the previous nat statement I had in there and made it 

nat (outside,outside) source dynamic FWH_sslvpn FWH-sslvpn-srcnat destination static PH-192.168.149.131 PH-192.168.149.131 It would not allow me to add the no-proxy-arp statement. I also added the - same-security-traffic permit intra-interface

My tracer result is as follows:

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,outside) source static FWH_sslvpn FWH-sslvpn-srcnat destination static PH-192.168.149.131 PH-192.168.149.131 no-proxy-arp
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.149.131/80 to 192.168.149.131/80

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 12.150.119.113 using egress ifc outside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group FWH_sslvpn in interface outside
access-list FWH_sslvpn extended permit ip any host 192.168.149.131
Additional Information:

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (outside,outside) source static FWH_sslvpn FWH-sslvpn-srcnat destination static PH-192.168.149.131 PH-192.168.149.131 no-proxy-arp
Additional Information:
Static translate 10.100.254.138/80 to 10.10.1.253/80

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

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: SFR
Subtype:
Result: ALLOW
Config:
class-map Sfr-Module
match access-list Cisco-Spark
policy-map global_policy
class Sfr-Module
sfr fail-open
service-policy global_policy global
Additional Information:

Phase: 8
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

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

sslvpn subnet: 10.100.254.0/24

sslvpn_srcnatip: 10.10.1.253 (LAN IP reserved for sslvpnNAT)

LAN subnet: 10.10.1.0/24

destination host: 192.168.149.131

[Cristian Matei]

Hi,

   The packet looks to be going through the tunnel. Test it with real traffic, and look in the " show conn long" to see your SSL traffic being NAT'ed.

Regards,

Cristian Matei.

[ccna_don]

I initiated web traffic to the intended destination as well as started a continuous ping but see nothing in my show conn long | incl 10.100.254.47 output. That is my laptop's IP. I see tons of other traffic. Just nothing from my machine. The route is on my machine. dest 192.168.149.131 gateway 10.100.254.1

[Cristian Matei]

Hi,

   Based on the posted NAT configuration from above, i expect that these two objects "FWH_sslvpn  and FWH-sslvpn-srcnat" cotain the IP's of 10.100.254.138 and to 10.10.1.253; while now you're trying to generate traffic from 10.100.254.47, which most probably does not get NAT'ed, which most probably does not match the encryption ACL.

   If you static NAT is just for 10.100.254.138, ensure you always get that IP via VPN.

Regards,

Cristian Matei.

[ccna_don]

Thanks for the help Cristian,

I changed it so that is reflects your NAT statement.

The fwh_sslvpn is (10.100.254.0/24)

The fwh_sslvpn_srcnat (10.10.1.253)

source dynamic fwh_sslvpn fwh_sslvpn_srcnat destination obj-192.168.149.131 

So I have it so that any sslvpn IP address that is destined for 192.168.149.131 is NAT'd to that IP address of fwh_sslvpn_srcnat 

[Cristian Matei]

So does it work?

[ccna_don]

I still cannot get a reply from the host and the website is not reachable. The result of the packet trace is the same as I sent last night. It fails at phase 11. Researched this last night

Phase: 11

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Drop-reason: (acl-drop) Flow is denied by configured rule

Researched and found this response:

This is an annoying error, that is difficult to solve. The reason you are seeing this error is because the ACL that defines the ‘interesting traffic’ for the VPN, does not a MIRROR IMAGE ACL on the OTHER VPN endpoint. As soon as this was rectified the packet-trace ran successfully.

I have no access to the other vpn endpoint and is why I am NAT'ng this traffic to begin with. Any validity to what they mentioned here?

[Cristian Matei]

Hi,

   It pretty much means that the VPN may not be functional. Can you confirm, leaving aside the SSL traffic, that from the LAN you cans end traffic through the VPN tunnel ( from 10.10.1.x to 192.168.149.131)? Can you issue "clear crypto ipsec sa counters", send like 1000 continuous pings in the tunnel and look at "show crypto ipsec sa peer x.x.x.x | i pkts" and actually see those 1000+ packets as encapsulated packets?

Regards,

Cristian Matei.

[ccna_don]

I tested the vpn from a machine on the LAN and the packets are being sent and received with no problem. The url I am trying to get to is also reachable from the LAN. The issue getting to these same resources is not available from the client vpn. Last packet trace failed:

fwh-hq-asa# packet-tracer input outside tcp 10.100.254.145 http 192.168.149.13$

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,outside) source dynamic FWH_sslvpn FWH-sslvpn-srcnat destination static PH-192.168.149.131 PH-192.168.149.131
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.149.131/80 to 192.168.149.131/80

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.100.254.145 using egress ifc outside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group FWH_sslvpn in interface outside
access-list FWH_sslvpn extended permit ip any host 192.168.149.131
Additional Information:

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (outside,outside) source dynamic FWH_sslvpn FWH-sslvpn-srcnat destination static PH-192.168.149.131 PH-192.168.149.131
Additional Information:
Dynamic translate 10.100.254.145/80 to 10.10.1.253/80

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

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: CP-PUNT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: SFR
Subtype:
Result: ALLOW
Config:
class-map Sfr-Module
match access-list Cisco-Spark
policy-map global_policy
class Sfr-Module
sfr fail-open
service-policy global_policy global
Additional Information:

Phase: 9
Type: WEBVPN-SVC
Subtype: in
Result: DROP
Config:
Additional Information:

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

[Cristian Matei]

Hi,

   Perform the packet-tracer function for another IP (10.100.254.145), but ensure it still gets NAT'ed. Or for the same IP, but not when the user is connected and assigned that IP address.

Regards,

Cristian Matei.