VLAN: How do you assign/use the native/untagged VLAN
-
If you assign an interface LAN to em0 and an interface OPT1 to em0_vlan100, em0 will be untagged to/from the switch. em0_vlan100 will be tagged with VLAN 100.
If you packet capture on em0 you will see tagged and untagged traffic but in the normal course of operation, LAN will only see the untagged traffic, OPT1 will only see the tagged traffic.
When designing networks, I avoid mixing tagged and untagged traffic on a link wherever possible. Exceptions are made where manufacturers require it (cough Ubiquiti cough). On pfSense I tag everything and leave the untagged interface (like em0) unassigned.
You seem pretty wrapped around the axle about a switching (layer 2) technology in your layer 3 device. Don't over-think it. pfSense has zero concept of what a PVID is. That is up to your switching infrastructure.
-
You seem pretty wrapped around the axle about a switching (layer 2) technology in your layer 3 device. Don't over-think it. pfSense has zero concept of what a PVID is. That is up to your switching infrastructure.
Well put! QFT!!
-
@kpa:
You simply don't do that in pfSense because pfSense has no support for such VLAN tag manipulation, in other words no support for PVID functionality or any related tricks that you'll find in a VLAN capable switch.
I'm not trying to do any kind of 802.1q manipulation at all. To the contrary, I am explicitly saying that no 802.1q manipulation is going to occur prior to the traffic being presented to one of the pfSense interfaces. Accept the fact that VLAN trunks can, and do, have untagged traffic otherwise known as "native". Any 802.1q aware device needs to have a strategy if it's going to "handle" native traffic, otherwise it just falls on the floor. A common strategy would be for the device to treat untagged traffic as if it had been tagged with a device dependent ID.
When I say handle I am explicitly talking about a device that makes decisions based on knoledge or assumptions, for example assuming that untagged traffic should be logically routed to a pipeline dedicated to a default ID. In the case of a firewall you want to handle the traffic by assigning it to a specific interface, because that's how pfSense works; it breaks a VLAN trunk out into a series of virtual non-802.1q interfaces. In fact, if the traffic happens to be routing across subsets, which usually also implies routing across VLANs, the packets will be re-tagged on the way out… or if it was untagged to begin with it will get tagged.
-
LAN assigned to em0 will get the untagged traffic
OPT1 assigned to em0_vlan100 will get the tagged traffic (tag 100).From that point there is no VLAN inside pfSense. The tag has been stripped and the traffic is ROUTED. If it happens to be routed out the LAYER THREE INTERFACE assigned to em0_vlan200 it will be tagged with VLAN 200 there. If it happens to be routed out the LAYER THREE INTERFACE assigned to em1 it will be sent untagged there.
Everything else is your switch's job.
-
If you assign an interface LAN to em0 and an interface OPT1 to em0_vlan100, em0 will be untagged to/from the switch. em0_vlan100 will be tagged with VLAN 100.
If you packet capture on em0 you will see tagged and untagged traffic but in the normal course of operation, LAN will only see the untagged traffic, OPT1 will only see the tagged traffic.
When designing networks, I avoid mixing tagged and untagged traffic on a link wherever possible. Exceptions are made where manufacturers require it (cough Ubiquiti cough). On pfSense I tag everything and leave the untagged interface (like em0) unassigned.
em0 is just not 802.1q aware, and there are some serious security ramifications here if you ignore tags on a trunk. That might be useful for egress, were you actually trying to generate untagged traffic for some reason, but my use case is the reverse. I have untagged ingress that needs to feed a specific ruleset. More often than not that native traffic is going to be routed into a tagged VLAN because of the destination subnet. In the real world you don't have the luxury of the purists view, you have to deal with the diversity (read exceptions) that technology vendors throw at you.
You seem pretty wrapped around the axle about a switching (layer 2) technology in your layer 3 device. Don't over-think it. pfSense has zero concept of what a PVID is. That is up to your switching infrastructure.
I'm struggling to keep people from getting wrapped up in the switch fabric, because the quickest argument is to force some other element of the infrastructure to negate the question, which is avoiding the question as opposed to answering it.
-
It will not make it into the firewall/rule set if it is tagged. It will be dropped if there is not an interface assigned to that VLAN.
A device cannot prevent something from appearing on the wire. It can only deal with it when it arrives.
-
Your question was simple enough, let me quote:
How would you configure an interface for the native/untagged VLAN in a trunk?
…
Also, some switches can tag untagged trunk traffic ... but I am interested in how you would do it with pfSenseWe already told you in quite simple and straightforward english that pfSense won't do that at all because it's a router/firewall operating system based on FreeBSD, not a switch. FreeBSD has no facilities for the kind of VLAN ID manipulation you keep wishing it had, zero, nada, zilch.
Also to clarify something if it wasn't clear enough:
Isn't em0 everything? I'm under the impression that em0_vlan100 is a subset of em0, so em0 "would include", but is not explicitly constrained to, untagged?
Em0 is the untagged traffic and only the untagged traffic, everything that is tagged on the wire connected to em0 has to go trough the configured VLAN interfaces.
-
LAN assigned to em0 will get the untagged traffic
OPT1 assigned to em0_vlan100 will get the tagged traffic (tag 100).From that point there is no VLAN inside pfSense. The tag has been stripped and the traffic is ROUTED. If it happens to be routed out the LAYER THREE INTERFACE assigned to em0_vlan200 it will be tagged with VLAN 200 there. If it happens to be routed out the LAYER THREE INTERFACE assigned to em1 it will be sent untagged there.
Everything else is your switch's job.
In my case em0… actually bond0 because it a VPN trunk over a LACP trunk... is:
WAN1 (public subnet)
WAN2 (public subnet)
DMZ1 (private subnet)
DMZ2 (private subnet)
LAN1 (private subnet)
LAN2 (private subnet)
VPN (private subnet)
Wireless (private subnet)
[Native (private subnet(s))]You can't (or at least shouldn't) use that interface for ingress. You take out 802.1q filtering and your greatly expand the attack surface by sending a lot more further up the stack.
What I'm hearing is that pfSense can't create a default interface dedicated exclusively to untagged traffic. The only way to do it is place a switch in front that default tags all native trunk traffic upon ingress. I'll have to dig and see if the Cisco 2960's can do it now… I just remember customers griping about how the flag was enabled but it wasn't working, and Cisco replying that the flag was generic to IOS but had no effect because the 2960's don't support it... but that may have changed since then.
-
@kpa:
Your question was simple enough, let me quote:
How would you configure an interface for the native/untagged VLAN in a trunk?
…
Also, some switches can tag untagged trunk traffic ... but I am interested in how you would do it with pfSenseWe already told you in quite simple and straightforward english that pfSense won't do that at all because it's a router/firewall operating system based on FreeBSD, not a switch. FreeBSD has no facilities for the kind of VLAN ID manipulation you keep wishing it had, zero, nada, zilch.
Yes, my question was simple enough, but apparently the words I used to ask it were not, so let me clarify:
How would you configure an interface for the native/untagged VLAN in a trunk? I can think of ways to mitigate the question elsewhere in the infrastructure, but assuming I can't deploy mitigation elsewhere, how would you configure an interface for the native/untagged VLAN in a trunk?
@kpa:
Also to clarify something if it wasn't clear enough:
Isn't em0 everything? I'm under the impression that em0_vlan100 is a subset of em0, so em0 "would include", but is not explicitly constrained to, untagged?
Em0 is the untagged traffic and only the untagged traffic, everything that is tagged on the wire connected to em0 has to go trough the configured VLAN interfaces.
Far from a clarification, if correct, this would actually answer my question and contradict what you just said about it not being possable, but, Derelict, Myself, and tcpdump are just going to have to agree to disagree with you here.
-
If you assign an interface LAN to em0 and an interface OPT1 to em0_vlan100, em0 will be untagged to/from the switch. em0_vlan100 will be tagged with VLAN 100.
If you packet capture on em0 you will see tagged and untagged traffic but in the normal course of operation, LAN will only see the untagged traffic, OPT1 will only see the tagged traffic.
Exactly what I do, it just works.
I use the untagged vlan for lan device management, ubnt access-point, controller & Devolo ethernet over power devices.
-
Assign it to the untagged interface.
Of course the interface itself is also going to see the tagged traffic. They're electrons arriving there.
-
"How would you configure an interface for the native/untagged VLAN in a trunk?"
How is this still a question - been answered and answered again. If its the interface em0 then it will be untagged. What vlan you assign that to on the switch and therefore the trunk is up to what you do on the switch… How is you are not getting this?????
If you want the traffic to be tagged as it leaves pfsense to enter the trunk port, it will be sent out the vlan interface. If you want it to be untagged then it would leave your naked interface.
"tcpdump are just going to have to agree to disagree with you here."
You clearly are just not getting it... I have lots of vlan (tagged) traffic hitting my interface... If I sniff on pfsense on on vlan interface. it does not report any of the untagged traffic. It only reports the tagged traffic.. Is all traffic actually hitting the interface yes.. But pfsense is going to process it based up if there is a tag or not a tag.
If your using tcpdump add -e on the end of your tcpdump command so you see the vlan tags of the tagged packets.. But do your packet capture or sniff on pfsense vlan interface and you will only see traffic for that vlan based upon the tag.
If you want to capture just specific vlan you can use the vlan interface pfsense creates in your tcp dump. Or just do grep for the tag your looking for after using -e..
If you want to capture just the native or untagged traffic on your naked interface use -d not vlan on the end of your tcpdump command.
-
em0 is not a superset of em0_vlan100. em0 only "sees" vlan data in the physical sense of the interface, the electron-level. The interface inside pfSense that you assign LAN/WAN/OPT to (in your case, em0) will only process untagged traffic. Any vlan packets arriving at the physical interface will only get processed by pfSense if there is an interface configured inside pfSense specifically for that vlan - else it gets dropped.
If you want to route untagged data, use em0. If you want to route vlan100 data, create an interface for vlan100 and attach it to em0 (ie, em0_vlan100).
-
…What I'm hearing is that pfSense can't create a default interface dedicated exclusively to untagged traffic...
Where do we lose you when saying:
EM0 is your default interface and handles all untagged traffic.
EM0_VLANxyz rides on top of that, tagged.You don't need to create it, it's there when you assign a network to a (physical) interface.
