Due to port exhaustion I am moving my “desktop” (quoted as it includes some laptops) systems to a secondary switch. This post describes the switch and new VLAN arrangement for these systems.

I recently bought a new NETGEAR “Plus” (I’ll call it “semi managed”) GS105PE switch which has the neat feature of being both POE (802.3at or 802.3af) powered AND passing through up-to 19W(802.3at - 7.9W with 802.3af from which we can infer the switch requires up-to 5W of power) of POE to 2 downstream POE ports. I originally bought it as I sacrificed a physical port in our living room to create a physical end-to-end connection for a HDMI-over-CAT6 device, so needed a switch to plug in the existing POE WAP and Satellite/Cable TV box (which also requires a physical ethernet connection according to the TV provider). Unfortunately the HDMI-over-CAT6 device was rubbish, dropping sound frequently and showing less-frequent but equally annoying intermittent picture corruption, and was returned rendering the switch temporarily redundant.

As our core switch has no free ports, and my new workplace prefer (but do not mandate) physical ethernet over WiFi I decided to repurpose the switch to move most of the 5 machines (including the work laptop) on my desk to it. The HP Microserver, with 2 bonded ports connected, will remain on the core switch, the remainder will fill this little 5-port switch and although I will not be using the POE pass-through day-to-day, it gives me the option to use it to (re)configure (new) POE devices conveniently without having to access the core switch.

Configuring the satellite switch

In common with other NETGEAR Plus switches (I have 2 powered 5-port ones already) the switch has no means of configuring its management interface to a particular VLAN. From observing what happens, it appears that the switch does a DHCP request on every VLAN configured, which makes them very susceptible to a rogue DHCP server on any of them. Reading between the lines, based on what I could find via Google, it seems the switch adopts the IP from the first successful DHCP reply it receives. Although my core switch allows me to create some protections against a rogue DHCP server, the switch is still susceptible to something connected locally (although, as the argument goes, once a bad actor has physical access you have lost the security battle).

On my DHCP server, I set it to have a static IP allocation for its MAC address - the DHCP server shows NAK responses on the incorrect VLANs (with wrong-network in log). Thereafter the switch only appears to attempt to renew the IP on the VLAN it received a valid DHCP response so further DHCP traffic is limited to (in my case) the switch management VLAN.

It is not ideal, there is a window of opportunity for a rogue device on the network to subvert the switch being configured to be only accessed via the management VLAN. As this only occurs at restart and the POE is UPS protected, the switch is unlikely to reboot unexpectedly even in the event of a power failure. Despite this drawback, their semi-managed features such as port-mirroring and crude cable-testing make them very useful for network debugging and auditing as well as the usual logical segregation you would want to use VLANs for.

All of my existing devices are on the main network, although I am creating a new guest vlan for my work laptop (the only difference to the regular guest VLAN being that rate-limiting will not be applied). The switch is therefore normally configured for: Management, Main and Guest-Work VLANs tagged on the uplink (POE power supply) port, Main vlan untagged on ports 1-3 and Guest-Work untagged on port 4 (for work laptop). I can, of course, pull out a system and reconfigure a port if I need (e.g.) management VLAN to setup a new WAP, temporarily.

Configuring the core switch

This is just a case of:

  1. Adding the new VLAN
  2. Changing the port the uplink from this switch is connect to to be a trunk port, with the 3 VLANs as permitted
  3. Reconfiguring the router’s port to permit the new VLAN

or (in configure mode):

vlan 41
name Guest-Work
interface switchport gigabitEthernet 1/0/1
switchport general allowed vlan 41 tagged
interface switchport gigabitEthernet 1/0/18
switchport check ingress
switchport acceptable frame tagged
switchport general allowed vlan 20 tagged
switchport general allowed vlan 10 tagged
switchport general allowed vlan 41 tagged
switchport general allowed vlan 1 untagged
switchport pvid 1
exit
exit
copy running-config startup-config

Configuring the router

I just added a new VLAN interface, a new network configuration to the DHCP server and iptables rules to permit Guest-Work -> Internet access. (Actually, I just added a new network, and the router’s interface to the VLAN, to my SaltStack pillar data and let it do all of this.)