cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
871
Views
0
Helpful
0
Replies
Kevin Sampson
Beginner

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

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!!!

0 REPLIES 0
Content for Community-Ad