L2L Connection ASA 5508X to Juniper SRX - Tunnel is Up, Traffic not Passing
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
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 18.104.22.168 22.214.171.124 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 126.96.36.199 188.8.131.52 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?
In this episode of Unhackable, Mike Storm (@mistorm) with his co-host and producer, Sean discuss the Unhackable Principle: Authentication. This is where they talk about passwords, multi-factor authentication, and what it takes to keep you safe when you ...
With the enhancements in ISE 3.0 for integrating with Azure AD via SAML IdP, it is now possible to leverage Microsoft Single Sign-On for multiple ISE Portals (for example Sponsor and Guest/BYOD Portals).
At the time of this writing, ISE cann...
With the enhancements in ISE 3.0 for integrating with Azure AD via SAML IdP, it is now possible to create a BYOD Flow to provide Wireless network access using an employee’s Azure AD credentials.
The use of Azure AD credentials is an alterna...
The table below shows the whole Cisco Security solutions + Splunk integrations add-ons. Kindly let me know if I have missed some add-ons or if there are any new updates. Thank you!
Hope this will be helpful for everyone who is looking for Splunk in...