How to Resolve Synology DDNS Failures with Dual‑PPPoE and IPSec VPN on vSRX

The author’s network uses a dual‑PPPoE setup with two exits and a vSRX firewall. To separate domestic and international traffic, about 8,000 domestic CIDR blocks are imported as static routes, while the default route 0.0.0.0/0 points to the IPSec VPN interface st0.0.

Problem: DDNS Fails When IPSec Is Up

Because the default route becomes active only after the IPSec tunnel is established, Synology DSM’s DDNS packets sometimes have no valid route, causing DDNS updates to fail. QuickConnect continues to work because it uses the internal network segment, which still has a reachable path.

Initial Diagnosis

Enabling SSH on the Synology NAS and logging in as root (password same as admin) allows packet capture with tcpdump. The capture shows that the DDNS packets cannot find a route when the IPSec tunnel is up.

First Fix: Add a pp0.0 Nexthop to the Default Route

lab@vSRX# show routing-options static route 0/0
next-hop 10.0.65.2;
qualified-next-hop pp0.0 {
    metric 100;
}

Adding the pp0.0 nexthop ensures that, if the IPSec tunnel is unavailable, traffic still exits via the PPPoE interface.

Observed Behavior After the Fix

When the IPSec VPN is not dialed, DDNS works correctly.

When the IPSec VPN is dialed, the DDNS update sometimes resolves to the public IP of the VPN’s remote endpoint because the default route prefers st0.0.

Second Fix: Add Static Routes for DDNS‑Related Destination Subnets

Capture the DDNS traffic to identify the destination subnets used during the update process:

tcpdump -i eth0 -s 0 -n src host 172.16.10.22 -w ddos01.pcap

Analysis reveals several /24 networks involved in the DDNS process. Adding static routes for these networks with a pp0.0 nexthop forces the DDNS packets to leave via the PPPoE interface regardless of the IPSec tunnel state.

lab@vSRX# show | compare rollback 2
[edit routing-options static]
+    route 60.251.87.0/24 next-hop pp0.0;
+    route 54.64.187.0/24 next-hop pp0.0;
+    route 54.148.98.0/24 next-hop pp0.0;
+    route 54.64.93.0/24 next-hop pp0.0;
+    route 54.69.83.0/24 next-hop pp0.0;
+    route 54.93.172.0/24 next-hop pp0.0;

Verification

Confirm the PPPoE interface status:

lab@vSRX# run show interfaces terse pp0
Interface   Admin Link Proto   Local               Remote
pp0         up    up
pp0.0       up    up   inet 111.194.xxx.xxx   --> 111.194.xxx.1

With these adjustments, DDNS updates succeed whether the IPSec VPN is active or not, and the resolved IP always reflects the public address of the PPPoE exit.