Practical Approaches to Site-to-Site Network Connectivity in a Cross-Border Home Broadband Environment

The current situation is as follows:

• Both locations only have public IPv4 addresses.
• The public IP address is unreliable. The address in China changes periodically due to PPPoE dial-up, while the address in Hong Kong remains unchanged for a longer period but may change if the router is restarted.
• A simple topology is shown in the header image. There is a small host on the internal network in China that can deploy VM machines, while the internal network in Hong Kong has only a NAS, making operations relatively limited.

Option 1: WireGuard Networking

For a site-to-site network, the simplest method is to use WireGuard along with the corresponding Allowed IPs. Below is an example of the wg0.conf file for the China side, and the configuration for the other side can simply be written in reverse:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = ---

MTU = 1412
PostUp = iptables -I FORWARD -i wg0 -j ACCEPT; iptables -I FORWARD -o wg0 -j ACCEPT; iptables -I INPUT -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -D INPUT -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens18 -j MASQUERADE

[Peer]
PublicKey = ---
PresharedKey = ---
AllowedIPs = 10.8.0.2/32
AllowedIPs = 10.145.1.0/24
Endpoint = x.x.x.x:51920
PersistentKeepalive = 30

After starting the VPN tunnel on both sides, since WireGuard isn’t running on the router, you’ll need to configure a static route on the router to direct the other side’s LAN subnet to the WireGuard server address. The NAT actions are already handled in the PostUp script.

Option 2: Tun to Socks5

If the VPN channel is only established between the two subnets, then Option 1 is essentially complete, allowing for TCP/UDP/ICMP intercommunication. However, the actual situation is:

1. Due to issues with ISPs or other factors from China to Hong Kong, WireGuard experiences significant interference and QoS degradation – WireGuard operates through UDP, but the host on the Hong Kong side is a NAS, making the use of udp2raw inconvenient.
2. Due to the public IP in China changing every 4-5 days, the WireGuard VPN will become inactive after the IP address changes and requires a manual restart – I tried configuring a domain name in wg0.conf for dynamic IP resolution, but it seems that WireGuard doesn’t automatically restart the interface after disconnection, rendering this solution ineffective.

In this case, we have to consider other methods to resolve the issue, such as routing traffic over a stable channel that isn’t affected by QoS and cross-border limitations. With these requirements in mind, I attempted to use TCP protocol along with a request initiated from Hong Kong to China to establish a channel and address the issues experienced with WireGuard.

On the China-side host, deploy FRPS, and connect from Hong Kong as a client, with TLS encryption enabled.

I chose to deploy a Squid proxy on the NAS in Hong Kong, exposing it for use in China via FRP. Since the traffic won’t appear as direct HTTP packets due to being wrapped by FRP, it incurs less performance loss compared to traditional protocols like Shadowsocks, Trojan, or V2Ray, which require content encryption.

Here’s an example of the configuration content for the FRPS part (just set up port mapping on the router to expose port 7000):

[common]
bind_addr=0.0.0.0
bind_port = 7000

# Dashboard can be enabled as needed
dashboard_addr=0.0.0.0
dashboard_port=7500
dashboard_user=sample
dashboard_pwd=sample

token = sample

And the configuration for the frpc part:

[common]
server_addr = --- # Enter domain name; frpc will attempt to reconnect automatically
server_port = 7000
tls_enable = true

token = sample

[squid]
type = tcp
local_ip = 127.0.0.1
local_port = 3128
remote_port = xxx

Once Squid is mapped to the internal network, you can access the Hong Kong internal network via this proxy. However, to achieve zero configuration on the client-side, you’ll also need to convert the proxy to a TUN interface. For example, you can use the following tool:

Refer to the README file of the referenced project to launch the program. We don’t need to hijack all the traffic, but only direct the IPs accessing the Hong Kong internal network to the TUN interface route:

ip route add 10.145.1.0/24 dev tun0

At this point, the FRPS host can access the Hong Kong internal network. However, if we want devices on the local network in China to also access the Hong Kong internal network, we will similarly need to configure static routes and perform NAT conversion on the FRPS host:

# The following commands configure route forwarding and NAT conversion; static routes should be set on the router. Adjust ens18/tun0 based on actual setup.
iptables -A FORWARD -i tun0 -o ens18 -j ACCEPT
iptables -A FORWARD -i ens18 -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

At this point, the site-to-site connection on both sides is set up. You can perform some tests to check the results (the upload bandwidth on the China side is 50 Mbps and download is 1000 Mbps; on the Hong Kong side, both upload and download are 1000 Mbps):

iPerf Test

Speedtest Test

Fast.com Test

YouTube 8K Streaming Test