Setting inter-VLAN communication in Netgear ProSafe switches

Arseni Mourzenko
Founder and lead developer
177
articles
January 17, 2021
Tags: security 8 network 1

Re­cent­ly, I was try­ing to con­fig­ure VLANs in or­der to cre­ate more log­i­cal net­work view and in­crease the se­cu­ri­ty of the net­work by lim­it­ing the traf­fic from the dif­fer­ent types of ma­chines through the router ACLs. In or­der to do that, I had two lev­el-3 switch­es: Net­gear ProSafe GS728TS and Net­gear ProSafe GS516TP.

With my ba­sic un­der­stand­ing of VLANs, I thought it would be sim­ple to do the change, but un­for­tu­nate­ly, the web-based ad­min­is­tra­tion pan­el of the switch­es made it much more cryp­tic and com­plex com­pared to what can be done with Cis­co IOS.

This ar­ti­cle de­scribes the fi­nal, step by step pro­ce­dure to fol­low to set­up VLANs on the switch. The idea is to be able to have sep­a­rate VLANs where:

  1. Any de­vice can com­mu­ni­cate with de­vices from oth­er VLANs, un­less pre­vent­ed by switch­es' ACLs.
  2. A de­vice from one VLAN can­not eaves­drop on com­mu­ni­ca­tions be­tween de­vices from oth­er VLANs.

This is, es­sen­tial­ly, the most cur­rent need for small busi­ness­es and soft­ware de­vel­op­ers. One of the goals, for in­stance, is to keep the pro­duc­tion servers apart from, say, Wi-Fi de­vices, while al­low­ing both the servers and the Wi-Fi de­vices to com­mu­ni­cate with each oth­er and to ac­cess the In­ter­net.

Set­ting up VLANs

In lab, use GS516TP and three Lin­ux ma­chines named m0, m1, and m2, con­nect­ed like this:

Here's the ini­tial con­fig­u­ra­tion of m0, that doesn't use the VLANs yet (since they are not yet con­fig­ured):

auto eth0
iface eth0 inet static
address 192.168.0.2
gateway 192.168.0.239
netmask 255.255.0.0

Fac­to­ry-re­set the switch, then go to 192.168.0.239 (the de­fault IP of the switch) from m0.

Go to Se­cu­ri­ty › Ac­cess › HTTP Con­fig­u­ra­tion. Set HTTP ses­sion soft time­out to 60 min­utes.

Go to Rout­ing › VLAN › VLAN Rout­ing Wiz­ard and cre­ate three VLANs:

Con­fig­ure m1 to use VLAN 11, like this:

auto eth0
iface eth0 inet static
address 192.168.11.2
gateway 192.168.11.1
netmask 255.255.0.0

Sim­i­lar­ly, m2 would look like this:

auto eth0
iface eth0 inet static
address 192.168.12.2
gateway 192.168.12.1
netmask 255.255.0.0

Re­boot m1 and m2, and ac­cess the con­fig­u­ra­tion page of the switch from m1 at 192.168.11.1.

Un­plug m0 from port g1 and con­nect it to the port g10:

The ma­chine shouldn't be able to con­nect, since the port is con­fig­ured as VLAN 10, and the IP ad­dress of the ma­chine is in­valid for this VLAN. Re­con­fig­ure m0 like this:

auto eth0
iface eth0 inet static
address 192.168.10.2
gateway 192.168.10.1
netmask 255.255.0.0

Re­boot m1. This time, it should be able to con­nect. A ping from one ma­chine to an­oth­er should work, but shouldn't be trace­able from a third ma­chine. For in­stance, m0 $ ping 192.168.11.2 should work, but a Wire­shark dump run­ning from m2 shouldn't show any of the pack­ets.

The switch is prop­er­ly rout­ing the pack­ets from one VLAN to an­oth­er. How­ev­er, it has no idea what to do with the pack­ets tar­get­ing the ma­chines out­side the lo­cal net­work. In oth­er words, even if one of the three ma­chines was an ac­tu­al router with In­ter­net ac­cess, the two oth­er ma­chines wouldn't be able to ac­cess the In­ter­net.

Im­por­tant note: if the ping doesn't work as ex­pect­ed, do ip route show, and then ip route delete 192.168.../... the in­valid records.

Ac­cess­ing In­ter­net

One of my mis­takes was to think that the con­fig­u­ra­tion in Sys­tem › Man­age­ment › IP Con­fig­u­ra­tion was im­por­tant, es­pe­cial­ly the de­fault gate­way. It's not, and it seems like the val­ue shouldn't be changed.

In­stead, go to Rout­ing › Rout­ing Table. Add DefaultRoute with next hop IP ad­dress 192.168.11.2, pref­er­ence 1.

Now, when do­ing ping 192.168.12.2 from m0, the ping will still work the same as be­fore, and m1 will not see the pack­ets. On the oth­er hand, when do­ing ping 1.2.3.4, it will be seen by Wire­shark on m1 (and the ping will fail, be­cause the "gate­way" doesn't know what to do with the pack­et).

DHCP con­fig­u­ra­tion

Hav­ing ma­chines which talk to each oth­er is great, but it's even greater when one doesn't have to man­u­al­ly con­fig­ure the gate­way and oth­er stuff. I'm us­ing ISC DHCP, and when re­con­fig­ur­ing it by adding sev­er­al sub­nets, I dis­cov­ered that it starts ig­nor­ing the host di­rec­tives.

In fact, DHCP serv­er was on an un­tagged port of the switch, and so it was us­ing a sin­gle in­ter­face eth0. On the oth­er hand, mul­ti­ple sub­net con­fig­u­ra­tion like the one used in most ex­am­ples on the In­ter­net ex­pects the DHCP serv­er to have mul­ti­ple in­ter­faces, would it be an eth0 on first LAN and eth1 on the sec­ond one, or an eth0.10, eth0.11, etc. in a case of mul­ti­ple VLANs with a trunk­ed port.

The so­lu­tion was to en­close all sub­nets in a shared-network block. The doc­u­men­ta­tion is per­fect­ly clear about that when you look for the di­rec­tive, but when you don't know that the di­rec­tive ex­ists in the first place, dis­cov­er­ing it may not be that easy.

Here's an ex­am­ple of the con­fig­u­ra­tion file:

shared-network everything {
    # VLAN 10.
    subnet 192.168.10.0 netmask 255.255.255.0 {
        option subnet-mask 255.255.0.0;
        option broadcast-address 192.168.10.255;
        option routers 192.168.10.1;

        pool {
            failover peer "dhcp-backbone";
            max-lease-time 1800;
            range 192.168.10.200 192.168.10.254;
        }
    }

    # VLAN 11.
    subnet 192.168.11.0 netmask 255.255.255.0 {
        option subnet-mask 255.255.0.0;
        option broadcast-address 192.168.11.255;
        option routers 192.168.11.2;  # The router itself.

        pool {
            failover peer "dhcp-backbone";
            max-lease-time 1800;
            range 192.168.11.200 192.168.11.254;
        }
    }

    # VLAN 12.
    subnet 192.168.12.0 netmask 255.255.255.0 {
        option subnet-mask 255.255.0.0;
        option broadcast-address 192.168.12.255;
        option routers 192.168.12.1;

        pool {
            failover peer "dhcp-backbone";
            max-lease-time 1800;
            range 192.168.12.200 192.168.12.254;
        }
    }

    host m0 {
        hardware ethernet 12:34:56:78:90:AB;
        fixed-address 192.168.10.2;
    }

    host m1 {
        hardware ethernet CD:EF:12:34:56:78;
        fixed-address 192.168.11.2;
    }

    host m2 {
        hardware ethernet 90:AB:CD:EF:12:34;
        fixed-address 192.168.12.2;
    }
}

Here's the list of re­sources which helped me to fig­ure out the things de­scribed above: