{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/", "item": { "id": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/", "slug": "choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership", "url": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership.md", "json": "https://update.dsesecurity.com/api/v1/posts/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/" }, "title": "Choose one-peer or shared pfSense WireGuard tunnels around route ownership", "summary": "A routing protocol cannot replace cryptokey peer selection inside a shared multi-peer tunnel.", "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:27+00:00", "modified_at": "2026-10-20T18:34:35+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 244, "potentially_affected": "This concerns the pfSense WireGuard topology decision.", "dse_recommendation": "DSE recommends identifying who owns remote-prefix changes before choosing a shared or per-peer layout.", "primary_source": { "name": "Netgate — Design Considerations", "url": "https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/design.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 routing protocol cannot replace cryptokey peer selection inside a shared multi-peer tunnel.

\n

Source facts

\n

Netgate explains that a WireGuard instance with several peers needs each peer’s routed networks defined for cryptokey routing. With one peer per interface, a broad Allowed IPs entry can identify that sole peer while an operating-system routing protocol manages which traffic reaches the interface. Endpoint definition also affects which side can initiate and supports roaming peers.

\n

Source: Netgate — Design Considerations.

\n

Applicability

\n

This concerns the pfSense WireGuard topology decision.

\n

DSE recommendation

\n

DSE recommends identifying who owns remote-prefix changes before choosing a shared or per-peer layout. If dynamic routing is required, keep operating-system route selection distinct from cryptographic peer selection. Record endpoint initiation and roaming expectations for each connection. Prefer a diagram that shows tunnel interfaces, peers, Allowed IPs, and advertised routes together so later subnet additions do not create an unexplained black hole. Review a proposed new remote subnet as part of the topology choice. Ask who will update peer ownership and who will advertise the operating-system route, and show both entries in the design. Keep one-peer and shared-tunnel examples separate so their maintenance obligations remain visible.

\n

Verification

\n

In a lab, add an approved remote prefix and verify both the operating-system route and the peer selected for encryption. Test return traffic and a prefix that should not be reachable. Confirm the chosen layout handles the intended prefix-change workflow without broadening firewall permissions unintentionally.

\n

Official reference

\n

Netgate — Design Considerations. Reviewed October 20, 2026.

", "content_text": "A routing protocol cannot replace cryptokey peer selection inside a shared multi-peer tunnel.\nSource facts\nNetgate explains that a WireGuard instance with several peers needs each peer’s routed networks defined for cryptokey routing. With one peer per interface, a broad Allowed IPs entry can identify that sole peer while an operating-system routing protocol manages which traffic reaches the interface. Endpoint definition also affects which side can initiate and supports roaming peers.\nSource: Netgate — Design Considerations.\nApplicability\nThis concerns the pfSense WireGuard topology decision.\nDSE recommendation\nDSE recommends identifying who owns remote-prefix changes before choosing a shared or per-peer layout. If dynamic routing is required, keep operating-system route selection distinct from cryptographic peer selection. Record endpoint initiation and roaming expectations for each connection. Prefer a diagram that shows tunnel interfaces, peers, Allowed IPs, and advertised routes together so later subnet additions do not create an unexplained black hole. Review a proposed new remote subnet as part of the topology choice. Ask who will update peer ownership and who will advertise the operating-system route, and show both entries in the design. Keep one-peer and shared-tunnel examples separate so their maintenance obligations remain visible.\nVerification\nIn a lab, add an approved remote prefix and verify both the operating-system route and the peer selected for encryption. Test return traffic and a prefix that should not be reachable. Confirm the chosen layout handles the intended prefix-change workflow without broadening firewall permissions unintentionally.\nOfficial reference\nNetgate — Design Considerations. Reviewed October 20, 2026.", "content_markdown": "A routing protocol cannot replace cryptokey peer selection inside a shared multi-peer tunnel.\n\n## Source facts\n\nNetgate explains that a WireGuard instance with several peers needs each peer’s routed networks defined for cryptokey routing. With one peer per interface, a broad Allowed IPs entry can identify that sole peer while an operating-system routing protocol manages which traffic reaches the interface. Endpoint definition also affects which side can initiate and supports roaming peers.\n\nSource: [Netgate — Design Considerations](https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/design.html).\n\n## Applicability\n\nThis concerns the pfSense WireGuard topology decision.\n\n## DSE recommendation\n\nDSE recommends identifying who owns remote-prefix changes before choosing a shared or per-peer layout. If dynamic routing is required, keep operating-system route selection distinct from cryptographic peer selection. Record endpoint initiation and roaming expectations for each connection. Prefer a diagram that shows tunnel interfaces, peers, Allowed IPs, and advertised routes together so later subnet additions do not create an unexplained black hole. Review a proposed new remote subnet as part of the topology choice. Ask who will update peer ownership and who will advertise the operating-system route, and show both entries in the design. Keep one-peer and shared-tunnel examples separate so their maintenance obligations remain visible.\n\n## Verification\n\nIn a lab, add an approved remote prefix and verify both the operating-system route and the peer selected for encryption. Test return traffic and a prefix that should not be reachable. Confirm the chosen layout handles the intended prefix-change workflow without broadening firewall permissions unintentionally.\n\n## Official reference\n\n[Netgate — Design Considerations](https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/design.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/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/", "url": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/#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": "Choose one-peer or shared pfSense WireGuard tunnels around route ownership", "item": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/#article", "identifier": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/", "url": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/", "headline": "Choose one-peer or shared pfSense WireGuard tunnels around route ownership", "description": "A routing protocol cannot replace cryptokey peer selection inside a shared multi-peer tunnel.", "abstract": "A routing protocol cannot replace cryptokey peer selection inside a shared multi-peer tunnel.", "articleBody": "A routing protocol cannot replace cryptokey peer selection inside a shared multi-peer tunnel.\nSource facts\nNetgate explains that a WireGuard instance with several peers needs each peer’s routed networks defined for cryptokey routing. With one peer per interface, a broad Allowed IPs entry can identify that sole peer while an operating-system routing protocol manages which traffic reaches the interface. Endpoint definition also affects which side can initiate and supports roaming peers.\nSource: Netgate — Design Considerations.\nApplicability\nThis concerns the pfSense WireGuard topology decision.\nDSE recommendation\nDSE recommends identifying who owns remote-prefix changes before choosing a shared or per-peer layout. If dynamic routing is required, keep operating-system route selection distinct from cryptographic peer selection. Record endpoint initiation and roaming expectations for each connection. Prefer a diagram that shows tunnel interfaces, peers, Allowed IPs, and advertised routes together so later subnet additions do not create an unexplained black hole. Review a proposed new remote subnet as part of the topology choice. Ask who will update peer ownership and who will advertise the operating-system route, and show both entries in the design. Keep one-peer and shared-tunnel examples separate so their maintenance obligations remain visible.\nVerification\nIn a lab, add an approved remote prefix and verify both the operating-system route and the peer selected for encryption. Test return traffic and a prefix that should not be reachable. Confirm the chosen layout handles the intended prefix-change workflow without broadening firewall permissions unintentionally.\nOfficial reference\nNetgate — Design Considerations. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:16:27+00:00", "dateModified": "2026-10-20T18:34:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/" }, "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/choose-one-peer-or-shared-pfsense-wireguard-tunnels-around-route-ownership/#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": "Choose one-peer or shared pfSense WireGuard tunnels around route ownership" }, "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": 244, "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 — Design Considerations", "url": "https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/design.html" } } ] } }