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 10,000+ VNS3 deployments.
First up, Cisco ASA:
Cisco employs a concept they call “interesting traffic.” If there isn’t any "interesting traffic" present, the ASA will not complete the tunnel connection. The ASA also has a "vpn-idle-timeout" default setting that tears down a tunnel after 30 minutes of inactivity. 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. If you don't, the tunnel will bounce every 30 minutes.
In order to keep the ASA from doing that, you can configure VNS3 to send a ping to some host on the other side periodically.
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's idle timeout to 0, which will disable the timeout.
The IPSec implementation in Cisco ASA versions 8.4.2-8.4.4 is quite buggy. We’ve had trouble with 8.4.2, 8.4.3 and 8.4.4. Once you upgrade above 8.4.5, things generally work fine. Remember to check for updates for your ASA if you’ve noticed any issues.
Watchguard
Watchguard devices run into issues with IKE IDs. You will likely need to set VNS3's "local private IP" (located at the top of the IPSec page; 192.0.2.254 by default) as the remote IKE Peer ID in the Watchguard configuration.
Checkpoint
Surprisingly, as one of the biggest network vendors in the world, Checkpoint did not follow NAT-Traversal standards until version R77+.
If you’re using a Checkpoint device, you may need to use Native IPsec instead of NAT-T.
Checkpoint also likes to have IKE Peer IDs set explicitly.
Palo Alto
By default, Palo Alto devices do route-based IPSec instead of policy-based. VNS3 v4.4.0+ supports route-based VPN, but there are still situations where policy-based is preferred or required.
In order to configure policy-based IPSec on a Palo Alto device, you must configure "Proxy IDs"; one for each tunnel. We've also noticed a small bug in Palo Alto's web interface which sometimes requires that Proxy IDs be saved, and the configuration committed, twice before they will come into effect.
Fortinet
Fortinet devices also default to route-based IPSec. There is a system setting to enable policy-based IPSec, after which you can configure multiple IPSec phase 2 objects, each one corresponding to one tunnel.
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 to help make coordination easier. Share the network knowledge!
With EOL’d software, there can be interoperability issues due to the age and evolution of the IPsec standard. 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!): https://www.cohesive.net/support/documentation
Be sure to contact us if you run into any trouble!