Magic Sites feels like a much better site-to-site VPN implementation to alternatives as it supports all the scenarios that plague traditional site-to-site VPN setup in Unifi, such as when you failover to your secondary WAN connection, or dynamic IP addresses / FQDN support, etc. But, figuring out how to route traffic over the magic site VPN remains a mystery to me -- if we could get split-vpn to work with magic sites it would be awesome!

Running ip route show, I see similar output to @sidprax (my remote network reached via the VPN is 192.168.2.0/24):

ip route show 192.168.2.0/24
192.168.2.0/24 via 192.168.1.0 dev wgsts1000 proto ospf metric 20 onlink

The 192.168.1.0 is not a routable address, as @peacey noted, but it's what appears here. Note if you just run ip route show you will see this, note the two entries related to the wireguard site-to-site VPN (wgsts1000):

24.171.201.1 dev ppp0 proto kernel scope link src 70.45.6.247   # My Primary Internet 
100.64.0.0/10 dev eth7 proto kernel scope link src 100.100.44.63  # My Starlink Secondary
192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.1 
192.168.1.0 dev wgsts1000 proto kernel scope link
192.168.2.0/24 via 192.168.1.0 dev wgsts1000 proto ospf metric 20 onlink

I have noticed that even though the address shown is 192.168.1.0 (not routable), going to 192.168.1.1. brings up the UDM Pro (even though my local network is 192.168.0.1.

In vpn.conf, I have experimented getting split-vpn to work with the following settings, to no avail:

DEV=wgsts1000
BYPASS_MASQUERADE_IPV4="ALL" (also tried BYPASS_MASQUERADE_IPV4="")
VPN_ENDPOINT_IPV4= I tried the gateway of the remote network (192.168.2.1) similar to how split-vpn works for an IPSec VPN, I also tried 192.168.1.0 which is the weird broadcast address provided by ip route show, similar to how split-vpn works for an OpenVPN, I also tried 192.168.1.1. When using 192.168.1.1 or 192.168.0.1, the script runs without complaining but reaching the FORCED destinations does not work. When using the remote site's router (192.168.2.1), the script fails with Error: Nexthop has invalid gateway..

By saying "reaching the FORCED destinations does not work", what I mean is, consider this example, whatismyip.com is forced using IP sets, its IP address is 172.67.189.152. I attempt to ping it from my local network host (192.168.0.84) while running tcpdumnp on the local UDM Pro.

Behavior when split-vpn is DOWN / turned off (normal, expected behavior, going out over the WAN interface):

#  tcpdump -ni any host 172.67.189.152
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:45:27.387920 switch0 In  IP14 (invalid)
11:45:27.387920 switch0.1 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 59900, seq 0, length 64
11:45:27.387920 br0   In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 59900, seq 0, length 64
11:45:27.387980 ppp0  Out IP 70.45.6.247 > 172.67.189.152: ICMP echo request, id 59900, seq 0, length 64
11:45:27.416340 ppp0  In  IP 172.67.189.152 > 70.45.6.247: ICMP echo reply, id 59900, seq 0, length 64
11:45:27.416382 br0   Out IP 172.67.189.152 > 192.168.0.84: ICMP echo reply, id 59900, seq 0, length 64
11:45:27.416387 switch0.1 Out IP 172.67.189.152 > 192.168.0.84: ICMP echo reply, id 59900, seq 0, length 64

Behavior when split-vpn is UP / turned on, with VPN_ENDPOINT_IPV4=192.168.1.1 -- appears to be in a loop:

#  tcpdump -ni any host 172.67.189.152
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:43:17.246175 switch0 In  IP14 (invalid)
11:43:17.246175 switch0.1 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.246175 br0   In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.246220 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.319732 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.319759 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.393499 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.393524 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.467263 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.467290 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.541941 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.541962 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.615379 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.615400 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.689211 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.689237 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.764531 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.764555 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.839995 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.840019 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.915014 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.915040 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.989137 wgsts1000 In  IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
11:43:17.989169 wgsts1000 Out IP 192.168.0.84 > 172.67.189.152: ICMP echo request, id 20476, seq 0, length 64
( continues like this ad infinitum)

Sorry I am not much of a networking whiz, but would love to get split-vpn working with the magic site stuff as it is so far superior to any other UDM solution for site-to-site VPN. Feedback / suggestions welcome.

Enable split script to use Magic SD-WAN #194

Description

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions