Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

One-Way VPN Tunnel Initiation

Status
Not open for further replies.

jrichv

Technical User
Mar 3, 2003
7
0
0
US
Mine: PIX 520 running 6.3(3) with 120+ vpn tunnels up and running; Theirs: PIX 500 series running 6.3(3) with several (a dozen or so) vpn tunnels as well.

Tunnel will initiate and come up normally when they send traffic from the servers on their side to my servers. As long as they initiate the tunnel, I can get to them, and vice-versa. If the tunnel is down, I am not able to bring it up - I get the error message in my debugs:
"IPSEC(sa_initiate): ACL = deny; no sa created" ...???

We have verified phase 1 and 2 parameters, and it is not an acl mismatch - those have been checked many times. PSK's match, etc. - we cannot find a discrepancy in the configs between the two firewalls. Cisco has no answer either - the case has been open a week, and they are back to asking for my configs and debug output. Starting over at square 1...

I can't understand why they can bring the tunnel up, but my side cannot? I've got many vpn tunnels up and running, and have done this many times. Thanks in advance, any and all help is appreciated.

jrichv
 
Did you ever get this resolved? If so, what was the resolution? I'm running into the same thing, and have confirmed the configs more times than I can count - nat, traffic control acls, interesting traffic acls, everything. Still doesn't work...
 
I'm running into this exact same thing! At least now I know I'm not a loonie....

Did either of you solve this problem? Anyone else have any thoughts?



Peter Sherwood

Morrack Consulting
 
I've experienced this problem for years on Pix tunnels but never on any other Cisco vpn product. After much trouble shooting we've resigned ourselves to using ping monitors (or just scheduled pings) to keep the tunnels alive.

Rick
 
I'm trying to recall which incident prompted my message. Uunfortunately, it could have been any one of a number of projects.

I believe that in this case the remote VPN device was hosted by the ISP of our VPN partner. We had open connectivity between the two VPN devices, but we suspected that the ISP had some ACLs which were blocking some ICMP traffic between our partner's server generating the interesting traffic and the ISP hosted VPN device. Once we had the ISP remove all filters between the server and the VPN device, things started working perfectly.

A few suggestions...

Refer to Cisco's docs on troubleshooting IPSec VPNs. They'll help explain the error messages and hopefully point you in the right direction.

Don't take anything for granted in the network path. Try to capture and analyze the traffic at various points in the transmission path, including both ends and in the encrypted tunnel area. Be sure to look at the ICMP traffic. There is no substitute for knowing exactly what's going on.

Don't forget about MTU issues. They can cause you to pull your hair out until you've been through it once or twice and recognize the signs.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top