Site to Site and Remote Access VPN behind same Public IP

[johnnylingo]

Got a rather stupid issue.  We have a Site to Site VPN configured to a new data center, that will handle general corporate traffic.  Additionally, certain users need to use utilize a VPN client to access certain zones.  The firewall in the office only has one public IP, so both the Site to Site and Remote Access VPNs will be coming from the same source.

This seems to cause a problem with the legacy Cisco VPN clients, because the crypto map matches the site-to-site VPN entry, even though they are using VPN clients.  Any good/easy solution to fix this?

Some logs (198.18.85.23) is the public IP for the office and tom.jones is the user.  192.168.1.0/24 is the VPN client pool.

Jan 07 2014 19:12:52 ASA5515 : %ASA-5-713130: Group = Corp-VPN, Username = tom.smith, IP = 198.18.85.23, Received unsupported transaction mode attribute: 5

Jan 07 2014 19:12:52 ASA5515 : %ASA-5-737003: IPAA: DHCP configured, no viable servers found for tunnel-group 'Corp-VPN'

Jan 07 2014 19:12:52 ASA5515 : %ASA-5-713119: Group = Corp-VPN, Username = tom.smith, IP = 198.18.85.23, PHASE 1 COMPLETED

Jan 07 2014 19:12:52 ASA5515 : %ASA-3-713061: Group = Corp-VPN, Username = tom.smith, IP = 198.18.85.23, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 192.168.1.4/255.255.255.255/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface OUTSIDE

Jan 07 2014 19:12:52 ASA5515 : %ASA-3-713902: Group = Corp-VPN, Username = tom.smith, IP = 198.18.85.23, QM FSM error (P2 struct &0x00007fff28dab560, mess id 0x37575f3c)!

Jan 07 2014 19:12:52 ASA5515 : %ASA-3-713902: Group = Corp-VPN, Username = tom.smith, IP = 198.18.85.23, Removing peer from correlator table failed, no match!

Jan 07 2014 19:12:52 ASA5515 : %ASA-5-713259: Group = Corp-VPN, Username = tom.smith, IP = 198.18.85.23, Session is being torn down. Reason: crypto map policy not found

Jan 07 2014 19:12:52 ASA5515 : %ASA-4-113019: Group = Corp-VPN, Username = tom.smith, IP = 198.18.85.23, Session disconnected. Session Type: IKEv1, Duration: 0h:00m:02s, Bytes xmt: 0, Bytes rcv: 0, Reason: crypto map policy not found

Jan 07 2014 19:12:53 ASA5515 : %ASA-5-713904: IP = 198.18.85.23, Received encrypted packet with no matching SA, dropping

[johnnylingo]

Configuration on the ASA, running version 9.1(4) 

access-list OUTSIDE_cryptomap extended permit ip object-group obj_DataCenter object-group obj_Office

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev1 transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5

crypto map OUTSIDE_map 5 match address OUTSIDE_cryptomap

crypto map OUTSIDE_map 5 set pfs

crypto map OUTSIDE_map 5 set peer 198.18.85.23

crypto map OUTSIDE_map 5 set ikev1 transform-set ESP-AES-128-SHA ESP-3DES-SHA

crypto map OUTSIDE_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP

crypto map OUTSIDE_map interface OUTSIDE

[Jouni Forss · Accepted solution]

Hi,

Not sure if this will work but you could try the following configuration (along with the rest of the VPN configurations)

access-list CLIENT-VPN permit ip any 192.168.1.0 255.255.255.0

crypto map OUTSIDE_map 4 match address CLIENT-VPN

crypto map OUTSIDE_map 4 set peer 198.18.85.23

crypto map OUTSIDE_map 4 set ikev1 transform-set ESP-AES-128-SHA ESP-3DES-SHA

The idea would be to have the ACL match the Full Tunnel VPN that the Client is trying to establish. (destination "any" from the perspective of the Client, source from ASAs perspective)

I tested this briefly on my own ASA by connecting to it from an IP address to which the ASA has a L2L VPN Connection. But as I dont have the L2L VPN operational I can't really verify the L2L VPN operation at the moment. So some risk might be involved if you can afford it.

- Jouni

[johnnylingo]

I initially though this worked, but turns out I the adjustment has to be within the Dynamic map so that it's correctly applied to the clients.

! Dynamic crypto map for legacy VPN clients

crypto dynamic-map REMOTE_ACCESS 1 set peer 1.2.3.4
crypto dynamic-map REMOTE_ACCESS 1 set ikev1 transform-set ESP-3DES-SHA ESP-3DES-MD5
crypto dynamic-map REMOTE_ACCESS 2 set peer 4.5.6.7
crypto dynamic-map REMOTE_ACCESS 2 set ikev1 transform-set ESP-3DES-SHA ESP-3DES-MD5
crypto dynamic-map REMOTE_ACCESS 65535 set ikev1 transform-set ESP-3DES-SHA ESP-3DES-MD5

! Crypto map applied to outside interface

crypto map OUTSIDE_map 1 match address STS_X
crypto map OUTSIDE_map 1 set pfs
crypto map OUTSIDE_map 1 set peer 1.2.3.4
crypto map OUTSIDE_map 1 set ikev1 transform-set ESP-AES-128-SHA ESP-3DES-SHA
crypto map OUTSIDE_map 2 match address STS_Y
crypto map OUTSIDE_map 2 set pfs
crypto map OUTSIDE_map 2 set peer 4.5.6.7
crypto map OUTSIDE_map 2 set ikev1 transform-set ESP-AES-128-SHA ESP-3DES-SHA
crypto map OUTSIDE_map 65535 ipsec-isakmp dynamic REMOTE_ACCESS
crypto map OUTSIDE_map interface OUTSIDE

Another gotcha - if you're using split tunnel with local LAN access, make sure the split tunnel entries don't exactly match any local subnets.  For example, if users connect from an internal subnet 192.168.1.0/24, set the split tunnel list to include 192.168.0.0/23 rather than 192.168.1.0/24.

[MedTiti92]

did you resolve this issues. if yes .. please provide your solution ! facing some issues !

Thanks