cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3372
Views
25
Helpful
18
Replies

VPN Site to Site Connection ASA 5508X to Juniper SRX

Kevin Sampson
Level 1
Level 1

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

18 Replies 18

Hi

What about show crypto ipsec sa?

 

 

 

-If I helped you somehow, please, rate it as useful.-

Sure thing. 

 

GSI-ASA5508X-FW1(config)# sh crypto ipsec sa
interface: outside
Crypto map tag: outside_map, seq num: 1, local addr: XX.204.254.115

access-list outside_cryptomap extended permit ip 10.3.2.0 255.255.255.0 192.168.0.0 255.255.0.0
local ident (addr/mask/prot/port): (10.3.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
current_peer: 210.138.219.67


#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 6751, #pkts decrypt: 6751, #pkts verify: 6751
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: XXX.204.254.115/0, remote crypto endpt.: XXX.138.219.67/0
path mtu 1500, ipsec overhead 58(36), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: CDDE8719
current inbound spi : 19E15DA1

inbound esp sas:
spi: 0x19E15DA1 (434199969)
transform: esp-des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 65536, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 3534
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00003FFF
outbound esp sas:
spi: 0xCDDE8719 (3453912857)
transform: esp-des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 65536, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 3533
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

Hello @Kevin Sampson

 

You are receiving packets from the other side but you are not sending anything to them, can you verify with a packet-tracer?

 

packet-tracer input inside icmp 10.3.2.21 8 0 192.168.0.21 detailed

 

Gio

Actually that makes perfect sense. This is a migration from one parent company to another and I'm working on setting a L2L to the new parent company. I have a nifty new firewall, but there's nothing behind it the firewall so there's nothing sending data in their direction, other than the firewall itself of course. 

 

I'll try to come up with something to throw traffic in their direction. 

 

As far as verifying with packet tracer, I'm not sure how to do that under the circumstances. I have packet tracer -- that nifty little network emulator. But I've never connected it to a live environment. 

The "packet-tracer" Flavio suggested is the built-in CLI utility on the ASA - not the external emulation tool used by Cisco Networking Academy. that said, your end is probably fine.

 

Based on what you are seeing, I would suspect that they have not setup their end properly to exempt their traffic towards you from NAT. That would explain why their IPv4 traffic is being put into the IPsec tunnel with an IPv6 address - it is being NATted when it shouldn't be.

 

This is a common problem when dealing with policy-based site-site VPNs on Juniper devices. There are a couple of articles that I found mentioning it and offering tips on configuring the Juniper end properly. See the following:

 

https://forums.juniper.net/t5/SRX-Services-Gateway/Policy-based-VPN-with-NAT/td-p/31699

 

https://www.fir3net.com/Firewalls/Juniper/juniper-srx-vpn-nat-issue.html

Awesome response. Thanks so much! I was trying and trying to figure out how "the egg got scrambled before I cracked it open" and that makes a ton more sense. 

 

Just so I can rule out everything on my side (and because I had to swap out the router unexpectedly) here's what I look like presently. 

 

GSI-ASA5508X-FW1(config)# sh nat

Auto NAT Policies (Section 2)
1 (any) to (outside) source dynamic obj_any interface
translate_hits = 0, untranslate_hits = 0

Manual NAT Policies (Section 3)
1 (Management) to (outside) source dynamic any interface
translate_hits = 0, untranslate_hits = 0


GSI-ASA5508X-FW1(config)# sh run crypto map
crypto map outside_map 1 match address outside_cryptomap
crypto map outside_map 1 set peer XXX.138.219.67
crypto map outside_map 1 set ikev1 transform-set ESP-DES-SHA ESP-AES-128-SHA
crypto map outside_map interface outside

 

GSI-ASA5508X-FW1(config)# sh 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.138.219.67
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE

There are no IKEv2 SAs
GSI-ASA5508X-FW1(config)#

 

GSI-ASA5508X-FW1(config)# sh crypto ipsec sa
interface: outside
Crypto map tag: outside_map, seq num: 1, local addr: XXX.204.254.115

access-list outside_cryptomap extended permit ip 10.3.2.0 255.255.255.0 192.168.0.0 255.255.0.0
local ident (addr/mask/prot/port): (10.3.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
current_peer: XXX.138.219.67


#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 275, #pkts decrypt: 275, #pkts verify: 275
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 50.204.254.115/0, remote crypto endpt.: XXX.138.219.67/0
path mtu 1500, ipsec overhead 58(36), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: CDDE8862
current inbound spi : D73C7B7A

inbound esp sas:
spi: 0xD73C7B7A (3611065210)
SA State: active
transform: esp-des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 21561344, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (3914983/2207)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0xCDDE8862 (3453913186)
SA State: active
transform: esp-des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 21561344, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (3915000/2205)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

GSI-ASA5508X-FW1(config)#

 

I'm back to where I was on a fresh new router ... again. What are the steps to doing what Flavio suggested? I certainly want to be 100% sure that I fix all possible issues on my end of this thing. I've probably done it at some point in years past, but I don't remember it. 

 

Thanks to both of you! Site to Site Tunneling with ASA and SRX is a bigger mess than I'd imagined. 

You're welcome.

 

I'd just double check the ASA logic with the packet-tracer command Flavio suggested.

 

The packet-tracer utility injects a synthetic frame into the ASA originating at the specified input interface and follows it through the packet processing flow of the ASA. It's a great tool for validating your configuration logic,

I'm not sure that it's looking particularly good. Looks like stuff is getting dropped before it even leaves my firewall ... if I'm reading this right. 

 

Access Lists: 

access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
alert-interval 300
access-list outside_cryptomap; 1 elements; name hash: 0x39bea18f
access-list outside_cryptomap line 1 extended permit ip object-group GSI object-group Nissha (hitcnt=39) 0xb429b5fb
access-list outside_cryptomap line 1 extended permit ip 10.3.2.0 255.255.255.0 192.168.0.0 255.255.0.0 (hitcnt=39) 0x35490439

 

NAT

Auto NAT Policies (Section 2)
1 (any) to (outside) source dynamic obj_any interface
translate_hits = 8, untranslate_hits = 9

Manual NAT Policies (Section 3)
1 (Management) to (outside) source dynamic any interface
translate_hits = 0, untranslate_hits = 0

Hits on the crypto map ACL are a good thing - they indicate that the ASA is seeing “interesting traffic” and will be encapsulating it into the tunnel. 

You'll have to excuse my silly mistake. I had a wrong interface in a NAT rule. Like I said, I just swapped out the firewall and was in a hurry to copy everything over. 

 

By the way, what the heck is "Code" in a ICMP packet? Sounds like an incredibly ambiguous item. 

ICMP message types and codes are well-documented. A good overview can be found in the Wikipedia article here:

 

https://en.m.wikipedia.org/wiki/Internet_Control_Message_Protocol#Control_messages

 

Packet-tracer output is best viewed from the cli (or via expanding the tree branches in the GUI) so that we can confirm we are hitting the expected access-lists and NAT rules. Those are equally if not more important than the final outcome. 

Yeah the trouble was that my console cable fell off of the device I had it plugged into. I was working from home and was relying on RDP'ing in. Then again, I could have used the CLI built into ASDM ... Anyways, here you go: 


GSI-ASA5508X-FW1(config)# packet-tracer input inside icmp 10.3.2.155 0 0 192.1$

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static GSI GSI destination static Nissha Nissha no-proxy-arp
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.223.251/0 to 192.168.223.251/0

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit ip any any
Additional Information:

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static GSI GSI destination static Nissha Nissha no-proxy-arp
Additional Information:
Static translate 10.3.2.155/0 to 10.3.2.155/0

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static GSI GSI destination static Nissha Nissha no-proxy-arp
Additional Information:

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 9277, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Hello @Kevin Sampson,

 

So everything should be working fine now, check the traffic with a ping and verify the command "show crypto ipsec sa". 

 

Gio

Hello @Kevin Sampson

 

Based on your screenshots from the packet-tracer you ran is that you are missing the NAT Exemption for the traffic, this specific traffic is being translated to the PAT you have for Internet access and that´s why you are sending the traffic to the Internet and not through the VPN tunnel. 

 

Your NAT Exemption should look something like this: 

 

nat (inside,outside) source static obj-10.3.2.x obj-10.3.2.x destination static obj-192.168.223.x obj-192.168.223.x no-proxy-arp route-lookup

 

After you apply this command you should be able to send the traffic through the VPN tunnel and everything should work as expected. 

 

HTH

Gio

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: