UTM 9 and Cisco ASA 3030 IPSec VPN

Question

Dear all, 
 First I would like to say HI to you all and I am looking forward to be a part of this Community. 
 
 So as Subject describes I am fighting with IPSEc VPN connection to the Cisco ASA 3030. I have to say that Cisco is not in our control so we can get logs per request but could take a while. So to describe the situation: I have 5 AWS VPC VPN connection already there and working. Now I am trying to set up the VPN to the Cisco ASA 3030 site but with one extra requirement, it needs to go trough the NAT and here is where all stops making sense for me. So to start at the begining: 1. I defined the policie for the connection and configured the phase 1 and phase 2 auth as received from the other side. 
 2. I defined the Remote GW for this VPN connection 
 3. I creted the VPN connection itself 
 4. When taking a look at the logs I see that phase 1 auth goes trough without any problems 
 Then I get stuck as phase 2. My guess is that 1:1 NAT does not work/is not configured properly so that is why phase 2 auth does snot go trough. As confirmation I received this logs from Cisco: 
 Nov 17 12:14:22 dres-fw-dmz-020_s138 %ASA-3-713119: Group = *.*.*.*, IP = 195.226.181.251, PHASE 1 COMPLETED Nov 17 12:14:22 dres-fw-dmz-020_s138 %ASA-3-713035: Group = *.*.*.*, IP = 195.226.181.251, Received remote IP Proxy Subnet data in ID Payload: Address 172.17.0.0, Mask 255.255.252.0 , Protocol 0, Port 0 Nov 17 12:14:22 dres-fw-dmz-020_s138 %ASA-3-713224: Group =*.*.*.*, IP = 195.226.181.251, Static Crypto Map Check by-passed: Crypto map entry incomplete! Nov 17 12:14:22 dres-fw-dmz-020_s138 %ASA-3-713224: Group =*.*.*.*, IP = 195.226.181.251, Static Crypto Map Check by-passed: Crypto map entry incomplete! Nov 17 12:14:22 dres-fw-dmz-020_s138 %ASA-3-713061: Group =*.*.*.*, IP = 195.226.181.251, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 172.17.0.0/255.255.252.0/0/0 local proxy 10.205.129.70/255.255.255.255/0/0 on interface outside 
 Nov 17 12:14:22 dres-fw-dmz-020_s138 %ASA-3-713902: Group =*.*.*.*, IP = 195.226.181.251, QM FSM error (P2 struct &0x00002aaadf3731d0, mess id 0xeb5a068f)! Nov 17 12:14:22 dres-fw-dmz-020_s138 %ASA-3-713902: Group =*.*.*.*, IP = 195.226.181.251, Removing peer from correlator table failed, no match! Nov 17 12:14:22 dres-fw-dmz-020_s138 %ASA-4-113019: Group =*.*.*.*, Username =*.*.*.*, IP = *_vpn_401532, Session disconnected. Session Type: LAN-to-LAN, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: crypto map policy not found 
 
 As you can see from here, the IP that UTM 9 is representing is 172.17.0.0 but it should be 10.205.176.24. My 1:1 NAT config looks like this: 
 Where Going to is: 10.205.129.70 and Map to is: 10.205.0.0/22. And when I try to initiate the connection this is what Sophos UTM 9 says: 2016:11:23-15:25:05 gw01 pluto[28618]: added connection description "S_REF_IpsSitComarch_0" 2016:11:23-15:25:05 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: initiating Main Mode 2016:11:23-15:25:05 gw01 pluto[28618]: ERROR: "S_REF_IpsSitComarch_0" #39: sendto on eth1 to REMOTE_IP:500 failed in main_outI1. Errno 1: Operation not permitted 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: ignoring Vendor ID payload [FRAGMENTATION c0000000] 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: ignoring Vendor ID payload [Cisco-Unity] 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: received Vendor ID payload [XAUTH] 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: ignoring Vendor ID payload [1fdb140ae9aced8797244c025cbefb3f] 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: ignoring Vendor ID payload [Cisco VPN 3000 Series] 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: received Vendor ID payload [Dead Peer Detection] 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: Peer ID is ID_IPV4_ADDR: 'REMOTE_IP' 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: ISAKMP SA established 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #40: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#39} 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: ignoring informational payload, type INVALID_ID_INFORMATION 2016:11:23-15:25:15 gw01 pluto[28618]: "S_REF_IpsSitComarch_0" #39: received Delete SA payload: deleting ISAKMP State #39

With enabling " Enable XAUTH client mode" and putting in random username and pre shared key as password I get rid of INVALID_ID_INFORMATION error but it does not help. Any suggestions on how to solve this? If you need any additional info please do not hesitate to ask. 
 BR, 
 MM

BAlfson · Accepted Answer

" Sophos(with FW, VPN,.. ) with Public IP configured on it=> internet => Cisco ASA 3030 ( again accessible with public IP no FW in between ) " 
 " We see in logs entries from network 172.17.0.0/22&hellip; the addresses should be NATted to 10.x.x.24 " 
 Ahhh, I suspected that that was what they wanted! 
 Everything is fine with the tunnel, they just want you to define it differently. 
 
 The IPsec Connection must have only a Host for the IP 10.?.?.24 in 'Local Networks'. Do not include the subnet 172.17.0.0/22 or any part of it. 
 Do not select 'Strict Routing' in the IPsec Connection. 
 In the Remote Gateway definition, if I understand them correctly, you want to have a Network definition for 10.?.?.70/31 in 'Remote Networks'. 
 Now, to make this all work, you need a rule that NATs traffic into the tunnel: 
 
 SNAT : {172.17.0.0/22} -> Any -> {10.?.?.70/31} : from {10.?.?.24} 
 It sounds like they have two internal IPs that your company needs to reach and they only want to deal with a single IP from your location. This is not an uncommon requirement. Are they happy now? 
 Cheers - Bob

BAlfson · Answer

The 'Any' Service object includes only TCP and UDP, not ICMP or other protocols. When you choose 'Automatic firewall rules', you get the 'Any' object as you can confirm by looking on the 'Firewall' tab. 
 Pinging and Traceroute are regulated on the 'ICMP' tab of 'Firewall', or you can make Firewall rules allowing them in only single directions. 
 Cheers - Bob

BAlfson · Answer

Hi, Stefan, and welcome to the UTM Community! 
 Instead of the "IPsec" Services Group in your firewall rules, you want "Ping" and "Traceroute" - any better luck with those? 
 Cheers - Bob

BAlfson · Answer

This time, I looked back at the earlier posts. If you still have the boxes checked on the 'ICMP' tab and are using 'Automatic Firewall Rules' in the IPsec Connection, then all three of those Firewall rules in your last post can be deleted. 
 I suspect that the trace routes stop where they do because the Comarch device blocks inbound ICMP messages from transiting. 
 Cheers - Bob

BAlfson · Answer

There is no virtual interface in UTM for IPsec tunnels, Matic. I bet the problem is on the Comarch side. Watch the traffic in the tunnel when you try to access things. Assuming that the name of the IPsec Connection is "Comarch" - get its REF_ with: 
 cc get_object_by_name 'ipsec_connection' 'site_to_site' 'Comarch'|grep 'ref' 
 Assume that you found REF_IpsSitComarch , watch traffic in the tunnel with: 
 espdump -n --conn REF_IpsSitComarch -vv 
 What did you learn? 
 Cheers - Bob

BAlfson · Answer

" 188.191.128.1:500 failed " - Good catch! Someone's firewall appears to be blocking port UDP 500 - was that it? 
 I might have seen that in your original post, but skipped over the line because of all the words like REMOTE_IP instead of an obfuscated IP like 188.xxx.yyy.1 or 10.x.y.1 or 192.168.xx.1. Those preserve secrecy but also clearly communicate whether addresses are private or public. 
 Cheers - Bob

UTM 9 and Cisco ASA 3030 IPSec VPN

Submitted a Tech Support Case lately from the Support Portal?