{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/", "item": { "id": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/", "slug": "keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions", "url": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions.md", "json": "https://update.dsesecurity.com/api/v1/posts/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/" }, "title": "Keep native VLAN behavior out of pfSense trust-boundary assumptions", "summary": "A tagged-network design still needs an explicit policy for untagged traffic on trunks.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:02+00:00", "modified_at": "2026-10-20T18:34:34+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 256, "potentially_affected": "This is Netgate's VLAN security guidance, not proof that a particular switch or firmware is exploitable.", "dse_recommendation": "DSE recommends documenting the allowed tagged VLANs, native VLAN, and handling of untagged frames on both ends of each trunk.", "primary_source": { "name": "Netgate — VLANs and Security", "url": "https://docs.netgate.com/pfsense/en/latest/vlan/security.html", "published_on": null, "authority": "docs.netgate.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

A tagged-network design still needs an explicit policy for untagged traffic on trunks.

\n

Source facts

\n

Netgate warns that native VLAN handling can strip a matching outer tag and that double-tagged traffic can reach another VLAN under vulnerable trunk arrangements. Untagged traffic is assigned to the native VLAN. The guide recommends restricting access to trunk ports and avoiding careless mixing of outside-firewall and trusted inside networks on one switching design.

\n

Source: Netgate — VLANs and Security.

\n

Applicability

\n

This is Netgate’s VLAN security guidance, not proof that a particular switch or firmware is exploitable.

\n

DSE recommendation

\n

DSE recommends documenting the allowed tagged VLANs, native VLAN, and handling of untagged frames on both ends of each trunk. Remove unused trunk access and place externally reachable equipment into a switching design appropriate to its trust level. Treat physical access to an enabled trunk as privileged network access. Keep the switch management network and ordinary endpoint networks deliberately assigned rather than inheriting a default VLAN accidentally. Include unused ports and the switch’s trunk-negotiation policy in the review, not only the active uplink. Have the switching owner explain where an untagged test frame should land, then compare that prediction with a controlled observation before accepting the trust boundary.

\n

Verification

\n

In a controlled network test, compare each permitted tagged VLAN with untagged and unauthorized-tag traffic. Confirm the observed interface and subnet on the firewall. Check both trunk endpoints and retain their configuration together; a correct VLAN interface on pfSense alone does not verify the switch path.

\n

Official reference

\n

Netgate — VLANs and Security. Reviewed October 20, 2026.

", "content_text": "A tagged-network design still needs an explicit policy for untagged traffic on trunks.\nSource facts\nNetgate warns that native VLAN handling can strip a matching outer tag and that double-tagged traffic can reach another VLAN under vulnerable trunk arrangements. Untagged traffic is assigned to the native VLAN. The guide recommends restricting access to trunk ports and avoiding careless mixing of outside-firewall and trusted inside networks on one switching design.\nSource: Netgate — VLANs and Security.\nApplicability\nThis is Netgate’s VLAN security guidance, not proof that a particular switch or firmware is exploitable.\nDSE recommendation\nDSE recommends documenting the allowed tagged VLANs, native VLAN, and handling of untagged frames on both ends of each trunk. Remove unused trunk access and place externally reachable equipment into a switching design appropriate to its trust level. Treat physical access to an enabled trunk as privileged network access. Keep the switch management network and ordinary endpoint networks deliberately assigned rather than inheriting a default VLAN accidentally. Include unused ports and the switch’s trunk-negotiation policy in the review, not only the active uplink. Have the switching owner explain where an untagged test frame should land, then compare that prediction with a controlled observation before accepting the trust boundary.\nVerification\nIn a controlled network test, compare each permitted tagged VLAN with untagged and unauthorized-tag traffic. Confirm the observed interface and subnet on the firewall. Check both trunk endpoints and retain their configuration together; a correct VLAN interface on pfSense alone does not verify the switch path.\nOfficial reference\nNetgate — VLANs and Security. Reviewed October 20, 2026.", "content_markdown": "A tagged-network design still needs an explicit policy for untagged traffic on trunks.\n\n## Source facts\n\nNetgate warns that native VLAN handling can strip a matching outer tag and that double-tagged traffic can reach another VLAN under vulnerable trunk arrangements. Untagged traffic is assigned to the native VLAN. The guide recommends restricting access to trunk ports and avoiding careless mixing of outside-firewall and trusted inside networks on one switching design.\n\nSource: [Netgate — VLANs and Security](https://docs.netgate.com/pfsense/en/latest/vlan/security.html).\n\n## Applicability\n\nThis is Netgate’s VLAN security guidance, not proof that a particular switch or firmware is exploitable.\n\n## DSE recommendation\n\nDSE recommends documenting the allowed tagged VLANs, native VLAN, and handling of untagged frames on both ends of each trunk. Remove unused trunk access and place externally reachable equipment into a switching design appropriate to its trust level. Treat physical access to an enabled trunk as privileged network access. Keep the switch management network and ordinary endpoint networks deliberately assigned rather than inheriting a default VLAN accidentally. Include unused ports and the switch’s trunk-negotiation policy in the review, not only the active uplink. Have the switching owner explain where an untagged test frame should land, then compare that prediction with a controlled observation before accepting the trust boundary.\n\n## Verification\n\nIn a controlled network test, compare each permitted tagged VLAN with untagged and unauthorized-tag traffic. Confirm the observed interface and subnet on the firewall. Check both trunk endpoints and retain their configuration together; a correct VLAN interface on pfSense alone does not verify the switch path.\n\n## Official reference\n\n[Netgate — VLANs and Security](https://docs.netgate.com/pfsense/en/latest/vlan/security.html). Reviewed October 20, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/", "url": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Keep native VLAN behavior out of pfSense trust-boundary assumptions", "item": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/#article", "identifier": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/", "url": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/", "headline": "Keep native VLAN behavior out of pfSense trust-boundary assumptions", "description": "A tagged-network design still needs an explicit policy for untagged traffic on trunks.", "abstract": "A tagged-network design still needs an explicit policy for untagged traffic on trunks.", "articleBody": "A tagged-network design still needs an explicit policy for untagged traffic on trunks.\nSource facts\nNetgate warns that native VLAN handling can strip a matching outer tag and that double-tagged traffic can reach another VLAN under vulnerable trunk arrangements. Untagged traffic is assigned to the native VLAN. The guide recommends restricting access to trunk ports and avoiding careless mixing of outside-firewall and trusted inside networks on one switching design.\nSource: Netgate — VLANs and Security.\nApplicability\nThis is Netgate’s VLAN security guidance, not proof that a particular switch or firmware is exploitable.\nDSE recommendation\nDSE recommends documenting the allowed tagged VLANs, native VLAN, and handling of untagged frames on both ends of each trunk. Remove unused trunk access and place externally reachable equipment into a switching design appropriate to its trust level. Treat physical access to an enabled trunk as privileged network access. Keep the switch management network and ordinary endpoint networks deliberately assigned rather than inheriting a default VLAN accidentally. Include unused ports and the switch’s trunk-negotiation policy in the review, not only the active uplink. Have the switching owner explain where an untagged test frame should land, then compare that prediction with a controlled observation before accepting the trust boundary.\nVerification\nIn a controlled network test, compare each permitted tagged VLAN with untagged and unauthorized-tag traffic. Confirm the observed interface and subnet on the firewall. Check both trunk endpoints and retain their configuration together; a correct VLAN interface on pfSense alone does not verify the switch path.\nOfficial reference\nNetgate — VLANs and Security. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:16:02+00:00", "dateModified": "2026-10-20T18:34:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/keep-native-vlan-behavior-out-of-pfsense-trust-boundary-assumptions/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Keep native VLAN behavior out of pfSense trust-boundary assumptions" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 256, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Netgate — VLANs and Security", "url": "https://docs.netgate.com/pfsense/en/latest/vlan/security.html" } } ] } }