Crazy VPN Situation - RA & S2S VPN to&from Same IPs
f0rgiv3n
Member Posts: 598 ■■■■□□□□□□
OK dudes, here's some crazy stuff and I'm still trying to work it out in my mind so any help would be great.
Say you have an IPSec Site-to-Site VPN between your HQ and a branch site. The HQ side has an ASA and that same ASA hosts the RA VPNs as well, which is using Cisco VPN clients (IPSec VPN as well).
The VPN is configured with split tunneling so only the private IP ranges are traversing the tunnel, the remainder is going out to the Internet (Including any traffic destined for the external IP of the HQ ASA).
Now, in the past, I have told people "the RA VPN will not work from the insides of the network, you must test it from a guest Internet or run to a coffee shop". We had a push to see if we can get the RA VPN to be able to work, from WITHIN the branch office site.
Here's the issue, the HQ ASA will have a Security Association already tied to the Branch office's external IP and so when it receives another VPN negotiation attempt (from the client) it becomes confused.
This ended up actually causing issues with the Site-to-Site VPN. Users would try to connect(even though they didn't need to, just out of habit) their RA VPN from within the Branch Office's LAN. Oddly enough, this caused the site-to-site VPN to drop and the HQ ASA would say "duplicate entry in tunnel manager" and the SAs would be screwed up. The only way to fix it would be either to wait for the SA to timeout, or reboot the branch router. It took me forever to figure out what was causing the issue since it was intermittent and seemed odd that something like this would cause an issue.
Basically, I'm of the opinion that this will never work because of the Security-association overlap. The HQ ASA will always be confused if it has two different Security-Associations with the same destination IP. Has anyone ever done anything like this? Am I crazy, or what? Feel free to say that I'm crazy, i can take it.
Side note: I do know that I could implement a NAT rule on the branch site to make any client's trying to connect use a different IP (which would solve the issue). I'm just trying to figure out in my head if it's possible at all without avoiding the issue altogether by changing the IP address.
Say you have an IPSec Site-to-Site VPN between your HQ and a branch site. The HQ side has an ASA and that same ASA hosts the RA VPNs as well, which is using Cisco VPN clients (IPSec VPN as well).
The VPN is configured with split tunneling so only the private IP ranges are traversing the tunnel, the remainder is going out to the Internet (Including any traffic destined for the external IP of the HQ ASA).
Now, in the past, I have told people "the RA VPN will not work from the insides of the network, you must test it from a guest Internet or run to a coffee shop". We had a push to see if we can get the RA VPN to be able to work, from WITHIN the branch office site.
Here's the issue, the HQ ASA will have a Security Association already tied to the Branch office's external IP and so when it receives another VPN negotiation attempt (from the client) it becomes confused.
This ended up actually causing issues with the Site-to-Site VPN. Users would try to connect(even though they didn't need to, just out of habit) their RA VPN from within the Branch Office's LAN. Oddly enough, this caused the site-to-site VPN to drop and the HQ ASA would say "duplicate entry in tunnel manager" and the SAs would be screwed up. The only way to fix it would be either to wait for the SA to timeout, or reboot the branch router. It took me forever to figure out what was causing the issue since it was intermittent and seemed odd that something like this would cause an issue.
Basically, I'm of the opinion that this will never work because of the Security-association overlap. The HQ ASA will always be confused if it has two different Security-Associations with the same destination IP. Has anyone ever done anything like this? Am I crazy, or what? Feel free to say that I'm crazy, i can take it.
Side note: I do know that I could implement a NAT rule on the branch site to make any client's trying to connect use a different IP (which would solve the issue). I'm just trying to figure out in my head if it's possible at all without avoiding the issue altogether by changing the IP address.
Comments
-
f0rgiv3n
Member Posts: 598 ■■■■□□□□□□
In case anyone ever runs across this:
I did end up blocking client VPN attempts at the branch site. This resulted in a stable VPN connection. As far as I know, there could be a work around by creating a granular entry in the cryptomap for the RA VPNs but have it be above the Site-to-Site cryptomap entry.
The effort wasn't worth the payout so we ended up just blocking all attempts and this fixed the issue. While it makes sense, this is the first time I've run across this and it is sort of crazy to think that something as simple as this would cause a S2S VPN to drop and have issues renegotiating.