Jump To: Support > KB > NetManager > Network > VLAN
VLAN configuration and usage
N.B. Before working with VLANs, you should have a good understanding of how VLANs work including tagging
Overview
Normal Ethernet traffic consists of a series of packets. Each packet contains a frame header with the traffic type (usually IP) and the source and destination MAC addresses. Switches and computers uses the headers to choose which packets are relevant to them.
With VLAN traffic, an additional 802.1Q header (named after the relevant IEEE networking standard) is inserted into the existing header of each packet which contains (amongst other things) a VLAN number (1-4094). This is called tagging (normal packets are called untagged). The extra header means that VLAN packets are not recognised by computers as the header does not match what is expected (technically, the frame type is read as being 0x8100 instead of, for example, 0x8000 for IPv4). Unless specially configured, switches will just send on the VLAN packets untouched.
Switches that understand VLANs can have ports configured to either forward on all traffic (whether tagged or untagged) or have a specific VLAN tag associated with them (a tagged port). If a tagged packet is received and the tag number matches that on a given port, the extra header will be stripped off and the (now untagged) packet will be sent out. Similarly, if untagged packets are received on a port configured for a certain VLAN tag, then a VLAN header will be added before sending on. Ports which send and receive all packets regardless of VLAN tag are sometimes called trunk ports.
It follows therefore that if a switch has the same VLAN tag configured on all ports that it will appear to be a 'normal' switch; any headers added on packets received will be removed before sending out.
The upshot of all this is that if a network is configured so that some ports on switches have 1 VLAN tag and other ports have a different VLAN tag, it will appear as though there are two independent LANs depending on which ports you use.
VLANs on the NetManager
If a NetManager network card is attached to an untagged port (i.e. so that it receives all packets for all VLANs), then that interface will see untagged packets and VLANs will be ignored (as one would expect).
However, you can create new virtual network cards that attach to a physical network card with a specific VLAN tag configured. The virtual network card and the real network card will appear as independent interfaces to the operating system, i.e. they can have different IP addresses assigned and can use DHCP, Firewalling and NAT.
Currently, there is no Console Menu or webadmin interface to configure VLANs. Therefore the NetManager configuration file must be edited directly (followed by the server Build Script). For reference, the configuration setting is interface_vlan and the value is a space-separated list of a <vlan-interface>:<physical-interface>:<VLAN-tag> triplets. For example:
interface_vlan="vlan42:wm0:42 vlan80:wm0:80"
In general, Precedence support staff will configure this for you.
Usage case - wireless guest access
Modern wireless access points can have multiple SSIDs which can each have their own VLAN. It is therefore possible to have open guest access (unencrypted) separated out from secure WPA access for known users. In conjunction with Firewalling, this allows you to give very restricted access to guest machines (such as no web access unless you log on through a web-browser and use a local proxy combined with no access to the rest of the network at all).
In the following example, there are 2 SSIDs: Guest and Secure. Secure has no VLAN associated (and has WPA2 configured, etc), Guest is associated with VLAN 10. On a network where no VLANs are configured on the switches, these access points could be placed anywhere. Clients using Secure SSID will be part of the main network and thus have unrestricted access.
On the NetManager, vlan10 has been configured with parent interface wm0 and VLAN ID 10 (i.e. interface_vlan="vlan10:wm0:10"). Interface wm0 is configured as usual as part of the internal network (in this example 10.0.0.1/16). The new virtual interface, vlan10, can be configured with an entirely different range of addresses (e.g. 192.168.2.254/24). DHCP is configured on vlan10 from 192.168.2.1-192.168.2.250). At this point, Guest computers will get a 192.168.2.x address, but because of routing and Trusted Networks they will get full access.
The firewall can then be switched to filter in and out traffic so that filters can be applied to internal networks. The firewall rules below are from the /etc/netmanager/ipf.additional Configuration File, but have been configured from webadmin, so it should be easy to determine the correct firewall rules.
Firstly, all traffic should be blocked on the guest VLAN:
block in proto tcp from 192.168.2.0/24 to any keep state
Next, we should allow DHCP traffic:
pass in proto udp from any to any port = 67 keep state pass in proto udp from any to any port = 68 keep state
Then allow access to webservers on the NetManager (both addresses) and relevant webservers on the internal network (10.0.0.153 in this example):
pass in proto tcp from any to 10.0.0.1 port = 80 keep state pass in proto tcp from any to 192.168.2.254 port = 80 keep state pass in proto tcp from any to 10.0.0.1 port = 443 keep state pass in proto tcp from any to 192.168.2.254 port = 443 keep state pass out proto tcp from 10.0.0.153 to any port = 80 keep state pass in proto tcp from any to 10.0.0.153 port = 80 keep state
Then grant access to the NetManager's web proxy:
pass in proto tcp from any to 192.168.2.254 port = 3128 keep state
And finally open up Citrix ICA access to allow connections to virtual desktops and applications:
pass in proto tcp from any to any port = 1494 keep state