ClusterXL/HA R65 SSH to passive member

[lodown]

All,

I have found that after a new install of R65 on a HA cluster I am now unable to SSH to the passive member. The traffic is accepted, but a session never starts. This has happened on 3 different sets of clusters built by 2 different engineers, so it is unlikely an operator error. Has anyone else experienced this?

lodown

[Routerkid1]

No please make sure you have a rule above your stealth rule to allow ssh from certain machines or networks.

[lodown]

All of the necessary rules are in place, and ssh was working properly before the move to R65. Ticket has been opened with CP.

lodown

[bglass]

Do a tcpdump on the interface that the SSH connection is going through on the secondary node. It may be hiding its' reply traffic behind the cluster IP causing it to fail. Let me know if that's the case..

[smps200]

Originally Posted by lodown

All,

I have found that after a new install of R65 on a HA cluster I am now unable to SSH to the passive member. The traffic is accepted, but a session never starts. This has happened on 3 different sets of clusters built by 2 different engineers, so it is unlikely an operator error. Has anyone else experienced this?

lodown

i have experienced this . i cant login over ssh into standby node (NGX R61 cluster). I am able to ping it from time to time , like 2 pings are going thru and all others are blocked.
anyone could let me know what this is ? id like to be able to connect onto passive node for backups etc....

[Routerkid1]

delete the cluster object and then create a new policy package.


File copy policy to package.

open the new policy and recreate the cluster object.

[Noidea]

Hello,

We have the same problem. When analysing traffic we saw that the passive member is answering with his VIP adress, which causes the next packet to be routed to the Active member, and therefore the connection fails.

This also makes it impossible to do for example NTP updates from the passive member, as he is going to send out his NTP requests using his VIP as source, and the reply will come to the active member.

sk31607 discribes this issue. This seems to be the case from:

VPN-1 Pro (VPN-1/FW-1) NGX R65
VPN-1 Pro (VPN-1/FW-1) NGX R60 (since HFA_05).
VPN-1 Pro (VPN-1/FW-1) NG with AI R55 HFA_19.

To enable/disable this feature, you have to change the global parameter
fwsm_dlpi_notification from '0' (default value) to 1.

Now... In our case, the parameter IS set to 0 ( default ) but the passive module is still sending out requests from it's VIP.

Anyone an idea?

[crucial]

I often have this same issue. I seem to remember being able to fix it by adding a route, but I don't recall the details. I'd like to figure this out as well.

[Noidea]

The only way we where able to solve it is by creating a nat rule on both modules.

SRC: MODULE DST: ANY PROT ANY / original - original - original

Hope this helps!