Can ping the X6 interface, but not manage on it

scottrell

Workstation (192.168.20.20) is on the same subnet as the X6 interface (192.168.20.1). Workstation can ping the X6 interface.

Management HTTPS and SSH are dropped. I have enabled HTTPS and SSH management on X6.

Still a basic setup,

I can manage via other interfaces, but not this one.

Workstation firewall is off. tried a different workstation, same results

What's left to look at?

-sc

MasterRoshi

You might have a rule higher up in the stack affecting the traffic. Its also possible there is IP spoofing/asymmetric routing issues.

Can you take a packet capture and see what happens to the traffic?

Teleporter

Are you sure there is a firewall rule allowing Management? On SonicOS 7 check your firewall rules (probably LAN to LAN [if the subnet your workstation is in belongs to the LAN zone]) => Edit rule => optional settings => tick "Allow Management Traffic"

In SonicOS 6 and before the setting is directly in the window where you edit the rule IIRC

Are you sure, you are not connecting to httP://192.168.20.1 but httpS ? This happens to me 25 times a week.

If this does not help: Do you see the login page when you access https://192.168.20.1 ??

Ajishlal

@scottrell

check if there any custom port configured for management interface access.

scottrell

@Teleporter

Hello and thank you, Yes, I did check the LAN to LAN access rules. In this case, this network is segmented on it own interface (X6), and there are all the default rules for SSH management, HTTPS Management, HTTP Management, and Ping.

@Ajishlal

This is pretty much a straight out of the box configuration, from factory defaults. I set up the network segments, and didn't set up a custom port for management. Fortunately I can mange on one of the network segments for the time being, but this isn't a network segment where I'd want to keep that enabled.

scottrell

Also, I have on that interface, enabled automatic redirection of HTTP to HTTPS, and it doesn't even get to that redirection. The browser reports the connection was reset and it is still on HTTP--so it is dropping the attempted connection even before that rule gets applied.

scottrell

@MasterRoshi

Thanks, it wasn't an access rule, but a routing rule in place to deal with multiple default gateways in this legacy network I'm working to migrate away from. The suggestion of asymmetric routes triggered the thought I may still have that rule in place--it would survive a ping but not a stateful connection.

Thank you

-sc