KB ID 0001604
Problem
A colleague was doing a firewall migration yesterday and I offered to sit in, in case he had any problems, one of the tasks was a VPN tunnel getting migrated, this is usually painless, (if you have control of both ends!) But in this case we didn’t, and it’s usually the case, when there’s VPN problems, the people at the {ahem} ‘less experienced,’ end of the tunnel tend to blame the other end.
I asked if we could get on the client’s servers to set up a constant ping, (to force the tunnel up as soon as the far side had changed peer ip addresses). But we couldn’t, I was asked ‘Can we not bring the tunnel up from the ASA?’
Solution
Note: To save people emailing me to ask, the above is virtualised using EVE-NG in VMware ESX.
Well, yes you can do this, BUT there are some caveats,
- The inside IP of the ASA needs to be part of the ACL that declares ‘interesting traffic’ i.e. the one matched in the crypto map.
- The inside IP o the ASA needs to also be in the nat exemption for the VPN traffic.
- ‘Management-access inside‘ needs to be enabled in the config, (so traffic can be sourced from it).
Then, (assuming 192.168.1.10 is an IP address at the far-end of the VPN tunnel), use the following syntax;
ping inside 192.168.1.10Note: This assumes your inside interface is called ‘inside‘, yours may be called LAN, or Inside, or something else.
Well my IP is on a different range to the inside interface, or I can’t enable management-access inside, and/or my IPs are not in the nat exemption! Jeez there’s always one! Well in your case you can simulate VPN traffic to bring the tunnel up, with packet-tracer, like so;
packet-tracer input inside tcp 172.16.1.1 80 192.168.1.10 80
Note: This assumes 172.16.1.1 is at YOUR site and 192.168.1.10 is at the OTHER site, and you interesting traffic ACL permits TCP port 80, (most of them permit all ports but you may be in a more secure environment so check).
Related Articles, References, Credits, or External Links
NA
