• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 495
  • Last Modified:

VPN tunnel won't set up from one side?

We had a VPN tunnel from our Cisco firewall going to the firewall of another party, and it's been working fine for quite some time.  However, the other party recently requested that we change the peer address, due to them making some changes with their internet provider.

We changed the address in the config, in all places that the old address existed.  We also adjusted the access lists and any other areas where you'd find the old address.

Now, we are unable to initiate VPN traffic from our side.  The other side can bring the tunnel up, and it stays up for the length of it's keepalive, but then it times out, and we're dead again.

Since the tunnel can be brought up from the other side, it stands to reason that the security is still correct, the peer IP address is good, etc.  The other side claims to be configured for bi-directional setup.

Any thoughts as to why we can't bring up the tunnel from our side now, when all that's changed is the peer?
0
aptnetworks
Asked:
aptnetworks
  • 4
  • 2
1 Solution
 
QlemoC++ DeveloperCommented:
Being non-Cisco'si, I can not get into the details, but is seems obvious that you have a more generous config then they have. Your device is accepting the negotiated proposals and encryption domain, while that is not the same in reverse. You only know for sure if you compare what they negotiate (with the debug command on connect, and getting the negotiated SA parameters when established). The same should be done on their device.
0
 
aptnetworksAuthor Commented:
We're going to try to debug the setup attempt, but honestly, doing so is a bit over my head, as far as reading and interpreting the results.
0
 
QlemoC++ DeveloperCommented:
First you need to know if the issue is in Phase 1 or Phase 2. It might be something simple as the old public IP expected, but the new sent, as part of the Local ID negotiation in Phase 1.
I'm (almost) certain that it is a configuration error on the other site. Sadly, only the responder side of an IPSec tunnel l will show the necessary details for rejecting a connection.

It might be easier to just look at the negotiated parameters on your site, after the tunnel is established from the other site. The SAs of both phases should show you which parameters where negotiated successfully. Compare those with what you have set up to detect the difference.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
aptnetworksAuthor Commented:
Turns out the other side has PFS turned on, but we didn't.  Since he built a new router and a new config, it's possible that they added that and just didn't tell us.  He disabled PFS, and the tunnel came up.

Thanks!
0
 
QlemoC++ DeveloperCommented:
Strange it worked one way then - it should not. Wrong PFS is detected at latest when payload packets are exchanged.
0
 
QlemoC++ DeveloperCommented:
This question has been classified as abandoned and is being closed as part of the Cleanup Program. See my comment at the end of the question for more details.
0

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now