2

Backstory: I have a site to site VPN from my ASA with 9.x firmware to a remote ASA with 8.2 firmware (NOT managed by me). We got the tunnel up and running quite a while ago, I ended up having to specifically add an ACL for ICMP.

The Problem: The other end provides AnyConnect SSL VPN connectivity and users connecting to the SSL VPN need access to my end of the site to site VPN, so I added to the existing subnets.

The Error:Running packet tracer from 10.10.10.5 destination: 192.168.99.5 I get:

VPN: Type -
VPN
Subtype -
encrypt
Action -
DROP

RESULT: The packet is dropped INFO: (acl-drop) Flow is denied by configured rule

Networking info:

  • My site=10.10.10.0/24
  • Other site=10.1.0.0/16
  • SSL VPN=192.168.99.0/24

The changes that I've made (added):

access-list VPN_ACCESS extended permit icmp 10.10.10.0 255.255.255.0 192.168.99.0 255.255.255.0
access-list VPN_ACCESS extended permit ip 10.10.10.0 255.255.255.0 192.168.99.0 255.255.255.0

And based upon this rule:

nat (inside,outside) source static LocalLAN LocalLAN destination static DM_INLINE_NETWORK_3 DM_INLINE_NETWORK_3

I also added added:

object-group network DM_INLINE_NETWORK_3 network-object object REMOTESSLVPN

object network REMOTESSLVPN  subnet 192.168.99.0 255.255.255.0

......

So, am I crazy, or shouldn't that work? What could I be missing? I recall that the initial setup between the sub 8.2 and the >8.3 firmware was a lot of trouble, but this should be simple. Does anyone have any insight?

EDIT: Here's the detailed packet trace from cli:

(config)# packet-tracer input inside tcp 10.10.10.0 80 192.168.99.0 $

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static LocalLAN LocalLAN destination static > > DM_INLINE_NETWORK_3 DM_INLINE_NETWORK_3
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.99.0/80 to 192.168.99.0/80

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (sp-security-failed) Slowpath security checks failed
  • Does the other site allow traffic from your site to the new networks, and vice versa? – Ron Maupin Aug 24 '16 at 14:25
  • SSL VPN=192.168.99.0/16 ==> I assume this should be /24 ? And as Ron mentioned, does the ACL on your inside interface allow the traffic ? – hertitu Aug 24 '16 at 14:31
  • Can you provide output of the same packet-tracer command but this time with the "detailed" option please? – hertitu Aug 24 '16 at 15:44
  • @Ron Maupin, Yes, the other end added an ACL, the other tech says that his packet tracer shows success. – bittrekker Aug 25 '16 at 12:45
  • @hertitu yes, thank you, it is /24, I fixed it. Ah... as far as ACLs, only the one's I've noted above. Oddly enough, they don't show up in my asdm. Adding the detailed packet trace – bittrekker Aug 25 '16 at 12:57
2

On the ASA running the version 8.2 code, there are a few potential issues. The first is the SSL VPN could be setup for split tunneling and they would need to add your subnet in the split tunnel list.

Second is the SSL VPN connects to the outside interface as well as your site to site VPN. They will need to permit hair pinning on the outside interface by issuing this command on the remote ASA

same-security-traffic permit intra-interface.

The third is the NAT exemption. They may need to do something like this on the remote ASA

static (outside,outside) 192.168.99.0 192.168.99.0 netmask 255.255.255.0.

If this doesn't work I would verify the remote end's crypto ACL and make sure the SSL VPN subnet is specified and that routing to the SSL VPN subnet is added to your router.

Josh

  • While all of this is correct, it does not explain the drop action in the packet tracer. – hertitu Aug 27 '16 at 22:35
  • ...nvm, sh routes doesn't show routes for the other end either way. I'll check with the other tech. – bittrekker Aug 29 '16 at 14:51
  • Wait, you make a good point about the NAT exemption, I think I had to do something similar. I'll let you know. – bittrekker Aug 29 '16 at 15:03
  • Yep, other end is u-turning correctly. I'm still convinced that this is on my end given the packet tracer output. I tried rebooting my firewall hoping that re-establishing the vpn on boot would allow the second subnet via the vpn acl – bittrekker Aug 30 '16 at 14:35
  • OK, just noticed that every time I try to ping the 192.168.99.x subnet, I get this in the logs every time, can someone translate what it means? •Tunnel Manager dispatching a KEY_ACQUIRE message to IKEv1. Map Tag = outside_map. Map Sequence Number = 1. •IKEv2 Doesn't have a proposal specified •Group = 206.x.x.x, IP = 206.x.x.x, IKE Initiator: New Phase 2, Intf outside, IKE Peer 206.x.x.x local Proxy Address 10.10.10.0, remote Proxy Address 192.168.99.0, Crypto map (outside_map) •Group = 206.x.x.x IP = 206.x.x.x, Received non-routine Notify message: Invalid ID info (18) – bittrekker Aug 30 '16 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.