Bait and (Netgear) Switch

Back in April I did a post about the shoestring home network I'd built in my flat at the time, which involved a little 8-port TP-Link switch at the centre of it all. The switch sat between the modem, router, and LAN, and performed some 802.1Q tag juggling to make sure everything was separated properly. After I wrote that post, I also located an unused unmanaged switch in the flat, and chained that off the TP-Link switch with a long cable in order to provide ethernet connectivity to multiple devices on my desk (which is in a separate room).

Just over two months ago, I'd been looking into doing slightly more complex things with the network in my flat, which were beyond the capabilities of the switching gear that I started out with. I wanted to set up a DMZ LAN in the flat, separate from the main access network, as I had a particular machine that I wanted to make internet-accessible, and give shell accounts to a couple of friends. For practical reasons (availability of space and power outlets), this machine needed to sit on my desk along with all the existing devices I had there.

This presented a couple of problems:

I needed a different switch for my desk, as the unmanaged one I was using couldn't manage 802.1Q VLAN tags. Everything connected to my desk switch would turn up on one of the LAN ports on the TP-Link switch.
The TP-Link switch didn't have any way that I could find to restrict access to the management interface to certain ports, which meant that someone with shell access to the machine on the DMZ could potentially get access to the main switch's admin controls, which was undesirable.

My conclusion was that I needed some switches with slightly finer VLAN configuration features to make this work in the way that I wanted. My requirements were something which could manage 802.1Q tags sensibly, and which could restrict access to the management interface. However, having mostly lived in the world of software up until this point, I didn't really know where to start, so I asked a friend for some ideas. They came back with a recommendation for the Netgear GS308T.

This is a reasonably featureful little switch for its price point (as of about two months prior to the time of writing), and it has the added bonus of having an undocumented telnet management interface, in case you prefer configuration via keyboard noises over configuration via clickety-click.

I bought one to take it for a test drive.

Playing with the new toy

My goal with playing with this switch was to work out what the default out-of-the-box settings are like, and how to make it do something which resembles my flat's network (with some VLAN management on different ports).

Setup

Out of the box there's a switch, some info leaflets and a power adaptor. When you turn it on for the first time it'll attempt to acquire an IPv4 address using DHCP, so take a look at the DHCP server logs to find out which address it's on.

When you point a web browser at that address, you'll get redirected to HTTPS with a self-signed certificate. Clicking past the browser warnings gets you to the web interface, with the default credentials being username "admin" and password "password" (which is also marked on the underside of the switch).

Seeing as I generally prefer to work in a terminal, the next port of call is to work out how to enable the telnet console. Head over to the "Maintenance" tab in the web UI, select the "Troubleshooting" sub-tab, and then select the "Remote Diagnostics" item. Turning this on enables a telnet daemon listening on port 60000 on the switch.

The credentials for the telnet interface are the same as the web interface, and by default lands you in an admin shell. If you've used the command line interfaces of other network appliances in the past then the interface might be quite familiar, but this is a new experience for me.

This admin shell will allow you to examine the current state of the switch and perform a couple of other system management commands. If you press question mark with a half-typed command, the shell will print a list of possible completions, which is generally quite helpful for discovering functionality and options.

You can examine the current switch configuration with show running-config. The output from this command is paginated, so press space a few times to get more output.

Entering configure will then take you into configuration mode, which is how the switch's settings are changed. Note that there's no way to stage changes before applying them — any change you make immediately goes live, which I've managed to shoot myself in the foot with more than once. You can leave the configuration mode using exit, too.

You can set the hostname with the aptly named hostname command, for example:

GS308T(config)# hostname sw-1.gb-edi1.6-e.net
sw-1.gb-edi1.6-e.net(config)#

The first thing to do is to change the access credentials and tweak some privileges. By default, logging in as the admin user gives you a privileged admin shell (which gives access to reading and writing the switch's configuration). You can also configure other users who have access to an unprivileged shell (limited to diagnostic functions), and then password-protect access to the privileged mode. The way I've chosen to set this up is to reduce the privileges of the admin user, so that they have an unprivileged shell until they escalate to the privileged mode. So, for example:

sw-1.gb-edi1.6-e.net(config)# username admin privilege user secret hunter2
sw-1.gb-edi1.6-e.net(config)# enable secret hunter3

will set the default privileges for the "admin" user to unprivileged, set their password to "hunter2", and set the password required to access the privileged modes to "hunter3". If you now open another terminal, and then telnet back into the switch, you should be able to log in as the user "admin" using the password just set. You should also have a different prompt, and most of the commands won't be available. However, if you run enable, with the second password, you should then get access to the privileged command mode.

sw-1.gb-edi1.6-e.net> enable
Password: *******
sw-1.gb-edi1.6-e.net# configure
sw-1.gb-edi1.6-e.net(config)#

There are a number of things running on the switch by default which I don't need in my environment. I'm not using spanning-tree protocol, SNMP, or LLDP:

sw-1.gb-edi1.6-e.net(config)# no spanning-tree
sw-1.gb-edi1.6-e.net(config)# no snmp
sw-1.gb-edi1.6-e.net(config)# no lldp

Nor do I intend to use the web configuration interface:

sw-1.gb-edi1.6-e.net(config)# no ip http
sw-1.gb-edi1.6-e.net(config)# no ip https

There's some predefined configuration for the "voice VLAN" feature of these switches, which I believe is something to do with putting VoIP traffic onto separate VLANs with different QoS settings. I don't need this either, so I deleted them with commands like this:

sw-1.gb-edi1.6-e.net(config)# no voice-vlan oui 0

I'm also running my switch on a statically configured IP address. Setting this up is a little delicate, as configuring a new IP address will immediately drop the old one, so you'll need to reconnect to the switch afterwards. For example:

sw-1.gb-edi1.6-e.net(config)# ip address 10.0.2.2 mask 255.255.255.240

VLANs

Logging back into the switch, I can now look into port and VLAN configuration. The command show vlan (when run from an admin shell not in configure mode) will present a little table showing which switchports are members of which VLANs. There are a couple of VLANs which come configured by default (including the magic default VLAN), and you apparently can't deconfigure all of these, so I've just ignored them when numbering the VLANs I intend to actually use.

You have to define VLANs before you use them, using commands like the following:

sw-1.gb-edi1.6-e.net(config)# vlan 30
sw-1.gb-edi1.6-e.net(config-vlan)# name management
sw-1.gb-edi1.6-e.net(config-vlan)# exit
sw-1.gb-edi1.6-e.net(config)#

Naming the VLAN isn't strictly necessary (simply entering the VLAN configuration state and then exiting again is enough to set a VLAN up), but I've done this so that the configuration and diagnostic output has a meaningful identifier associated with each VLAN. I did this with each of the five VLANs I'm going to use (30 through 34 inclusive). The individual switchports on the switch can now be configured too, with the appropriate VLAN tagging and untagging rules.

There appears to be three different modes for the switchports on this switch: "access", "trunk", and "hybrid". My understanding of these is:

"Access" configures a port so that it only accepts untagged frames, and associates all traffic on that port with a given VLAN.
"Trunk" mode seems to behave like the name suggests: tagged frames from multiple different VLANs can be sent and received on the port, so that you can create VLANs which span multiple switches.
The "hybrid" mode allows manual configuration of which VLANs are allowed on which port, what the default VLAN for incoming untagged traffic is, and other filtering policy.

The "hybrid" mode appears to be a superset of both the "access" and "trunk" modes. I'm not totally clear on what the semantics of the "trunk" mode are; the "hybrid" mode is perhaps the most clear, as all the possible control knobs are exposed, and appears to be the default mode for all ports.

Another relevant thing to note is that this switch has a concept of a management VLAN. The management VLAN is the only VLAN on which the switch will answer ARP requests for its IP address, i.e. it's the only VLAN on which you can get access to the management interface. (This functionality was why I bought this switch in the first place!) There's a footgun here though: if you change the management VLAN, and haven't configured any other ports on the management VLAN, then there's no way of logging back into the switch (without power cycling to revert to the boot-time configuration). Changing the management VLAN requires a bit of care.

Out of the box, each switchport is attached to VLAN 1 untagged (the default VLAN on the switch), and the management VLAN is set to VLAN 1, so the management interface can be reached on any port. I'm going to configure this switch so port 1 is for my router (which handles passing traffic between VLANs), port 2 is for the modem (which has both tagged and untagged traffic), port 3 is an access port for my WiFi Access point, and port 8 is a trunk port to a second switch on my desk. I'm also going to change the management VLAN so that only the router can access the switch's management interface, but this needs a little delicacy to prevent locking myself out.

As port 8 is going to end up as the trunk port with access to all the VLANs which need to span to the switch on my desk (including the management VLAN), I've connected my laptop directly into that port for setup and debugging purposes. I've also added a VLAN interface on my laptop, so I can still access the switch when I change the management VLAN setting.

molly on flywheel ~> sudo ip link set eth0 up
molly on flywheel ~> sudo ip link add link eth0 name eth0.30 type vlan id 30
molly on flywheel ~> sudo ip link set eth0.30 up
molly on flywheel ~> sudo ip address add 10.0.2.1/28 dev eth0

To start with, I'm going to turn off all the ports which I'm not using, and I'm going to leave them in "access" mode so they can't be used to accidentally backdoor the other VLANs.

sw-1.gb-edi1.6-e.net(config)# interface range g4-7
sw-1.gb-edi1.6-e.net(config-if-range)# shutdown
sw-1.gb-edi1.6-e.net(config-if-range)# switchport mode access
sw-1.gb-edi1.6-e.net(config-if-range)# exit
sw-1.gb-edi1.6-e.net(config)#

The router's port should have all the VLANs enabled, and shouldn't permit any untagged frames, as my router is an explicit boundary between different VLANs, and shouldn't be sending untagged traffic.

sw-1.gb-edi1.6-e.net(config)# interface g1
sw-1.gb-edi1.6-e.net(config-if)# switchport mode hybrid 
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid ingress-filtering
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid acceptable-frame-type tagged-only
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid allowed vlan add 30-34 tagged
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid allowed vlan remove 1
sw-1.gb-edi1.6-e.net(config-if)# exit
sw-1.gb-edi1.6-e.net(config)#

Ingress filtering isn't enabled by default on these switches and needs to be turned on explicitly. Without this, the switch would accept frames coming in on this port tagged with a VLAN which isn't in the list of VLANs which are sent out on this port. I've also explicitly removed the default VLAN 1 from the access list on this port, as it's otherwise added implicitly (which you can check with show vlan).

The modem's port is a bit more interesting. On the modem's side, frames tagged with VLAN ID 32 will be forward to the upstream interface talking to the ISP (and traffic received from the ISP will be tagged with VLAN 32 before being sent onto the LAN port). Untagged traffic can talk to the modem directly, which is how the modem's management interface is reached, however once again I want this to only be accessible to my router.

The switch therefore needs to be configured so that the modem can send and receive frames on VLAN 32, and put any untagged traffic onto a management VLAN which only the router has access to.

sw-1.gb-edi1.6-e.net(config)# interface g2
sw-1.gb-edi1.6-e.net(config-if)# switchport mode hybrid 
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid pvid 31
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid ingress-filtering
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid allowed vlan add 32 tagged
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid allowed vlan add 31 untagged
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid allowed vlan remove 1
sw-1.gb-edi1.6-e.net(config-if)# exit
sw-1.gb-edi1.6-e.net(config)#

Note that I've set the port VLAN ID here to 31, so all untagged inbound traffic gets pulled into VLAN 31. By default the switch accepts both tagged and untagged frames in hybrid mode, so I don't need to configure this explicitly.

Port 3 is an access port for my WiFi access point. The access point doesn't have any useful 802.1Q capabilities, so I've just left it on the LAN with a static IP address assigned.

sw-1.gb-edi1.6-e.net(config)# interface g3
sw-1.gb-edi1.6-e.net(config-if)# switchport mode access
sw-1.gb-edi1.6-e.net(config-if)# switchport access vlan 33
sw-1.gb-edi1.6-e.net(config-if)# exit
sw-1.gb-edi1.6-e.net(config)#

Port 8 is the trunk port, and it's also the one I've got my laptop plugged into. This requires a little bit of care, as getting the configuration wrong here will lock me out of the switch on this port. To start off, I've added the VLANs to the port:

sw-1.gb-edi1.6-e.net(config)# interface g8
sw-1.gb-edi1.6-e.net(config-if)# switchport mode hybrid
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid allowed vlan add 30,33-34 tagged
sw-1.gb-edi1.6-e.net(config-if)# exit
sw-1.gb-edi1.6-e.net(config)#

Now I'm going to change the management VLAN to ID 30:

sw-1.gb-edi1.6-e.net(config)# management-vlan vlan 30

At this point, my telnet session to the switch hung, however I moved my laptop's IP address from the ethernet interface to the tagged VLAN interface:

molly on flywheel ~> sudo ip address del 10.0.2.1/28 dev eth0
molly on flywheel ~> sudo ip address add 10.0.2.1/28 dev eth0.30

If this is timed correctly, the telnet session's TCP connection will resume, and you'll be able to continue working on the switch without reconnecting. It's a nice trick when it works, but it only costs a few moments of time if you do need to disconnect and reconnect.

The trunk port's configuration can then be finished off, by removing VLAN 1 from the access list, and enabling some filtering policy:

sw-1.gb-edi1.6-e.net(config)# interface g8
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid allowed vlan remove 1
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid ingress-filtering
sw-1.gb-edi1.6-e.net(config-if)# switchport hybrid acceptable-frame-type tagged-only
sw-1.gb-edi1.6-e.net(config-if)# exit
sw-1.gb-edi1.6-e.net(config)# exit
sw-1.gb-edi1.6-e.net#

Once all of this is set up, the last thing to do is to save the configuration, so that it persists when the switch is rebooted.

sw-1.gb-edi1.6-e.net# save
Success
sw-1.gb-edi1.6-e.net#

Conclusions

This one's a keeper — I'm very happy with this switch, and I bought a second one to complement the one I configured above. A pair of these switches has satisfied my requirements quite nicely, and I now have my DMZ network set up the way I want it.

Changelog