Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
lbcadenco10
Contributor
Jump to solution

Cannot Access Active Cluster Member via HTTPS/SSH Over VPN

I can access the MGMT interface of active and standby cluster members via ICMP over the VPN but not SSH or HTTPS. Their is an SMS that sits behind these GWs and I can reach the SMS via ICMP, SSH and HTTPS. As the SMS is on the same MGMT network as the GWs, I can also access the GWs ia ICMP, SSH and HTTPS (using telnet) from the SMS.

 

I'm aware of sk42695, sk42733 and sk93204 which could explain the behavior of the standby cluster member but it's odd that I'm able to ping both units. So I don't think any of those sk's apply plus I would expect to be able to access the active cluster member without issue. I also have a another 5100 cluster that works with the same configuration.

 

The firewalls logs show traffic being allowed, encrypted/decrypted and I don't see any drops via "fw ctl zdebug drop" on either cluster member. A packet capture also shows the SSH/HTTPS traffic ingressing eth1 where the VPN is terminated but I only see a SYN with no ACK or further traffic. There are no host restrictions per the statement "add allowed-client host any-host".

 

Any ideas on where I can look to troubleshoot further? I'm not seeing any noticeable in /var/log/messages.

 

GWs are running R80.20 JHF Take 87.

0 Kudos
1 Solution

Accepted Solutions
lbcadenco10
Contributor
Just wanted to note for anyone that stumbles across this post in the future, upgrading to the latest GA JHF, Take 141, resolved this issue. TAC noted a number of improvements to SecureXL and VPNs between Take 87 and Take 141.

View solution in original post

0 Kudos
5 Replies
PhoneBoy
Admin
Admin
I would get the TAC involved here.
lbcadenco10
Contributor
Thanks! I went and opened a case. I'll follow up with our findings
0 Kudos
lbcadenco10
Contributor
Update - opened a case with TAC and so far it's looking like an issue with SecureXL as disabling it resolves the issue. After re-enabling the issue is resolved temporarily but reverts to the same behavior within 24 hours. I'll be collecting debugs to assist TAC in tracking down the issue.
0 Kudos
PhoneBoy
Admin
Admin
Yup, anytime you need to disable SecureXL to "fix" something, it's a bug.
0 Kudos
lbcadenco10
Contributor
Just wanted to note for anyone that stumbles across this post in the future, upgrading to the latest GA JHF, Take 141, resolved this issue. TAC noted a number of improvements to SecureXL and VPNs between Take 87 and Take 141.
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events