- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: IPSec VPN Connection terminated
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IPSec VPN Connection terminated
We recently faced with an issue on all our IPSec VPN's. We have around 10 Site to Site IPSec VPN's with different third parties. All tunnels are up on both phases. But on some tunnles, our ED's can't reach the Remote ED with an error of "Connection terminated before detection: Insufficient data passed. To learn more see sk113479."
But before we all able to reach the remote ED's from our local ED's. Now, The remote ED can able to reach to our Local ED. Below you can find the screenshot.
What could cause this? Any suggestion will be appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In laymans terms, all that sk is literally telling you is that 3 way handshake is not happening, so you would definitely need to run captures to figure out why. In my experience, its usually not CP issue.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@the_rock
What kidn of captures should I ran
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You will see few commands at the bottom of the file I attached.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What version/JHF are the gateways and management?
What is the exact nature of the traffic?
What are the exact Access Policy rules being used to permit traffic in these cases?
The “fix” for this is to ensure rules that match on the first packet are used (ie must be a simple TCP/UDP service).
This is basically what sk113479 says.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@PhoneBoy @the_rock
May be If the below description helps.
JHF Take 197 is installed on both Gaeywats and the management server
One scenario may be helping in this case is we have a IPSec tunnel with a third party with 3 Local ED's and 6 Remote ED's of different subnets on the same peer. Previosuly, on the tunnel managment option of VPN Community, One VPN Tunnel per subnet pair is selected. And at a time 1 ED is working and all other ED's are down on phase 2. Then I have selected One VPN tunnel per gateway pair, and now all the ED's are UP on phase 2.
All 6 Remote ED's are reaching our Local ED's But Our local ED's ca't reach the Remote ED's. The partner said the traffic is not reaching their destination. When I checked from checkpoint Log it shows Connection terminated.
Does selecting VPN tunnel per gateway pair have an impact?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe you would select that option per gateway if you use mix of hosts and subnets. I also see customers use it when having Azure or AWS tunnel thats permanent route based.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@the_rock
What about this one? All 6 Remote ED's are reaching our Local ED's But Our local ED's can't reach the Remote ED's. The partner said the traffic is not reaching their destination. When I checked from checkpoint Log it shows Connection terminated.
How can I fix the connection terminated. Insufficient Data Passed error
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Understood. What does it show from fw monitor? At what point does the connection terminate?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Below is the output from fwmonitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks @gemechisd , will review it later. Can you please indicate affected IP addresses? ie your end, their end?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Local ED: 10.100.140.35 & 10.1.175.111
Remote ED: 102.318.58.83 & 10.0.103.8
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, so I see from your screencap that i and I are happening on eth1-02 and o on eth1...is that expected? You probably wont see big O since connection would be encrypted.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@the_rock
eth1 & eth1-02.
eth1 is when I try to ping the Remote Host.
eth1-02 is when I try to telnet the Remote Host.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By the way, did you ever end up opening TAC case for this?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@the_rock
I haven't opened a TAC Case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think it might be a good idea at this point, as its possible this will require further debugging.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The VPN configuration is only relevant insofar as the actual Access Policy rules used to allow the relevant traffic, which you did not provide here.
Please provide screenshots (sensitive details redacted).
The services used in the rules should NOT be redacted.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any APPC/URLF rule matched for that traffic?
If so, try to put a rule for the affected traffic with Action accept on top inside the layer (or in-line layer) for APPC/URLF rulebase
