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
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!!
Make sure that the crypto ACL is bidirectional for ever entry, ie:
permit tcp 10.0.0.0 0.255.255.255 184.108.40.206 0.255.255.255 eq 23
permit tcp 220.127.116.11 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, 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.
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.