cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1223
Views
0
Helpful
3
Replies

site to site issue ASA5510 to Juniper

jsdurstjsdurst
Level 1
Level 1

I've been wrestling with this for awhile.  I only have visibility on my end as the Juniper firewall is owned by another entity.  The VPN was set up and working at one point.  I could initiate a ping from my side, miss first ping while tunnel established, and then the rest were successful.

The crypto map is bidirectional, and allows my network to theirs with ICMP, TCP/3306 and TCP/2509.

The tunnel is currently up, traffic counters incrementing, and devices on their network can reach my network over 2509.  They can no longer ping into my network, nor can I ping into theirs.  The only change that was made was that I needed to add another port, udp8200.  I had them add it along with me and it didnt work.  Thats when we noticed we could not ping either.  I added the port to my crypto map first which I thought would break the tunnel.  (I was under the impression that both sides had to be identical)  But it didnt.  We have since reverted back and the issue remains.

I tried using the packet trace utilitiy and when I source a packet from my network to theirs with a desitnation of tcp/2509, the trace goes as far as VPN lookup- Subtype encrypt- action drop.  Does this mean that my firewall doesnt think the traffic should be encrypted or is it taking into account the negotiated tunnel and perhaps they have something set that is not allowing my traffic in the vpn?  My crypto map is allowing the traffic, and I can not find a reference anywhere else in the running config that would be denying the traffic from entering the tunnel.

Their network space is private, ours is public.  (Obviously their external peer address is public)

Please help!

Jeremy

3 Replies 3

Vikas Saxena
Cisco Employee
Cisco Employee

Hi,

You need to post your crypto config and the packet-tracer data.

Crypto config with port and proto are always complicated. Juniper side is working with filters, you should too, rather than specifying ports and protos in the crypto, configure filters and let the crypto be ip to ip.

-Vikas

Thanks for the reply.

I originally attempted to accomplish this with filters, but couldnt get the tunnel to come up at all.  I'm not familiar with how Juniper handles VPN.  So if the crypto map matches on each end (Which you mentioned the Juniper will likely be all IP) then are the filters required to match in order for the tunnel to come up?)

I found it strange that I could change the crypto map on my side and the tunnel would remain up.

I utilized ASDM to view the packet trace, how do I capture that for posting?  Do I have to utilize command line?  (I usually prefer command line, but in the case of the ASA, ASDM is a savior.)

Okay, I have configured the VPN with a filter.  Now my packet trace does just about the same thing, although an ACL lookup fails instead of a VPN lookup.

The packet trace goes as follows...

Route lookup check

Access-list lookup check

IP options lookup check

Access-list lookup Action Drop.

I can only assume the second access-list lookup is the filter.  But the filter is set to permit. (I've checked and rechecked this, its only 1 line with 3 services.)  Can this be indicative of a deny on their end of the vpn?