↓ Skip to main content

VLAN Through SpeedFusion

·1559 words·8 mins

Route a VLAN Through SpeedFusion to a FusionHub — Peplink B One + Ubiquiti UDM
#

The scenario: You have a Ubiquiti UDM (or UDM Pro) behind a Peplink router. You want traffic from one specific VLAN on the UDM to exit the internet via a SpeedFusion tunnel to a remote FusionHub — not via your local WAN. Every other VLAN continues to use the local internet normally.

We couldn’t find a complete guide for this combination anywhere online. Here’s what actually works.

Why This Is Harder Than It Looks
#

The Peplink router sits between your ISPs and your UDM. From the Peplink’s perspective, all traffic from the UDM looks like it comes from a single IP — the UDM’s WAN address (e.g., 192.168.60.30). The Peplink has no visibility into which VLAN inside the UDM originated the traffic.

This means you cannot simply write a Peplink outbound policy matching your VLAN subnet (e.g., 192.168.3.0/24). The Peplink never sees that subnet — it only sees the UDM’s WAN IP.

The solution is a SNAT trick on the UDM that makes VLAN traffic appear to come from a distinct, dedicated IP that the Peplink can match.

Architecture Overview
#

VLAN client (192.168.3.x)
  ↓  [UDM: SNAT to 192.168.60.100]
Peplink router (192.168.60.1)
  ↓  [Outbound policy: source 192.168.60.100 → SpeedFusion tunnel]
SpeedFusion VPN
  ↓
FusionHub at remote site
  ↓  [Peer NAT → egress via FusionHub's WAN IP]
Remote internet (Oregon, NYC, wherever your FusionHub is)

What You Need
#

  • Peplink router (B One, Balance, etc.) as the WAN gateway

  • Ubiquiti UDM or UDM Pro behind the Peplink (UDM’s WAN port plugged into Peplink’s LAN)

  • Peplink FusionHub at a remote site (cloud VM, data center, or another physical location)

  • SpeedFusion VPN tunnel already established between the Peplink and FusionHub

  • SSH access to the UDM (root)

  • UniFi VLAN configured for the traffic you want to redirect

Step 1 — Pick a Dedicated SNAT Address
#

Choose an unused IP in the Peplink’s LAN subnet. This will be the “identity” of your VLAN traffic from the Peplink’s point of view.

In this example:

  • Peplink LAN subnet: 192.168.60.0/24

  • UDM WAN IP: 192.168.60.30

  • SNAT address: 192.168.60.100 (unused, won’t conflict)

  • VLAN to redirect: 192.168.3.0/24 (VLAN 3, VPN2USA SSID)

Step 2 — Configure the UDM (SNAT + Secondary IP)
#

SSH into your UDM as root. Create the boot script that adds the secondary IP and the SNAT rule:

cat > /data/on_boot.d/99-vlan-to-vpn.sh << 'EOF'
#!/bin/sh
sleep 10

# Add secondary IP on the WAN interface (eth8 = UDM's WAN port to Peplink)
# This lets the Peplink ARP-resolve 192.168.60.100 back to the UDM
ip addr add 192.168.60.100/24 dev eth8 2>/dev/null || true

# SNAT all VLAN 3 traffic to 192.168.60.100 before it goes out to the Peplink
iptables -t nat -I UBIOS_POSTROUTING_USER_HOOK 1 \
  -s 192.168.3.0/24 -o eth8 -j SNAT --to-source 192.168.60.100
EOF

chmod +x /data/on_boot.d/99-vlan-to-vpn.sh
bash /data/on_boot.d/99-vlan-to-vpn.sh

The script goes in /data/on_boot.d/ which the UDM runs on every boot. The sleep 10 gives interfaces time to come up before applying the rules.

Verify it worked:

# Should show 192.168.60.100/24 on eth8
ip addr show eth8

# Should show your new SNAT rule at the top
iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK -n -v | head -5

Important: eth8 is the WAN port on a UDM Pro. On other UDM models it may be eth0 or eth4 — check with ip addr show to find which interface has your Peplink LAN IP.

Step 3 — Configure the Peplink Outbound Policy
#

In the Peplink web UI, go to Network → Outbound Policy and add a new rule:

FieldValueNameVPN2USARULE (or anything descriptive)ProtocolAnySource192.168.60.100/32 (the SNAT address from Step 1)DestinationAnyAlgorithmEnforcedEnforced ConnectionSpeedFusion VPN →

\[your tunnel to FusionHub\]

Move this rule above any default rules. Save.

This tells the Peplink: any traffic appearing to come from 192.168.60.100 must go through the SpeedFusion tunnel. No fallback, no WAN leak.

Step 4 — Configure the FusionHub
#

This is where most guides fall short. All three of these settings must be correct, and the third one is the most commonly missed.

4a. Routing Mode: NAT (not IP Forwarding)
#

In the FusionHub local web UI, go to Network → WAN and confirm:

  • Routing Mode: NAT

Do not use IP Forwarding mode. In IP Forwarding mode, the Peer NAT checkbox appears and looks correct, but peer internet traffic is silently dropped — the FusionHub will reach the internet for its own traffic but will not forward peer traffic to WAN. This is a known behavior that is not documented clearly anywhere.

4b. Peer NAT: On
#

On the same WAN configuration page, enable:

  • Apply NAT on Remote Peers’ Outgoing Internet Traffic: checked

This SNATs your VPN clients’ traffic to the FusionHub’s WAN IP before sending it to the internet. Without this, return traffic has no way to find its way back.

4c. Route SpeedFusion VPN Traffic to LAN: Off (leave unchecked)
#

This checkbox, if enabled, sends SpeedFusion traffic to the FusionHub’s LAN port rather than out the WAN — the opposite of what you want for internet egress. Leave it unchecked.

4d. Click “Apply Changes”
#

This is the step that burned us for days.

FusionHub separates “saved configuration” from “running configuration.” After changing any setting, you must click the Apply Changes button on the dashboard. Until you do, the UI shows the correct settings but the running iptables rules are stale — peer traffic will be silently dropped with no error.

If you see a yellow “Changes pending.” warning on the FusionHub dashboard, click Apply Changes before testing anything.

4e. SpeedFusion VPN Profile
#

If your FusionHub is managed via InControl2 (ic2.peplink.com), note that the SpeedFusion VPN profile — including peer connections and tunnel settings — can only be edited in InControl2, not in the FusionHub local UI. The local UI shows the profile as locked.

Step 5 — Test
#

From the UDM, test using the VLAN source address directly:

# On the UDM:
curl --interface 192.168.3.1 --max-time 15 ifconfig.me

This sends a request sourced from the VLAN 3 gateway IP, which triggers the SNAT → SpeedFusion path. You should see the FusionHub’s public IP (your remote location’s IP), not your local WAN IP.

From an actual VLAN 3 client device, browse to any “what is my IP” site — it should show your remote location.

Troubleshooting
#

Traffic exits via local WAN instead of SpeedFusion
#

  • Verify the SNAT rule is active: iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK -n -v

  • Verify the secondary IP is on the interface: ip addr show eth8

  • Check the Peplink outbound policy matches 192.168.60.100/32 (not the whole /24)

  • In Peplink → Status → Active Sessions, filter by the SNAT IP — does it show the SpeedFusion connection?

Traffic reaches FusionHub but doesn’t exit to internet
#

  • Check FusionHub dashboard for “Changes pending.” — click Apply Changes

  • Confirm Routing Mode is NAT, not IP Forwarding

  • Confirm Peer NAT is checked

  • Confirm FusionHub’s own internet works (Status → ping test to 8.8.8.8)

SpeedFusion tunnel is down
#

  • Peplink and FusionHub firmware must be compatible — avoid FusionHub firmware 8.4.0 (peer NAT bug), use 8.4.1+

  • If FusionHub is behind double NAT: ensure the outer router has a DMZ or port forward for UDP 4500 pointing to the FusionHub

UDM reboots and routing breaks
#

  • The /data/on_boot.d/ directory is persistent on UDM. Verify the script is executable (chmod +x)

  • UDM OS updates occasionally wipe on_boot.d — check after any firmware update

  • To verify after reboot: ip addr show eth8 | grep 192.168.60.100 and iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK -n

IPv6 shows the wrong location
#

SpeedFusion tunnels IPv4 only. If your VLAN clients have global IPv6 (from a prefix delegation), that IPv6 traffic will exit via your local WAN, not through SpeedFusion. To prevent this, disable IPv6 on the VLAN in UniFi Network settings, or block IPv6 forwarding from that bridge:

ip6tables -I FORWARD -i br3 -j DROP
ip6tables -I FORWARD -o br3 -m state --state ESTABLISHED,RELATED -j ACCEPT

If clients only have fe80:: (link-local) IPv6 — which is the case when you’ve disabled IPv6 RA/DHCPv6 for that network in UniFi — there’s nothing to worry about. Link-local addresses cannot reach the internet.

Why the SNAT Address Needs to Be in the Peplink’s Subnet#

The UDM adds 192.168.60.100/24 to eth8 (not just a host route). This means:

  1. The Peplink can ARP for 192.168.60.100 and the UDM will answer — making the Peplink aware that 192.168.60.100 exists on its LAN

  2. The UDM’s kernel knows to send reply traffic for 192.168.60.100 back out eth8 (not a different interface)

  3. Conntrack on the UDM can correctly de-SNAT the returning traffic and deliver it to the original 192.168.3.x client

If you used an IP outside the Peplink LAN subnet, the ARP would fail and reply traffic would be black-holed.

Summary
#

WhatWhereSettingSecondary IP + SNAT ruleUDM /data/on_boot.d/192.168.60.100 on eth8, SNAT from VLAN subnetOutbound policyPeplink web UISource 192.168.60.100/32 → Enforced SpeedFusionRouting ModeFusionHub local UI → WANNAT (not IP Forwarding)Peer NATFusionHub local UI → WANCheckedRoute to LANFusionHub local UI → WANUncheckedApply ChangesFusionHub dashboardALWAYS click after any config changeVPN profileInControl2 (not FusionHub UI)Managed remotely

The pattern generalizes: any traffic source you want to route through a specific Peplink tunnel just needs a distinct SNAT address in the Peplink LAN subnet. You can run multiple VLANs through different SpeedFusion tunnels by giving each one its own SNAT address and matching outbound policy rule.