Managed Switch Vlan Setup

[Desmond Hutchins]

Howeveryou cannot put multiple untagged VLANs on the same port. When the router sends untagged packets, the switch will not know which VLAN they should belong to. All it can do is tag all packets with the same VLAN (PVID), and you don't gain anything. (Some switches allow configuring this anyway, and it appears to work when only one VLAN is used in practice, but falls apart when you actually try to mix two.)

(The router only sees what's on the packets themselves, it doesn't know what happens inside the switch. If it sees untagged packets, it doesn't know and doesn't care which VLAN number they were originally from.)

Not without a router. Out of the box, it will only talk to the devices that are on the default vlan. If you configure the port to be an access port to a different vlan.. then that would be the vlan that you have access to. You would need a vlan aware router on the vlan side of the equation to route traffic from the "internet's vlan" to the other vlan.

Yes, but with work. Their traffic will be assigned a default lan based on the access port (untagged vlan port) the router is connected to. However, There are ways to assign vlans based on your mac address. I know of the CISCO VMPS (vlan membership policy service), which VMPS compliant devices can use to ask the VMPS (server) for a VLAN based on the mac. Perhaps it has other ways such as based on the IP. Switches might have a setup were macs are explicitly setup via a table to be assigned to a vlan.

This setup can be configured to only accept one vlan (rejecting the others), accept multiple (if the mac is registered with a vlan, then there is no confusion as there is when there is no knowlege of the mac at all, accept unknown but have a default lan they'll be assigned to.. I think there's one more.

The initial concept of a vlan allowed using multiple ports on a switch for different lans, creating virtual switches. The virtual switches switch virtual lans. But which particular port on a vlan can be decided by IP, or by Mac Address. As mentioned, a particular port on a switch can be assigned to a vlan by a lookup table or service.

On tagged ports, the switch preserves VLAN tags on packets, so you should add VLAN-aware devices as tagged ports of a VLAN. VLAN-aware devices are things like firewalls, other managed switches, and wireless access points that support VLANs.

When you add a port to a VLAN as an untagged port, the switch allows the device connected to that port to send and receive traffic to the VLAN, just like for tagged ports. The difference with an untagged port is that, before passing along packets to the port, the switch will strip the VLAN tag from network packets.

Assigning the port to the VLAN as an untagged port strips the VLAN tag from packets before they reach the IoT device. Assigning the PVID adds the VLAN tag to packets that the IoT device sends into the switch.

One of the biggest challenges in debugging VLAN issues was finding a way to observe what effect my configuration changes had. If I changed a port from a tagged port to an untagged port, how could I test whether that made a difference?

I originally tried debugging my VLANs in a VM on my Proxmox VM server, but that was too different from the actual IoT device I was trying to simulate. The Proxmox server is VLAN-aware, whereas I was trying to test a non-VLAN-aware device. Treating the Proxmox server as an untagged port would lock me out of the Proxmox server entirely.

I used two ping commands in two terminal windows. One was to the firewall at 10.0.80.1 and one was to google.com. The windows would tell me when I gained and lost connectivity to my local network and to Google, respectively.

One method I have found seems to work but not sure if this is secure or correct is to create 3 new interfaces and assign different network addresses/subnet and then assign different ports to each. Then plug an unmanaged switch into each port and then you have 3 seperate networks. I have tested this and theres no pinging between networks and seems fine but wanted opinions?

You just have to have a managed switch (unmanaged ones are not vlan capable but also will not touch the vlan tag in your packets). If you have unmanaged switches then the devices connected to those switches will have to take care for the vlans. The FortiGate can only handle packets that are tagged in a vlan (or are not tagged in any) and it will only let out packets tagged over the vlan interface.

Your problem begins when the VLAN (tagged) traffic leaves the FGT. The next switch must be VLAN capable, that is, able to collect switch ports into a VLAN broadcast domain, able to read the VLAN tag etc. IMHO there are 'semi-managed' switches which are VLAN capable for only a few bucks (Netgear metal boxes for instance).

If you create a VLAN you would want to pass the traffic all through your network either to the gateway or the hosts. If the FGT is your gateway, your switches need to support VLANs so that tagged traffic can reach the hosts. Hosts (PCs) usually are not VLAN capable; a switch port declared as 'VLAN access port' would be part of the VLAN but remove the VLAN tag on egress to the host.

Then repeat these steps for the other 2 networks we have obiously chanigng ports, network address, etc and then plugging unmanaged switches into each of these. As they arent officially VLANs they dont need VLAN compatible switchs. But is there some drawback to this method?

The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.

Dumb question here sorry, Routing mode should only be enabled on the Core switch correct, all other switches dont require it if i have DHCP helper enabled for every VLAN to each switch. Second dumb question is does the switch pickup an DHCP ip address for each VLAN that is tagged on the switch. I have a core stack xsm7224s and then M5300 for each location/department. Some departments have several VLAN's so each VLAN will give the switch an IP address, or did i miss configure something.

Lots of questions sorry, trying to make a better network than what is currenly here. From Core switch should the ports be configured for the Specific VLAN, default vlan 1, another vlan 10, should the ports be configured Untagged for the default vlan or the VLAN ID for the network. Example Department 1 is 10, department 2 is 20, department 3 is 30, should i untagg those ports on the core switch that go to that network. Or should i setup the default vlan ID for all the switches as untagged on the core switch and then just tagg the vlan ID per network.

I currently have a managed switch (DGS-3120-24SC) configured for private VLANs (secondary and primary port groups). Secondary ports are isolated from each other and forwarding is not possible between them. However they can communicate with all primary ports (uplinks). What I'd like to do is to transparently pass VLAN tagged packets between devices connected to primary and secondary ports.

I do have some servers connected to primary ports that need to reach devices behind secondary ports using different VLANs and tagging/untagging them at intermediary switches is not a convenient option for me.

I accidentally got into this page again, so decided to answer my own question. I've found a solution that works for quite some time now: the wanted functionality is achieved by using Traffic segmentation and VLAN trunking features of the switch. Traffic segmentation lets you allow or deny traffic forwarding between ports (in any configuration) and VLAN trunking allows to enable tagged packets to pass the switch untouched. These functions can be configured quite flexibly, because you can control individual ports.

But if they are on different ip subnets(L3), the network design usually also associate those subnets with separate vlan id's(L2). Then it is a matter of allowing ip routing (i.e. L3) to place the packets into the correct vlan through the routing process. Your servers which accept vlan tagged packets you will typically find to have an ip address per vlan id it accepts, each belonging to the ip subnet associated with the respective vlan. Your routers will facilitate reachability from clients on other vlan ids/subnets.

Put differently, vlan switches add vlan tags on egress and remove them on ingress. You don't change that basic premise and don't add to it unless you really have a thought out design requirement and solution (see the QinQ link below). To hop between vlan ids you use the overlying protocol ip, i.e. most likely your default gateway (the closest router).

If this is not what you want and still wish to do QinQ because you knew all of that stuff anyway, read the final "Problems..."-part in the following link. If you had no trouble understanding those and had answers for them already (I don't as I never did provider bridging), knock yourself out: _802.1ad

I am trying to configure a vlan for my xbox using a netgear gs305e managed switch, and cannot get the switch to put the xbox on the xbox vlan, the vlan group is set to 2 in the switch vlan settings and the vlan id in pfsense is set to 2 as well. I have the dhcp server setup for the vlan but the xbox still gets an ip of 192.168.3.22 when the ip range for the vlan is 192.168.20.xx. This was using the tip someone commented on my last post of setting the vlan id on the switch while it was unpluged form the pfsense server and then setting up the vlan on pfsense. Not sure what im doing wrong as im rather new to pfsense but i doubt theres anything wrong with my hardware.

3a8082e126