New VLAN setting, advice request

Comments

7 comments

  • Avatar
    Firewalla

    If you are new to VLAN's, the best to start with just a couple of them and then grow as you need them. The reason for this is, complexity in network design may have a negative impact on your network and also increase the time to debug. 

    0
    Comment actions Permalink
  • Avatar
    Radagast82

    That's what I did, just 3 VLANs... it seems to be working correctly, as long as I can test them (i.e. able to ping devices from LAN but unable to do this from VLANs, ip addresses correctly assigned to devices based on ip range for each VLAN etc). Any advice for rules?

    0
    Comment actions Permalink
  • Avatar
    Dave Taylor

    It would help if you could post a diagram showing your network layout, from the text above, echoed by @Firewall's comments, your network seems quite complex, having a diagram showing how things are wired up, which VLANs run to where, etc would be useful for providing advice.

    Hint: Sometimes just sitting down and diagramming what's supposed to go where and under what conditions can show you a solution to the question.

    0
    Comment actions Permalink
  • Avatar
    Radagast82

    Hi Dave,

    In my mind it was a quite simple layout, maybe with this graph it's better:

     

     

    0
    Comment actions Permalink
  • Avatar
    Dave Taylor

    The diagram certainly helps, thanks!

    (Incidentally, is that done with Creately?  Trying to figure out where I've seen the format before, I really should get around to diagramming my setup with something more than pen&paper).

    In terms of adding more VLANs, you mentioned you've got a Gold which is fine, the Purple is limited to 5 VLANs so you have to be a bit careful with allocation of devices.  I'm using mine for security so I've got two IoT VLANs, one for devices that are cloud-based so you can restrict access to outgoing WAN-only, and one for devices where you need local access.

    You may also want to consider a VLAN for high-risk devices, I have one for VoIP devices which tend to have more than their share of vulns and are typically full-blown Linux boxes once an attacker gets in, those are locked into a WAN-only VLAN with no ability to access anything local.

    0
    Comment actions Permalink
  • Avatar
    Radagast82

    Yes, I made that diagram with creately, very useful. 

    In terms of setup, I'm thinking about another VLAN for work devices (total of 4, 2 laptops and 2 phones), this would be managed by the access point. 

    I think nothing more should be worth to do, as a matter of fact I already segmented all my devices between personal (in LAN-WLAN), multimedia (VLAN 103) and IoT (VLAN 101). My guests will connect to their network (VLAN 102) eventually. In terms of rules, other than the generic block from internet, I locked VLANs in their subnet and between devices, with the only exception of VLAN103 where devices in there are able to talk with each other (need it to let the nvidia shield read files from NAS and WDMyCloud). LAN devices can of course access to everything. I made some simple ping test, connecting my laptop to the Guest network: I wasn't able to reach the NAS for instance, so this should work. 

    Hope Firewalla will release a Gold "plus" with some 2.5gb ports, now the router is the only part of main components which is using gigabit ports...

    0
    Comment actions Permalink
  • Avatar
    Dave Taylor

    Ah, that's a good idea, have a VLAN that disallows traffic between devices.  So if you wanted to be really careful you'd have three VLANs for IoT, one for purely cloud-based devices that allows WAN access and nothing more (Apple TV would be an example), one for cloud + local, e.g. uploads to the cloud + admin via local SSH (WeeWX would be an example), and one for local access, e.g. interacts with things locally (a NAS as an example).  I'm thinking here of the most effective way to isolate at-risk IoT devices if they get compromised.

    0
    Comment actions Permalink

Please sign in to leave a comment.