VLans, security & access
-
I think I've found a cure to my earlier problem. What I've done is create vLans, each with a DHCP server. And then to allow them access to the gateway (and, thus, onto the internet), you simply don't enter a gateway address.
Example
-
I've created a vLan 3 interface (and assigned it to pvid 3).
-
In the interface area this is entered as a static type with an IP of 10.3.0.1 (with a /24 provision).
-
Next, I've left the gateway as none - I had been trying top set it to tell it to use the global one (that didn't work - now I just leave it as 'none' it seems to work).
-
For now, I've left the DHCP settings for each vLan quite simple (in vLan 3, it is subnet 10.3.0.0 with a mask of 255.255.255.0 with an allowed range from 10.3.0.1 to .254, though I have restricted it to .101 to .200).
Now that seems to address computers in vLan 3 (which is port 3 on my ZyXEL switch) correctly. These are seperatly addressed to ones in vLan2 or LAN.
However, there are a couple of issues/problems.-
Firstly, how secure is this? Is vLan 3 secure? I'm asking this partly becuase;
-
In vLan 3 you can ping and access the 10.1.0.1 address that pfSense is sitting at - I want (no, need) to turn off the ability to access 10.1.0.1 (infact the whole 10.1.0.x network) from any of the vLans (other than my control one - which will be vLan 1, connected to port 1 on my ZyXEL switch.
Does this make sense? Have I done the right thing? Is there any vLan security testing routines that you can run (similar to the fact that you can run firewall tests from various internet sites)?
Many thanks
-
-
From a PC on vLan 3 (10.3.0.101) I can ping 10.1.0.1, 10.2.0.1, 10.3.0.1, etc. (one per vLan that I've created). However, I can't ping a computer on the 1st vLan (called LAN) - the computer is 10.1.0.167 and the ping simply timesout.
I've tried it the other way - 10.1.0.167 can ping all the gateways, but not 10.3.0.101. So it seems to be working - am I just being too cautious?
-
Hello Sensi,
I have now implemented the same kind of setup using a Cisco 3500XL switch and pfSense for a few VLANs on my test network and can speak to some of your concerns…
However, there are a couple of issues/problems.
-
Firstly, how secure is this? Is vLan 3 secure? I'm asking this partly becuase;
-
In vLan 3 you can ping and access the 10.1.0.1 address that pfSense is sitting at - I want (no, need) to turn off the ability to access 10.1.0.1 (infact the whole 10.1.0.x network) from any of the vLans (other than my control one - which will be vLan 1, connected to port 1 on my ZyXEL switch.
Does this make sense? Have I done the right thing? Is there any vLan security testing routines that you can run (similar to the fact that you can run firewall tests from various internet sites)?
You could be more specific on what you mean by "this" being "secure"… Is no one ever going to be able to compromise your network? Obviously not...
However, I believe, based on what I assume (dangerous, lol) you mean, that yes this is "secure". This assumes your setup is robust and correct. I have, and would expect you to have, these VLANs defined in the switch itself and a port on the switch configured as a VLAN trunking port and connected to the pfSense box (assuming your switch is 'managed' and such things are possible - what is the model number?)
Under the conditions above (and in my test network) the VLAN subnets are segregated from each other's layer-2 broadcast domains and the only way for them to communicate with each other (assuming no compromised hosts or network devices on your network) is for the traffic between the VLANs/subnets to be routed through a layer-3 routing device like the pfSense box.
This would mean your firewall rules on the pfSense box will determine exactly what kind of traffic is allowed between the VLAN subnets. Sounds like you have a lot of work to do (as did I) to get all the firewall rules setup to allow and deny specific traffic in specific directions between the different VLANs.
If you want help with that, you would need to post up some info on your rules, but it is a very logical process (if a bit complicated due to a lot of decisions to be made) to set up the rules how you want them. I found it easiest to map out what traffic I wanted to allow and deny between which networks on paper, then figure out the least complicated way to get that done in pfSense's firewall.
From a PC on vLan 3 (10.3.0.101) I can ping 10.1.0.1, 10.2.0.1, 10.3.0.1, etc. (one per vLan that I've created). However, I can't ping a computer on the 1st vLan (called LAN) - the computer is 10.1.0.167 and the ping simply timesout.
I've tried it the other way - 10.1.0.167 can ping all the gateways, but not 10.3.0.101. So it seems to be working - am I just being too cautious?
You are not "too cautious", you just seem to know what you want as far as access behavior and need to take some time to map out how to make that happen using the pfSense firewall rules. There will be many ways to make it happen. Allow everything at the bottom of the rule list, then block access to the networks you do not want that subnet to access using rules located above the "allow everything" rule or make use of the default "block all" rule that does not show up in pfSense's rule list but is there none-the-less and add rules to allow access to only the networks you want that subnet (VLAN) to access. Either way.
I made network alias for each VLAN (subnet) where I then added as members the networks I either wanted to access or block for that particular subnet and then named the alias accordingly. Like 'BlockFromVLANfive', or 'AllowFromVLANseven'. Then I made an allow or block rule for source network on any protocol or port to a destination of the appropriate alias for that interface to any protocol or port. This way, changing the rule for a VLAN (subnet) just means changing the networks that are a member of the appropriate alias.
Anyway, sorry to go on for so long, but you can always "keep the best and dump the rest", lol.
Anyway, good luck to you!
Let us know how it goes.Jon
-
-
Jon,
You are a gentleman, sir (that's a major compliment here in Blighty!).
I'm currently just using the 'default' settings and it seems as if the vLans are secure & separate (so far as it is possible to be so!). All the vLans are untagged to a specific port on the switch (which then connects to a basic/simple switch that has all the PCs in that vLan connected to it). Each port is also tagged to vLan64 (which is for a VoIP phone network, that allows public/unsecured internet access).
I think it's correct/safe/good! Switch with be either a ZyXEL1428 (or was it a 1528) or a 3Com4200.
-
Thank you for the kind words. :)
The ZyXEL seems to be the ES-1528. It does not seem to handle 802.1q trunking as I would expect. They call port aggregation "trunking" on the ES-1528 web-interface.
ZyXEL seems to come up with common sense, though not exactly standard, ways of implementing a particular technology, and this switch's implementation of 802.1q is no different, lol.
The 3com 4200 series switches seem to be comparable to the Cisco 3500XL series switches I use and likely handle .1q trunking very well.
Hopefully you have already blocked or enabled access between VLANs to your liking.
If your setup is working well for you, obviously there is no need to mess with it. -
I've re-read your answer and I'm a bit surprised that I have to create rules to keep the vLans totally separate (other than the shared/common internet input).
I would have assumed that this would have been standard.
-
What I meant was simply the need to configure a firewall ruleset so a VLAN has the access you want and is denied from getting where you don't want it to go. The possible, specific configurations are numerous, as I mentioned. You could block specific and allow everything else. You could allow specific and block everything else.
If a VLAN has access to the internet, then it is not showing "standard", aka "default", behavior.
Standard (default) for a new interface setup on pfSense is that the new interface cannot connect to anything, including the internet.
Obviously, when we setup a new interface it has a blank ruleset in the firewall so all traffic for that interface gets picked up by the default (not shown, but still there) "block all" rule. Thus, if any VLAN can access anything, it is already not configured as default, so a rule or rules had to have already been created for that interface. This is what I was referring to, that process of creating rules. Not NECESSARILY "create rules to keep the vLans totally separate", but DEFINITELY "create rules".
That is what I meant, the process of creating the rules you want. It has to be done, because each new interface has no rules when you assign it (and so only the default rule that is not shown to "block all"). See where I was coming from?
Each individual VLAN will only go where you allow it to go. Obviously we can get that done however we want, but it has to be done.
I personally found the best way for me to give a VLAN access to the internet, but not access to every other VLAN, was to use a rule that blocked access to all the networks listed in an alias created for this purpose, and then put an "allow any" rule at the bottom that permitted all traffic that wasn't blocked (traffic to any network lot listed in the firewall alias would be permitted).
I also found the best way for me to give a VLAN access to some of the other VLANs, but not access to the internet or the rest of the VLANs, was to use a rule that allowed access to all the networks listed in a firewall alias created for this purpose, and then to use the pfSense default "block all" rule (not shown, but still there) to prevent all other traffic.
I like this setup because then I am not keeping a bunch of rules up to date, just a firewall alias file for each interface. That is easier in my opinion.
Again, good luck.
As long as it works how you want that is what we're after, right? :) -
Thanks,
I'm going to have a good read and do some thinking. On my 'test', I've got internet access by not giving a gateway but I have secure/safe(ish!) vLans. Or so I was thinking. It was down to each vLan being untagged to the switch port it was on and tagged to the port the modem was on.
-
Sorry, not the modem but pfsense