@Chaetura Try set up a static routing 0.0.0.0/0 to your gateway IP.

 

  @Somnus Thanks for your reply. OK, so the switch can now route packets to networks not directly attached to it. How does this help?

 

Let me start off with an example having the kind of specificity that's needed. This example doesn't work. What changes, specifically, will make it work? For this example, I'm using my T1600G-28TS v3 switch. On regular VLAN interfaces, I can access the switch by http, ssh, and telnet as expected.

 

• assign loopback interface of switch to 192.168.88.10/32. "Admin status" is up. The IP is arbitrary but cannot lie within a subnet of any other interface (VLAN). The mask is /32 and cannot be changed.
• IPv4 routing is enabled ("interface" screen).
• all "security" settings are at defaults (off).
• Various VLANs are defined and interfaces are "up". My convention is each VLAN N is on 192.168.N.0/24 where the gateway (and DHCP and DNS) is at N.1 and the switch is at N.10. Currently N={3,6,15,22,23}. Plus two VLANS which deviate from the pattern: N=200 is /25 not /24, and the network for VLAN 1 is 192.168.103.0/24 (instead of 192.168.1.0/24).
• static route 0.0.0.0/0 points to gateway of VLAN 15 (i.e., 192.168.15.1).
• Port 23 is configured to belong to VLAN 1 only (PVID and untagged).
• My machine (Windows 10) has multiple NICs and one is dedicated to testing, connected to port 23. I configure the NIC static 192.168.88.88/24, no gateway, which sets up corresponding route to that subnet. The Windows firewall is completely off (for domain, private, and public networks).
• Ping/http to the loopback address (192.168.88.10). Meanwhile I'm looking at traffic on the test NIC with Wireshark. The test NIC is ARPing for 192.168.88.10 and there is no reply. This makes sense because from the switch's point of view on a /32 network, there are no other hosts on the subnet.

 

Here are examples of things I've tried, starting from the configuration above.

 

From this starting point, I try adding 192.168.88.10/24 as secondary IP for VLAN 1's interface. Refused as expected because "IP address conflicts with an existing one." Try adding 192.168.88.20/24 instead. Same response, can't do that. I remove the static subnet from the interface on VLAN 1 (which was 192.168.103.10/24). As expected, interface status is now "down" even though "enable" is still checked, because it can't be up till it gets an IP address. Retry ping/http to the loopback address. No change, ARPs for the loopback address are sent but no reply, so no connection ever made.

 

OK change strategy. Let's at least get a packet with destination of the loopback interface IP into the switch somehow, instead of just ARPing in vain to discover where to send it. I could define a static ARP on my test machine, but I'll try a more natural way. From the starting point, change the test NIC to static 192.168.103.103/24. No gateway (so as not to mess with my test machine's default routes), but add a static route 192.168.88.0/24 via 192.168.103.103. Now my test NIC is in the switch's VLAN 1 interface's subnet, and ping/http packets addressed to the switch's loopback interface are going to be sent into the switch. If the switch is going to intercept and respond to packets with destination of its loopback interface, it could do that instead of forwarding to the gateway.

 

Here's the relevant part of my test machine's routing table:

  192.168.88.0    255.255.255.0               On-link   192.168.103.103     26
  192.168.88.255  255.255.255.255         On-link   192.168.103.103    281
  192.168.103.0    255.255.255.0             On-link   192.168.103.103    281
  192.168.103.103  255.255.255.255       On-link   192.168.103.103    281

  192.168.103.255  255.255.255.255       On-link   192.168.103.103    281

 

Progress: The switch now answers the ARP for the loopback interface with its own MAC. And http (and ssh) SYN packets get responses back to the test NIC, but this is followed by repeated TCP re-transmits by the test NIC and repeated ACKs. I'm closer, but something's still mis-configured. Help?

From the last configuration described, DELETING the static default route in the switch allows connections (ping, http, ssh, telnet). Restoring it blocks the connections. There's still plenty I don't understand. Having no default route is not a reasonable prerequisite for accessing the switch on a loopback interface. If anyone can add to this knowledge.... I will write and post the missing chapter of switch documention when I have full understanding.

Alternately, turning off (IPv4) routing entirely allows connections. Contacting the loopback interface works from any IP address within the VLAN subnet of the PVID of the port. The VLAN interface needs to be "up." Have not experimented yet with sending tagged packets to contact the loopback interface. Still true that connection works only if (a) routing is OFF, or (b) routing is ON and there is NO default route. Even when routing is OFF the VLAN interface needs to be "up." Stay tuned.