We’ve connected to pretty much every networking device out there, and we’ve learned the hard way what not to do while routing traffic to, from, and between cloud deployments. Today we’d like to share a few tips we’ve learned while working with the major network vendor “boxes” and some 2,000 VNS3 customers.
First up, Cisco ASAs
Cisco has a concept of “interesting traffic.” If there isn’t any interesting traffic going on, the ASA will not complete the tunnel connection. The ASA also has an idle timeout default setting that closes a tunnel after 30 minutes. That means if you are connecting a VNS3 device to an ASA, you’ll need to keep traffic flowing in order to connect and maintain your connection.
Since you likely just set up your IPsec tunnel connection in the VNS UI, you know for sure that there is a “ping-able” host at the address. In order to keep the ASA from timing out, you can set VNS3 to send a ping to that host every 30 seconds.
From the IPsec page, you can edit the Ping host and add a Ping interval. That should keep the Cisco ASA timeout from kicking in. Or, ideally, you can have your partner/customer set their ASA to idle timeout at 0, meaning the connection will stay open until you need to edit it again.
Cisco ASA running versions 8.4.2 to 8.4.4 are just buggy. We’ve had trouble with 8.4.2, 8.4.3 and 8.4.4. Once you upgrade above 8.4.5, we’re fine. Remember to check your ASA updates if you’ve noticed any issues.
The Watchguard runs into issues with the VNS3 static LAN. To fix this, just add our local private IP (usually 192.0.2.254 or something like that) as your IKE Peer ID.
Surprisingly, as one of the biggest network vendors in the world, Checkpoint does not follow NAT-Traversal standards. If you’re using Checkpoint, you will have to use something like AWS VPC and enable Native IPsec on VNS3 to use Protocol 50 (ESP) to encapsulate traffic.
Check it twice!
Make sure check everything twice! The easiest way to make troubleshooting better is to do it right from the first time. We’ve got a network checklist to share with partners and customers, as well as a Google Forms format. Share the network knowledge.
With EOL’d software, there can be interop issues due to the age of the IPsec standards used. For example, we know that Cisco 1945ios router 15.4TM was end-of-life’d (EOL) in 2005. If we see that listed on your network checklist, we know to look out for some aging hardware and we can help you sort out any issues.
At the end of the day, your best resource is the product resource page (aka Documentation!):cohesive.net/support/product-resources
Make sure contact us if you run into any trouble!