This is driving me insane. I have been trying and trying to get this stupid Site to Site VPN connection up and running.
Confirmed that both sides have the Outside/Inside interface matching and correctly configured. Proposal is confirmed to match as ESP-DES-SHA with DH-Group 1 & pre-shared key and ESP-AES128-SHA with DH-Group 2 & pre-shared key.
Their inside interface is 192.168.0.0/16.
My inside interface is 10.3.2.0/24.
No other inside networks have been added to the VPN connection and both sides match on everything you see above.
ASA5508X-FW1(config)# sh run crypto map
crypto map outside_map 1 match address outside_cryptomap
crypto map outside_map 1 set peer XXX.XXX.XXX.XXX
crypto map outside_map 1 set ikev1 transform-set ESP-DES-SHA ESP-AES-128-SHA
crypto map outside_map interface outside
The other site is in Japan, so I can't physically go there. They're using what appears to be a pretty old Juniper firewall. They're also not open to the idea of changing many of their settings (hence the use of DES and DH-1 and 2) and looks like everything is IKEv1. When I suggested a change to their proposal, they said no, so any changes are pretty much going to have to be on my side.
Tunnel is Up but not passing traffic:
ASA5508X-FW1(config)# show crypto isakmp sa
IKEv1 SAs:
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: XXX.XXX.XXX.XXX
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE
There are no IKEv2 SAs
Here's the Errors I keep getting:
4 Dec 15 2017 03:14:57 210.138.219.67 50.204.254.115 IPSEC: Received an ESP packet (SPI= 0xFBDB975B, sequence number= 0x1D2) from XXX.138.219.67 (user= XXX.138.219.67) to XXX.204.254.115. The decapsulated inner packet doesn't match the negotiated policy in the SA. The packet specifies its destination as 1ae9:75b:1f68:3cd5:db92:ab74:9f8d:b467, its source as 64fa:642f:7d35:4251:e71a:294f:fe9b:61d8, and its protocol as 255. The SA specifies its local proxy as 10.3.2.0/255.255.255.0/ip/0 and its remote_proxy as 192.168.0.0/255.2
4 Dec 15 2017 03:18:37 210.138.219.67 50.204.254.115 IPSEC: Received an ESP packet (SPI= 0xFBDB975B, sequence number= 0x214) from XXX.138.219.67 (user= XXX.138.219.67) to XXX.204.254.115. The decapsulated inner packet doesn't match the negotiated policy in the SA. The packet specifies its destination as 23aa:b7c1:73e6:ab35:2c5b:8ffb:52c9:a7e2, its source as 251c:ffe2:f50b:78df:3aab:5056:2a79:18bb, and its protocol as 255. The SA specifies its local proxy as 10.3.2.0/255.255.255.0/ip/0 and its remote_proxy as 192.168.0.0/255.
6 Dec 15 2017 05:26:04 192.168.221.36 3 Failed to locate egress interface for ICMP from outside:192.168.221.36/3 to 10.3.2.1/0
It's strange that the decapsulated ESP packet would contain IPv6 source and destination using 255 protocol (a reserved and never used tcp/udp port). Since these do not match the settings they set on their end, the thought was that something on my side was mangling things.
One suggestion from a Juniper support forum was to disable VPN Monitoring. Truth be told, I don't know how to do. It sounds like a bad idea, but I'll try anything at this point. Also Japan is saying their setting is "policy based VPN" which I thought was kind of obvious, but maybe I'm missing something. In Juniper speak, does that mean something that I'm not quite comprehending?
Help!!!
