cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6723
Views
0
Helpful
3
Replies

Trying to run a Site to Site VPN and Remote VPN from the same remote IP

John Malette
Level 1
Level 1

We currently have a site to site VPN setup between our offices and a 3rd party call center which allows them to access our training environment for their employees to use while being trained on our systems. This tunnel is running between our ASA and their ASA with no problem; however, when we have managers go out to the call center they are unable to use Remote VPN to access our office.  

Apparently the same remote peer IP address that we are using for our site to site tunnel is the same IP address that our Managers are using to access the internet when they are on site with the client. When I look at the logs it shows  the VPN attempt and then I get Information Exchange processing failed. So from what I can gather when our managers try to connect to our firewall from the same IP as the site to site peer it automatically tries to create a tunnel based on the site to site tunnel information. If our managers are anywhere else they can connect via remote VPN with no problems.

My question is if anyone knows of a way to make the firewall allow both site to site and remote VPN connectivity from the same remote IP address.     

1 Accepted Solution

Accepted Solutions

Hello John,

Basically, in older versions, when you hit a static crypto map and you did not match that static crypto map completely the connection continues until the dynamic crypto map. For that reason you could connect your IPSec clients before. A bug was opened about this vulnerability.

CSCuc75090  Bug Details

Crypto IPSec SA's are created by dynamic crypto map for static peers

Symptom:

When a static VPN peer adds any traffic to the crypto ACL, an SA is built even though the IP pair is not allowed in the crypto acl at the main side. Those SA's are eventually matched and  setup by the dynamic crypto map instance.

Conditions:

This was a intended design since day one that enabled customers to fall through in case of static crypto map didn't provide a needed crypto services.

The SA need to be initiated from a statically configured peer and a dynamic crypto map instance must be configured on the receiving end.

Workaround:

N/A

Some possible workarounds are:

Configure a static nat that when trying to use the remote VPN  so the remote firewall will be hit with different Public IP. That would be a good workaround but it will depend of how many public ip addresses you have available, also if you really want to spend one of those ip addresses for that access.

Also, I was thinking that you could use AnyConnect instead of IPSec VPN client. I do not know how many users need to connect from your HQs to the remote site, but the ASA has 2 available SSL licenses that you could use. Since Anyconnect uses SSL protocol it will not cause any problems on your environment.

Below some information:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/vpn_anyconnect.html

Hope this helps,

Luis.

View solution in original post

3 Replies 3

shine pothen
Level 3
Level 3

Hello John,

if you already have site to site Vpn form your office to the call center office, then why you want your manager to use remote access vpn.

they just simply have to connceted to the local Lan of the call center and then will get access to your office, if there is restriction given then check for those subnets.

what is the Remote peer ip that you are using.

can you please share the config,

I'm unable to open up the site to site tunnel to all of our subnets for security reasons so our manager cannot connect using that tunnel. Currently it only has access to our production servers.

The Remote Peer IP is the outside IP of their ASA and the call center's peer is our outside ASA interface which is the same for the Host IP for the remote VPN profile.

I know that's what is causing the problem so I'm looking for anyone's ideas on how to work around the problem. I cannot post the config at this time because I don't have time to go through and sanitize the config prior to posting, but if someone wants to see a specific part of the config I could try to post that.

Hello John,

Basically, in older versions, when you hit a static crypto map and you did not match that static crypto map completely the connection continues until the dynamic crypto map. For that reason you could connect your IPSec clients before. A bug was opened about this vulnerability.

CSCuc75090  Bug Details

Crypto IPSec SA's are created by dynamic crypto map for static peers

Symptom:

When a static VPN peer adds any traffic to the crypto ACL, an SA is built even though the IP pair is not allowed in the crypto acl at the main side. Those SA's are eventually matched and  setup by the dynamic crypto map instance.

Conditions:

This was a intended design since day one that enabled customers to fall through in case of static crypto map didn't provide a needed crypto services.

The SA need to be initiated from a statically configured peer and a dynamic crypto map instance must be configured on the receiving end.

Workaround:

N/A

Some possible workarounds are:

Configure a static nat that when trying to use the remote VPN  so the remote firewall will be hit with different Public IP. That would be a good workaround but it will depend of how many public ip addresses you have available, also if you really want to spend one of those ip addresses for that access.

Also, I was thinking that you could use AnyConnect instead of IPSec VPN client. I do not know how many users need to connect from your HQs to the remote site, but the ASA has 2 available SSL licenses that you could use. Since Anyconnect uses SSL protocol it will not cause any problems on your environment.

Below some information:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/vpn_anyconnect.html

Hope this helps,

Luis.