There is Internet buzz and customer complaints around wording buried in some ASA configuration docs that can be interpreted as, “Cisco doesn’t support 3rd Party VPN connections” To set the record straight, Cisco has changed all of their documentation (in record time) to reflect their true stance.
The text in question:
ASAs support IPsec LAN-to-LAN VPNs with other Cisco peers. Because we adhere to VPN industry standards, ASAs may work with other vendors' peers in LAN-to-LAN VPNs; however, we do not support them.
Has been updated to this:
The ASA supports Lan-to-Lan IPSec connections with third party devices that comply with all relevant standards.
Many of us, myself included, always interpreted the original quote in the way it was intended. So we didn’t ever think twice about it. The intent was something like this, if you connect to a 3rd party and they are standards based then Cisco TAC would support the Cisco side of the connection and the 3rd party would have to support their side of the connection. Nothing new here right. However, history has shown that Cisco TAC usually goes above the call of duty and tries to help out Cisco customers on both ends even though that is not their job. Also, Cisco has publicly posted numerous whitepapers on how to connect Cisco stuff to other vendors like checkpoint and Juniper for example.
So I find it a bit disturbing that the blogosphere would start to perpetuate these wild interpretations of the above original text. I can understand competitors doing it (and they are, believe me) but seasoned Cisco engineers jumping on. Come on folks! Does anyone really believe that Cisco would start rejecting 3rd party IPSEC VPN connections to their ASAs? That’s like saying Microsoft is going to start rejecting 3rd party software on their operating system. Maybe when hell freezes over, but not before.
Cisco has a better track record working with customers to support 3rd parties than any other vendor in this arena by far. And most of it is just TAC engineers going above and beyond the call of duty in an effort to help their customers.
Hopefully the new wording Cisco has injected in their docs will stop the buzz and rumor mill regarding this FUD (fear uncertainty and doubt) being injected into the blogosphere at a torrent pace.
If you have any other questions or would like some kind of additional clarification just post it here and I can help.
For a look at the new changes here is a list of the docs that have been updated so far, if you find another one that needs updating please post it.
http://www.cisco.com/en/US/docs/security/asa/compatibility/asa-vpn-compa...
http://www.cisco.com/en/US/partner/docs/security/asa/asa81/config/guide/...
http://www.cisco.com/en/US/docs/security/asdm/6_1/user/guide/vpn_ike.htm...
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/s...
IKE chapter, IPsec section in http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/a...
http://www.cisco.com/en/US/docs/security/asa/asa80/asdm60/user/guide/vpn...
http://www.cisco.com/en/US/docs/security/asa/asa72/asdm52/user/guide/vpn...
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/s...
http://www.cisco.com/en/US/docs/security/asa/asa71/asdm51/user/guide/vpn...
http://www.cisco.com/en/US/docs/security/asa/asa71/configuration/guide/s...
http://www.cisco.com/en/US/docs/security/asa/asa70/configuration/guide/s...
The opinions and information presented here are my personal views and not those of my employer.
More from Jamey Heary:
* Credit Card Skimming: How thieves can steal your card info without you knowing it
* Cisco enters the crowded AV and DLP client market
*Cisco's new ASA code allows you to securely take your Cisco IP Phone with you anywhere
* Cisco targets Symantec, McAfee with its new antivirus client
* Google's Chrome raises security concerns and tastes like chicken feet a>Go to Jamey’s Blog for more articles on security.
Advertisement: |
Jamey Heary, CCIE No. 7680, is the author of the Cisco NAC Appliance: Enforcing Host Security with Clean Access book by Cisco Press. Jamey is a seasoned security technologist with over 15 years in the IT field with 10 years focused on IT security. His areas of expertise include network and host security design and implementation, security regulatory compliance, and routing and switching. His other certifications include CISSP, CCSP, and Microsoft MCSE. He is also a Certified HIPAA Security Professional. Jamey is currently a Security Consulting Systems Engineer with Cisco, though the opinions expressed here are his own. Jamey is a member of Network World's Cisco Subnet blog community.
The Leader in Network Knowledge
What's the big deal?
I don't understand people's concern. Any engineer who has ever had the chance to work with TAC should know they go above and beyond the call of duty in supporting customers. I've actually been on a call where the TAC engineer called the third party vendor and explained what was happening.
iPhone ipsec vpn
It has been proven by Joe Harris, CCIE# 6200 that Cisco IOS router is capable to establish ipsec vpn connection with iPhone. He wrote his recipe here.
But in "Apple iPhone 2.0 VPN Connectivity to Cisco Adaptive Security Appliances (ASA)" the last statement say: "Neither Cisco IOS VPN routers nor the VPN 3000 Series Concentrators support the iPhone VPN capabilities.".
The question is - what is true purpose for this disclaimer?
not outrageous to think support was cut
In the current economic client, everyone is looking to cut costs and do more with less. In the support world one way of doing that is to drop the extent of support so cases are closed quicker. I could see a company putting a disclaimer like that in their product so support can say "hey we told you its not supported" and they are off the phone faster and onto the next case. IMHO, this will cut costs but it will also result in less customer loyalty and in the end lower sales. I think Cisco TAC and other support organizations that go above and beyond are what really differeniates a company.
The hidden issue here is the
The hidden issue here is the use of the pronoun 'them' in a technical document. To which 'them' is the writer of the doc referring? The peer or the L2L connection? Maybe I'm old school, but I hate seeing references to 'them', 'they', 'it', etc. in tech docs.
Silly us...
The original text says: "we do not support them."
Silly public for thinking that Cisco actually meant that they do not support them. I mean, it's obvious that while they say "we do not support them," what Cisco really means is that they *DO* support them. And we should all know that because the Cisco TAC is all that and a bag of chips. All this is obviously a contrived controversy generated by Cisco's competitors and the blogosphere to make them look bad. Obviously, Cisco is completely blameless in this misunderstanding. After all, they explicitly state "we do not support them," and everybody should know exactly what that means.
Sheesh... :rolleyes:
Silly Anonymous
the original text actually states this
" Because we adhere to VPN industry standards, ASAs may work with other vendors' peers in LAN-to-LAN VPNs; however, we do not support them."
The "do not support them" means from a TAC perspective Cisco will not help you configure the 3rd party devices. That is where the confusion was and why Cisco changed its docs. It was not clear enough that this was a support from a TAC perspective and not a product perspective. It was obvious to most but not all, and when the FUD started flying Cisco immediately changed its docs to clear up any misunderstandings.
Silly us, still...
What? So now "we do not support them" is supposed to be translated as "we won't help you configure a competitors product?" Really? Because, you know, every other TAC helps me configure competitors products... Puh-leeze.
So, let's just say it: Cisco screwed up. It's unclear whether the manual text was the screw-up or whether the policy was a screw-up and later changed once it gained visibility, but clearly the screw-up was Cisco's and not the public's. The fact that you said that even Cisco engineers misinterpreted the text is evidence that it was misleading. As a Cisco employee (and fanboy), you're simply trying to spin this as something positive when it isn't. You might escape this with some shred of credibility if you simply say, "Yea, that was a screw-up. Obviously, the manual was wrong," and leave it at that. Desperate attempts to prove it was everybody else's fault only make you look foolish.
your right
yeah you must be right, your argument makes much more sense than mine. mine is that Cisco produced some ambiguous wording in its docs by mistake, people took it as it was not intended, cisco fixed the issue quickly to express their real point.
Your argument is that Cisco decided to stop supporting all 3rd party connections into their ASA and would only support connections with their own products. Instead of making this announcement public, Cisco decided to hide this insignificant factoid deep into their ASA docs. Cisco figured that once 3rd party connections just started to randomly fail that customers would understand and they could point to their little blurb in the docs to say "hey we told you so". Cisco doesn't feel the need to make this known to the fortune 100 companies, Gov't agencies, etc that use their ASA VPN solution which connects 1000's upon 1000's of 3rd party VPN L2L tunnels around the globe. Cisco figured they'd just let those fail and the customers could just deal with it. But hey they told everyone right? It was in their documentation! You're definitly right, I don't know what I was thinking before. Silly me.
I've heard some conspiracy theories before, but yours is over the top. Almost worthy of a blog topic of its own I'd say.
"The "do not support them"
"The "do not support them" means from a TAC perspective Cisco "
So are you saying here that the Cisco customer is the Cisco Tac ? :)
From when we read docs as being Cisco TAC ?
If a customer needs an l2l with a third-party VPN gateway, and it happens to experience some issues, this customer may go and read your docs, being in a state of confusion. And surprise there, from the customer's point of view it says: "ASAs may work with other vendors' peers in LAN-to-LAN VPNs; however, we(Cisco) do not support them(l2l connections with other vendors' peers)." That translates into crystal clear Cisco ASA does not support l2l VPNs with third party VPN gateways.
Of course, we may assume as well that this customer happens to be an IPsec expert and knows that Cisco is a member of the VPNC, and that Cisco's l2l VPN's implementation is RFC compliant in respect with RFC X and RFC X, and have setup hundreds of l2l VPNs with ASAs and third-party VPN gateways....
I have a better explanation: Shakespeare wrote that doc and Cisco wrote Romeo and Juliet. :)
The PURPOSE of any GOOD documentation material is to be DEFINITIVE and not interpretable, as it is assumed that the reader may already be in a state of ambiguity.
The only one responsible for the interpretability thing is Cisco and Cisco alone. This discussion wouldn't have place if the documentation would have been, let's say more exact.
So have some decency and take the blame.
living in the past
why are you living in the past. You should be shelling out kudos to cisco for so quickly changing their docs to make them more clear the moment they got wind that others were taking their wording the wrong way. Surely you understand that their are two definitions for "support" one is hardware/configuration support and the other is technical/help desk support. I don't see any blame needed to be taken by anyone. the docs were being misinterpretted, cisco got wind of it, and made the change within record time. I'm sure it upset the competitors that were spreading FUD but not cisco customers like yourself right?
Post new comment