GETVPN causing some applications to fail

[mjtabbara]

Hi guys,

On one of our customers is using GETVPN between different sites.

We have 2 KS and several GMs.

This was implemented 3 to 4 month back and it was working 100% fine. There were no issues with any of the applications running between his sites.

3 weeks back, and without applying and changes, some of the applications (but not all), which were already running with no issues between sites, stopped working.

The dilemma is that once we stop the GETVPN these applications start working normally as before. Then if we re-enabled GETVPN these applications stop working!

Any useful subjections or thinks to check for?

Thanks and best regards

Mohammad Jamal Tabbara

CCIE R&S# 24487

[Collin Clark]

What are the applications that stop working?

[mjtabbara]

They are bank applications.

As a result of that we disabled GETVPN since these application are very critical to the bank, which means that these critical information are not secure right now!!

[Collin Clark]

Are they real-time applications? Can you post the relevant config from your KS?

[Jason Gervia]

Mohammad,

Make sure that the crypto ACL is bidirectional for ever entry, ie:

permit tcp 10.0.0.0 0.255.255.255 11.0.0.0 0.255.255.255 eq 23

permit tcp 11.0.0.0 0.255.255.255 eq 23 10.0.0.0 0.0.0.255

And that it's present on both sides.

Otherwise, I would push out a deny ip any any in your crypto ACL to essentially turn off encryption, and slowly turn it back on (by inserting lines prior to your deny ip any any) for particular subnets (keeping the above rules in mind) until it 'breaks' so you can see exactly what flow is broken.

Do you get any syslog messages about packets that should have been encrypted but weren't, or were encrypted but shouldn't have been?

--Jason

[Collin Clark]

Jason, just as an FYI this is GETVPN which is very different from traditional IPSec VPN's. There is only one ACL that is configured for encryption (on the KS) and it gets pushed out to all the GMs.

[Jason Gervia]

Collin,

Thanks.

As the team lead for the RTP VPN TAC team, I'm pretty aware of what GETVPN is.

--Jason

[Collin Clark]

Great then I'll back off and you can help. Sorry to have stepped on a Cisco employees toes.

[Jason Gervia]

LOL,

No worries.  No toes were stepped on.

What I was talking about above was the following:

1)  customers frequently don't have the reverse ACL (they encrypt 10 --> 11 but not 11 --> 10)

2)  There are platform differences in interpreting the crypto ACL (between ASR and ISR) that would cause #1 to be even more important

3)  Checking both sides would hopefully reveal if they're getting the policy correctly (maybe they have COOP KS and are getting different policies?)  and also see if there are any local overrides configured that could be causing the issue.

Also, the easiest way to 'turn it off' would be to put a 'deny ip any any' at the top of the crypto ACLso no traffic is encrypted, and then slowly migrate networks to be encrypted again, which was what I was suggesting - maybe as a way to narrow down if a particular entry in the crypto ACL that is pushed to the GMs is causing the issues.

Getting the KS config would probably be the easiest, I agree, but given that this is a financial customer on a public forum, I'm not sure how likely that is to happen. 

--Jason