Introducing a managed switch to my network - VLAN setup questions
-
"tagged port (Cisco calls this a trunk port)"
Not quite. At least not in the Cisco SG200-08.Here are the available VLAN Interface Settings for the Cisco SG200-08.
Interface VLAN Mode — Select an option to configure the port type with respect to VLAN membership and tagging.
General — The port can be a member of one or more tagged or untagged VLANs. This mode allows the full capabilities specified in the IEEE 802.1Q specification, “VLAN Tagging.”
Access — The port can accept only untagged frames. An access port can be a member of only one VLAN and it uses the VLAN ID as its port VLAN ID (PVID). Access ports are typically used to connect hosts, which become members of the VLAN by virtue of being physically connected to the port.
Trunk — The port can be assigned to only one untagged VLAN, the native VLAN, and can be assigned to any number of tagged VLANs (or none). Trunk ports carry traffic for multiple VLANs from the switch to other network devices, such as an upstream router or an edge switch.Port to VLAN Configuration — For each interface, configure the following parameters:
Member — Check this box if a port is to be member of the VLAN. Uncheck this box if a port is not to be member of the VLAN. A port is not member of the VLAN by default.
Tagged — Select Tagged if all the packets of the VLAN egress to the port are to be tagged. Otherwise, select Untagged. A trunk port is tagged by default. This option is only relevant if the port is a member of the VLAN.
Untagged — Select Untagged if the packets from the VLAN egress to the port are to be untagged. Otherwise, select Tagged. An access port is always untagged. A general port is untagged by default. This option is relevant only if the port is a member of the VLAN.
PVID — Check this box if a port is to use the selected VLAN ID as its port VLAN ID (PVID). Otherwise, uncheck this box. If PVID is selected for an access or trunk port, the port must be an untagged member of the VLAN. Untagged packets received from the port will be assigned to the corresponding VLAN.Note that a trunk port is tagged by default. But a tagged port is not necessarily a trunk port.
Some images of the VLAN configuration interface can be seen in this Cisco support forum discussion
https://supportforums.cisco.com/thread/2214870?tstart=0 -
But then later on I read that I should just leave the physical parent (em1) free from any interface assignment, so I deleted it.
If you delete an interface from the pfSense pool of available interfaces that will (I presume) effectively disable all child VLAN interfaces.
It is generally recommended not to mix tagged (VLAN) and untagged traffic on an interface, therefore the VLAN parent interface should be left with a default OPTx name and no IP address.
-
The few tutorials I read suggested a configured parent interface was unnecessary. But I can't think how else to control traffic across management VLAN 1.
I had it working today, for a few fleeting minutes. Then I did something and broke it again.
At the moment the setup I've gone for is as simple as can be.
On Cisco:
VLAN1 (magic management VLAN): default id 1, trunk, 1 untagged, 2 tagged.
VLAN2, id 2, trunk, 2 untagged.No matter what configuration combination I try, nothing comes through on my client computer on vlan2. However, tcpdump -i em1_vlan2 is going crazy on a monitor attached to pfSense directly with those settings if I try to load up a bunch of websites. Too fast for me to understand what's going on. If I make VLAN2 be trunk and tagged with 2, tcpdump is silent.
Does the noise from tcpdump mean it's my firewall rules blocking? Because at one stage I tried to allow any from any on WAN, LAN, VLAN2 and VLAN_PARENT (a.k.a. VLAN1 on em1) and it still didn't work. I felt bad even after 1 min with those rules, and coincidentally got a bluescreen while switching it back to warn me not to be so stupid.
I wish I remembered what settings worked. Vaguely recall it was also with wide open rules. But I also want traffic to feed through VLAN2 -> VLAN_PARENT -> pfSense -> Dansguardian -> Squid3 -> Internet so maybe my package configuration is interfering? I guide normal LAN traffic through DG and Squid and was trying to do the same with VLAN2 traffic - directing it to the LAN subnet. Maybe I need to do some tricky subnet rdr remapping to enable that kind of functionality.
At the moment it's like:
LAN x.x.0.1/24
WLAN x.x.1.1/24
VLAN2 x.x.2.1/24
.
.
.
VLAN_PARENT x.x.10.1/24Anyway, a couple of hours more of stabbing in the dark for no results.
-
This should not be so difficult. ;)
Cisco's VLAN config scheme is confusing IMHO.You should not have the VLAN parent interface, em1, assigned with an IP address. Leave as type 'none'.
I think the problem is probably the switch config but I can't really be sure about that.
You definitely don't need any rules on WAN.
Look at the firewall logs to see if any VLAN2 traffic is being blocked.
Is the client attached via the VLAN2 interface ever receiving an IP via DHCP?
Steve
-
The few tutorials I read suggested a configured parent interface was unnecessary. But I can't think how else to control traffic across management VLAN 1.
I have not ever configured a Cisco switch so I might have misread the configuration information you posted. It seems to me you have misconfigured the switch. You need the port connected to the pfSense box to be a trunk port with it sending VLAN tags for every VLAN you are using. In pfSense you need VLAN interfaces for every distinct VLAN ID you are using. You then control traffic from VLAN 1 by using firewall rules on the pfSense interface with VLAN id 1. It looks to me that you have configured the switch to NOT send VLAN tags on VLAN 1 and VLAN 2 seems to be both tagged and untagged. However you need to configure it, the result is that you want the port connected to the pfSense box putting VLAN tags in transmitted frames for all VLANs. Maybe the VLAN 1 is special and you really should use another VLAN id to accomplish this.
I had it working today, for a few fleeting minutes. Then I did something and broke it again.
Time to stop random tinkering. Decide on a simple objective, make a simple change, document the change and then test that change brings things closer to your objective. Repeat as necessary.
It is very hard to help when someone reports "I made a few changes that I can't remember and now it is broken".
Does the noise from tcpdump mean it's my firewall rules blocking?
Impossible to tell without a reasonable sample. However it is unlikely because I think tcpdump shows incoming frames BEFORE firewall rule processing has occurred.
-
From OP'ers previous posts it seems they are mostly interested in tinkering to learn VLANs.
To that end here are some fundamentals that may help.
PVID is the VLAN tag that will be given to untagged packets received by the switch port.
Untagged Member means VLAN traffic will be transmitted out the port with VLAN tag stripped so that it is placed on the wire as untagged. Target device does not need to be VLAN configured.
Tagged Member means VLAN traffic will be transmitted out the port with VLAN tag in place. Target device needs to be VLAN configured.
On the Cisco SG200-08, probably the easiest way to get things working is to place the interfaces in "General" mode. "Access" and "Trunk" modes will override some settings. For example "Trunk" can only have 1 untagged member and "Access" is always untagged member of corresponding PVID and only accepts untagged traffic.
Don't try to config it all at once. Set up one simple piece first. Then expand.
Oh and by the way. If you use any port mirror/probes for checking results. Be aware that some NICs strip VLAN tags by default and yet some other NICs don't pass VLAN tagged packets up the stack. These NICs requires a special config settings to see VLAN tags with sniffer such as Wireshark. This is mostly only relevant to Windows machines.
See the Wireshark Wiki for Details: http://wiki.wireshark.org/CaptureSetup/VLAN -
Here is a working example for you. I know this is not specifically what you are trying to set up. But it may help with understanding VLAN config.
This is a home config that connects a single NIC pfSense to both the LAN and WAN.
The LAN is the native physical device (bfe0) and the WAN is a VLAN device (bfe0_vlan99).pfSense is connected to switch interface g6 and ISP is connected to switch interface g8.
Interface g6:
Mode: General
PVID 1
Untagged member VLAN 1
Tagged Member VLAN 99Interface g8:
Mode: General
PVID 99
Untagged Member VLAN 99Cisco SG200-08 VLAN Configuration Images:
-
Although I didn't have much difficulty setting up vlans, I had a bit of a problem making them work on pfsense. Hopefully that was just a hardware problem specific to my setup… Which shouldn't be an issue unless you're using equipment old enough to be put in a museum. I also had an issue on the linux side of things, eventually identified as a weird glitch that magically went away after restarting the box. As in, the exact same steps taken to bring up the network sometimes resulted in nothing being sent on the vlan ports on the linux PC.
So what I'm trying to say is, I've run into some random weirdness when dealing with vlans, in case you somehow get stuck while your setup seems to be 100% correct (and you've double-checked) and yet it simply doesn't work, consider restarting things or otherwise not trusting the hardware/software as much and testing things one step at a time.
Good luck learning this stuff :)
-
Yeah! Got it, thanks to your help. I copied NOYB's configuration and got a basic setup working with a single VLAN2 for now. Then I set about fixing up pfSense.
On my LAN, I've got wpad pointing to Dansguardian, on the LAN subnet. I made sure DG was also listening on VLAN2 and modified wpad to point to DG on VLAN2's subnet.
I also have NAT rules to redirect http and https traffic on the LAN to DG's port. Not sure if these or wpad take priority, I'll have to investigate one day. I did the same for VLAN2 traffic but rdr it to VLAN2:DG's port.
I've got some wide-open rules allowing all VLAN2 traffic within VLAN2. Not sure how necessary this is. I'll have to lock it down a bit later.
I had to set up a VLAN_PARENT interface on em1 temporarily to gain access to the switch. I plugged it in to the LAN port several times and for whatever reason couldn't get an IP address for it from the LAN's dhcp server. But I'm impatient and don't wait around long after plugging and changing. It might have gained one on LAN eventually. Setting up VLAN_PARENT seemed to gain me access to a dynamic IP pretty quickly. Now I've deleted the em1 interface and it is still working with NOYB's setup, just VLAN2 on em1_vlan2.
I will configure openvpn access to pfSense on this computer, because it's annoying not being able to access the webgui and having to replug my computer back into LAN each time.
And wireshark's awesome. I don't really know how to use it properly but it's already given me a few hints and is much easier to use than walking backwards and forwards to the other end of the house where the pfSense monitor running tcpdump is.
-
You can allow access to the switch web interface without using untagged traffic by setting up a further VLAN interface on VLAN1 and then adding VLAN1 to the 'trunk' connection.
However unless you need to access the switch on a regular basis perhaps 'if it aint broke don't fix it'. ;)Steve
-
I would like access to the switch gui as well. But I don't have any 'trunk' ports any more - that was one key difference to any of the setups I tried. I always had a trunk port but when emulating NOYB's example his are all general and now, so are mine.
I thought exposing VLAN1 was a bad idea. But I like the idea of reliable access. One issue is that on each of the occasions I've gained access to the switch, I've had to reset it first to factory settings to get a dhcp assigned address. Although I was trying to get static addresses right up until yesterday. Maybe now that I'm not bothering and letting it get a dynamic address it'll gain one easier.
We'll see. At least now I have a baseline to fall back to. And I've saved that switch config for future too.
-
It shouldn't have any trouble getting a DHCP address.
But if so, then there is misconfiguration either in the pfSense router or switch vlans.
If need be a static can be assigned in Administration - Management Interface -
The reason you should not use VLAN1 is that the switch uses it internally even if you have no VLANs defined and are using it as an unmanaged switch. You can get odd behaviour if you're not aware of what you're doing. The webgui is on VLAN1 internally in the switch. Usually all traffic with VLAN1 is untagged at every port such that you never see it outside the switch but you can allow it to exit as tagged and that way you can connect to the webgui over tagged traffic. ;)
You are only doing this because it's not recommended to have tagged and untagged traffic on the same pfSense interface. The reason for that is that some combinations of hardware and driver cannot handle that and end up discarding one of the other. However most people never see this problem so you are probably fine just adding the em1 as an interface to access the switch gui. Just be aware that it may cause a problem.
Alternatively there is often an option to add the webgui to other VLANs so you could just add it to your existing VLAN.
Steve
