cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3165
Views
0
Helpful
7
Replies

ASA or 871 ipsec l2l to SSG-140: tunnel is up, but no traffic

Ton V Engelen
Level 3
Level 3

Hi

i am curently troubleshooting a ipsec l2l VPN between

1. ASA 7.2(4) to SSG-140

2. Cisco 871W to SSG-140

In both scenario's the tunnel is nicely established, and traffic goes into the tunnel, but nothing comes out. All encap's, but no decap's                    

It seems like a routing issue, but we can not find anything on both sites.

So maybe i m running into a (known) issue between cisco VPN equipment and the SSG-140?

I ve searched the forum, but did not find a clue to this issue.

If anyone has an idea its most welcome.

Could it be a proxy-id issue? Cause they configure stuff like 10.1.1.0/24 and i configure 10.1.1.0 0.0.0.255

Thanks in advance!

1 Accepted Solution

Accepted Solutions

Tom, I haven't seen the uploaded configs or displays. I would concentrate on the asa as its easier to troubleshoot. You can use the packet tracer facility to verify that the syn is sent via the outside interface and encrypted. You also have the capture facility. The problem of course is that the traffic is encrypted. A syn packet is small and difficult to tell apart. Try sending 10 ping at 1000 pkt size and see if you can locate them in the capture (ipsec will add about 80 bytes). You might need to do it at a quiet time to make it easier. Assuming that you can identify the packets, you can repeat the capture and get someone to do the same at the remote end. Also try making the ping from the remote device and see if you can capture the packets. My guess is that there is something amiss at the other end or a firewall dropping the esp packets (ip prot 50). If you want to send config, displays, captures to mwinnett@cisco.com I can take a look. Matthew

View solution in original post

7 Replies 7

mwinnett
Level 3
Level 3

Tom, I would definitely check that the proxy-ids (and all other settings) are the same on each side. I have seen 3rd party equipment this is configured for a subnet but actually bring up host proxy-ids for each src/dst pair. I checked a number of cases and all were fixed by config changes (usually at the Juniper side, so I don't know what was done), but the bottom line is that it can be made to work. Make sure that you have catered for NAT (Cisco does nat before encrypt going outbound, reversed inbound). Does the reference to "All encap's, but no decap's" refer to the Cisco end or both ends ? No real magic, pick a known stream and capture at either end and follow the trail. Matthew

Hi, Matthew,

thanks for your reply!

Proxy-id's were checked, and seem ok. VPN tunnel is up, phase 1 and 2 are ok. 

I ve send over my configs and debugs plus a drawing to the other company. I hope they will be able to find something in their configs.

I m doing an export ip traffic of the outside interface and sending it to my laptop to wireshark, but all i see the traffic being send, no return traffic, except a couple of isakmp informational packets from the other side after i do some pings to the destination behind the tunnel.

If i do "debug ip packet 101 detail",  i can see the packet is send , with the correct source and destination, correct port numbers, correct gw, and this ends with a SYN being send,  waiting for the SYN ACK, which never arrives.

Also if i do a "debug crypto engine packet" i can see the packets before and after encryption and that then the packet is fast switched.

"debug crypto engine error" retuns nothing. Seems to be in order.

So, waiting here for the other side...cause i ran out of idea's anyway.

Thanks again!

Tom, I haven't seen the uploaded configs or displays. I would concentrate on the asa as its easier to troubleshoot. You can use the packet tracer facility to verify that the syn is sent via the outside interface and encrypted. You also have the capture facility. The problem of course is that the traffic is encrypted. A syn packet is small and difficult to tell apart. Try sending 10 ping at 1000 pkt size and see if you can locate them in the capture (ipsec will add about 80 bytes). You might need to do it at a quiet time to make it easier. Assuming that you can identify the packets, you can repeat the capture and get someone to do the same at the remote end. Also try making the ping from the remote device and see if you can capture the packets. My guess is that there is something amiss at the other end or a firewall dropping the esp packets (ip prot 50). If you want to send config, displays, captures to mwinnett@cisco.com I can take a look. Matthew

Hi, Matthew

thats very generous of you, thanks a lot. I think i will send some stuff over.

The tunnel is now setup between the 871 and the SSG.

When it was set up between the ASA and the SSG i did use the packet tracer and its output said 100% succesfull.

ACL lookup, VPN lookup, routing lookup etc > all ok.

Because i could run a test here with two 871's which worked fine as for ipsec VPN, i am using the 871 now (cause i ve seen it work) .

And 1 step further now:

Right now i can see packtes come in and go out (encaps and decaps) from the site where the SSG is situated.

He sends a continuous ping from the webserver to my laptop through the tunnel. These are the encaps end decaps i see. The requests reach my laptop,ut the reply doesn t reach the webserver, they get lost in the tunnel. .

So traffic is traversing the tunnel (one way it seems) . I can see the icmp requests from the webserver (and replies) in wireshark, as i export ip traffic to my laptop.

I will ask the other party if it is ok if i send the SSG config to you. if, ok, i will send over a drawing and both configs.

Thanks a lot btw!!

johnnykaye
Level 1
Level 1

"i configure 10.1.1.0 0.0.0.255"

Hi,

a small detail, just in case:

ASA and PIX require straightforward subnet masks for ACLs, rather than the wildcard masks used in Cisco IOS. Also, whereas Cisco IOS will let you enter a subnet mask and then translate it into a wildcard mask for you, PIX/ASA is not as forgiving.

Best,

Johnny

Hi, thanks for your reply.

I m aware of this, i work with both types of devices

And IOS will not translate like that.

If you configure

ip access-list ext 101

     permit ip 10.1.1.0 255.255.255.0 host 30.40.50.50

you will end up with an acl which would be something like

     ip access-list ext 101 permit ip 0.0.0.0 255.255.255.0 any

That is not the issue here, but thanks anyway!

Matthew analysed the problem and got it fixed.

The problem was in the firewall > i had to open protocol 50 (esp) instead of udp 50

@Matthew, a 1000 thanks!!

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: