Failed SSH connection in ClusterXL HA

[Matlu]

Hello,

I have a curiosity, is there any way to "validate" which port is the one configured to access by SSH to my GW Cluster?

I have a legacy architecture, I have 2 GW, which its management IP is 192.168.61.2 and 192.168.61.3, but when you try to log in by SSH (Putty, etc), it fails to connect.

The only way to connect is "jumping" from the SMS, but we want to document why we can not access directly to the GW.

Maybe they "changed" the SSH port, or simply something is "failing" that does not allow us to connect directly.

Hopefully someone can give me some troubleshooting tips.

Thanks. 🙂

[the_rock]

You can check /etc/ssh/sshd_config file bro.

Kind regards,

Andy

[Matlu]

I have reviewed the basics so far,

We have a firewall rule that allows SSH connection to ClusterXL HA members.

We are trying to connect via RA VPN.

Our RA VPN segment is allowed in the VPN Domain of the RA VPN community, but what I have "noticed" is that when we are connected to the VPN, we do not get the route to manage the 192.168.61.x segment.

We consult the route table on each PC, with the command "route print".

In the LOGS nothing is seen (as if no traffic attempt is generated by SSH), and the "FW CTL ZDEBUG + DROP | GREP IP", does not tell us anything wrong.

Greetings.

[the_rock]

What does route print show? If such a route is missing on the firewall, then it wont get "injected" when clients connect either.

Andy

[Matlu]

We have a rule, where our origin is the segment of the RA VPN connections, and the destination is the GW of the Cluster.

Destination IPs: 192.168.61.2 and x.x.61.3

The route print does not show me this segment, for some strange reason.
I guess that's why we can't reach both GWs, but the strangest thing is that both IPs are within the VPN Domain of the RA VPN community.

The only way to access the GWs is jumping from the SMS.

I share a txt with what it shows me at the level of a connected user.

[the_rock]

Whats mgmt IP? Can you send route print?

Andy

[Matlu]

I share with you the "route print" from a remote user connection.

[the_rock]

Routing is your issue, there is nothing for 192.168.61.x subnet. Check proper route exists for it on the cluster.

Andy

[Matlu]

To fix the route, from what "perspective", from the same GW of the Cluster?

Because those IPs, 192.168.61.2 and x.x.x.3, belong to the GWs,
They are their management IPs.

You mean validate the route, to reach the network of my VPN remote user connection pool, 192.168.9.0?

I did not understand that last part of your comment.

Sorry, Buddy

[the_rock]

The vpn clients are not getting route to that subnet because its not getting propagated from the gateway itself. I would call TAC and do a quick remote for this, Im sure its something simple missing.

Andy