If you have recently upgraded to ASA 8.4 or above, you might have come across a VPN behavior where the outbound IPSec SA reaches it’s data lifetime threshold and you have to manually bounce the tunnel to bring it back up.
This happens because of a bug found in the code 8.4(2.240) and 8.6. The bug is such that the IPSec outbound SA in Phase 2 fails to rekey when the ‘data lifetime’ reaches it’s threshold limit (default 4608000). CSCtq57752 is the bug ID which you can lookup in the bug tool kit (requires a CCO login).
There is a workaround and a fix for this issue;
1. Workaround: The lifetime values for the particular VPN tunnel in question needs to be adjusted where the re-key for the VPN should happen with the seconds lifetime and not the data lifetime.
2. Fix: Upgrade to ASA 8.4(3) or the other versions in which the bug is fixed.
Change the lifetime seconds to a lower value so that the outbound IPsec SA rekey happens when the seconds threshold is reached. Continue reading
Just came across this comic strip that was posted by Tufin’s facebook page few days back and I couldn’t agree more to it.
By the way, Tufin is a wonderful firewall management application that provides solutions for firewall policy change management, auditing, analysis and compliance.
If you’re trying to configure a Static PAT/Port forwarding rule in Check Point and if it still isn’t working, then this post will help you to understand the reason behind it and also what additional configuration will be required to get it to work.
Adding a Static PAT/Port forwarding rule in Check Point is one hell of a task because Auto NAT in Check Point doesn’t allow you to specify any ports (unlike Cisco ASA’s Auto NAT post 8.3), so you have to use Manual NAT here . And to make that work you’ll also have to configure Static ARPs on the firewall.
The reason for manually configuring the ARP entry is because, when you use a Manual NAT to configure a Static PAT rule, the external interface of the firewall does not proxy ARP if the NAT IP (public IP) used for the internal server belongs to the connected subnet with your ISP. Continue reading
The following lists the order in which the rules/policies/ACLs (whatever you may call it) are enforced in Check Point R75:-
1. Anti-spoofing check
2. Implied rules configured First in the Global Properties.
3. Stealth rule (normally the first explicit rule) Continue reading
I recently came across this scenario where a customer had two internet links terminating on his ASA from two different ISPs. If his primary link (ISP2) was unavailable, he wanted the Site-to-Site VPN to fail over to the backup link (ISP3). This post shows you how to configure a firewall having two internet links using the SLA monitoring feature to get the required redundancy for the Site-to-Site VPN.
The site having two ISPs (in this case, FW2) is the one that needs major changes. Basic site-to-site configuration remains the same and only additional configuration for the backup peer IP 220.127.116.11 is covered under this post.
TCP and UDP being statefully inspected by default, you just have to run the packet-tracer on the source interface and you can be sure the return traffic will be allowed through. With ICMP, it’s a different story.
Because the ASA does not statefully inspect ICMP packets (by default) you have to vouch for the return packets as well. So you’ll be running two packet-tracer commands to verify that ICMP packets go through and come back. Continue reading
The previous post shows you how to configure a basic IPsec Remote Access VPN using a Cisco IPsec VPN client with minimal configuration. This post is in continuation to the previous one, so do have a look at Part 1 which covers the basic configuration of an IPsec Remote Access VPN using the Cisco IPsec VPN Client. Continue reading
To be honest, there isn’t much of a change in the configuration of an IPsec Remote Access VPN in ASA 8.3/8.4. There is just a minor change in some of the ‘crypto’ statements wherein you need to specify it as either IKEv1 or IKEv2.
So if you are planning to use the legacy IPsec VPN client (the one with that yellow lock icon) then you need to configure your Remote Access VPN with IKEv1 option. And if you’re planning to move to the new AnyConnect VPN client, then you need to configure your Remote Access VPN for IKEv2. AnyConnect does support IPsec VPN, it’s just that it will only work when you have the respective remote access VPN configured for IKEv2.
Please note that the ASA can simultaneously be configured for both IKEv1 and IKEv2. Though they use the same UDP port they are not interoperable but they work independently without any conflicts.
The following post covers the basic configuration that will be required for running an IKEv1 Remote Access VPN in ASA 8.3/8.4. Continue reading