I wanted a small, low-maintenance way to route selected devices at my home in France through a trusted residential internet connection in Japan.
The use case is simple: streaming devices in France should appear to be on the Japanese home connection, while the rest of the home network should continue using the normal French internet connection.
The setup uses:
- a GL.iNet GL-SFT1200 / Opal in Japan as the WireGuard server
- a GL.iNet GL-MT6000 / Flint 2 in France as the WireGuard client
- the existing guest Wi-Fi VPN policy on the GL-MT6000, which was already being used with NordVPN before
The nice part is that GL.iNet firmware can bind a VPN client to the guest Wi-Fi, so I did not need to build a custom VLAN/policy-routing setup from scratch.
Topology
Japan home
----------
ISP router
|
| Ethernet
v
GL-SFT1200
WireGuard server
|
| Internet
v
France home
-----------
GL-MT6000 / Flint 2
WireGuard client
|
+-- Main LAN/Wi-Fi: normal French internet
|
+-- Guest Wi-Fi: routed through Japan WireGuard tunnel
The Japan-side GL-SFT1200 is connected behind the existing ISP router.
ISP router LAN port -> GL-SFT1200 WAN port
The ISP router remains the normal household router. The GL-SFT1200 only acts as a VPN gateway.
Japan-side setup
The GL-SFT1200 is given a fixed private address on the ISP router LAN.
Example using sanitized addresses:
ISP router LAN IP: 192.168.0.1
GL-SFT1200 WAN IP: 192.168.0.5
GL-SFT1200 WireGuard IP: 10.20.0.1
On the ISP router, I added a NAT/port-forwarding rule for WireGuard:
Protocol: UDP
External port: 51820
Internal host: 192.168.0.5
Internal port: 51820
This requires the Japan-side connection to be reachable from the internet. If the ISP uses CGNAT, DS-Lite, MAP-E, or another IPv4-sharing setup, direct inbound WireGuard may not work without IPv6, Tailscale, or a relay.
WireGuard server on the GL-SFT1200
Enabled Dynamic DNS on the GL-SFT1200 as the IP is not static on the Japanese side. It is provided by GL.inet =>
The WireGuard server was enabled from the GL.iNet web interface.
The VPN subnet is separate from both home LANs:
WireGuard subnet: 10.20.0.0/24
Japan router VPN IP: 10.20.0.1
France router VPN IP: 10.20.0.2
The GL-MT6000 in France was added as a WireGuard peer.
The client profile uses:
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
AllowedIPs = 0.0.0.0/0 allows the France-side router to send internet-bound traffic through the Japan tunnel.
WireGuard client on the GL-MT6000
On the GL-MT6000, I imported the WireGuard client profile generated by the GL-SFT1200.
The tunnel came up correctly:
Interface: wgclient
Client VPN IP: 10.20.0.2
Peer endpoint: <host>.glddns.com:51820
Allowed IPs: 0.0.0.0/0
The router showed a recent WireGuard handshake and increasing RX/TX counters.
wg show
At this point, the VPN tunnel itself was working.
Guest Wi-Fi routing
The GL-MT6000 was already configured to route its guest Wi-Fi through a VPN client. Previously, that VPN client was NordVPN.
For this setup, I reused the same GL.iNet feature and replaced the VPN target with the new WireGuard tunnel to Japan.
The desired behavior is:
Main LAN/Wi-Fi -> normal French internet
Guest Wi-Fi -> Japan WireGuard tunnel
This is handled by GL.iNet’s built-in VPN policy feature rather than custom firewall rules.
Testing from the router itself
One important detail: traffic generated directly from the router SSH shell is not handled the same way as traffic from LAN or guest Wi-Fi clients.
The guest Wi-Fi may be correctly tied to the VPN, but commands run from the router itself may not use that same policy.
For testing from SSH, I temporarily added explicit routes and firewall rules.
On the GL-MT6000 in France:
ip route replace 10.20.0.1/32 dev wgclient1 src 10.20.0.2
On the GL-SFT1200 in Japan:
ip route replace 10.20.0.2/32 dev wgserver src 10.20.0.1
Then I allowed testing traffic on the WireGuard interfaces.
On the GL-SFT1200:
iptables -I INPUT -i wgserver -s 10.20.0.2 -j ACCEPT
On the GL-MT6000:
iptables -I INPUT -i wgclient1 -s 10.20.0.1 -j ACCEPT
These were temporary test rules, not part of the normal client-facing setup.
With those in place, I could test router-to-router connectivity:
ping -c 4 -I 10.20.0.2 10.20.0.1
And internet connectivity through the tunnel:
ping -I 10.20.0.2 -c 10 1.1.1.1
The internet ping test showed roughly:
Latency: ~245 ms
Packet loss: 0%
That is acceptable for France -> Japan -> internet -> back.
Bandwidth testing with iperf3
The important direction for this use case is:
Japan -> France
That is the direction used when a streaming device in France downloads content through the Japanese connection.
I installed iperf3 on both routers.
On one side:
iperf3 -s
From the other side:
iperf3 -c 10.20.0.1 -B 10.20.0.2 -t 300 -P 4 -R
The -R flag matters. It makes the remote host send data back, which tests the Japan-to-France direction.
The result over five minutes was:
Transfer: ~2.7 GB
Bitrate: ~77.7 Mbit/s
Retransmit: 1
Duration: 300 seconds
For a compact GL-SFT1200 acting as the WireGuard server, this is a very good result.
Real internet download test
iperf3 proves the tunnel is fast router-to-router, but I also wanted to test a real internet download through the Japanese exit path.
From the GL-MT6000 SSH shell, I bound curl to the WireGuard source address:
curl -4 --interface 10.20.0.2 -L -o /dev/null \
-w 'HTTP=%{http_code} size=%{size_download} bytes speed=%{speed_download} B/s time=%{time_total}s\n' \
'https://speedtest.jp.cherryservers.com/test-1000mb'
Result:
HTTP=200
size=1073.7 MB
time=109.2 s
avg=78.6 Mbit/s
This was very close to the iperf3 result, which confirmed that the setup was not only fast between routers, but also worked well for real internet downloads through Japan.
Result
The Japan-to-France WireGuard path is working and stable.
Measured performance:
WireGuard router-to-router: ~77.7 Mbit/s sustained
Real Japan-hosted HTTP download: ~78.6 Mbit/s
Latency via Japan tunnel: ~245 ms
Packet loss during ping test: 0%
For the intended use case, this is more than enough for normal Japanese TV streaming and should also be fine for high-quality 1080p or moderate-bitrate 4K.