Add a site VPN beside the ISP router without breaking calls

Most small sites already have one box doing internet, DHCP and the voice line, and that box is not going to run your site tunnel. Adding a second gateway for the private path works, provided you settle who owns each route before touching a cable. The risk is not the tunnel; it is quietly changing the device that keeps the phones registered. Work the five checks in order and stop where one fails.

Write down the roles that already work

Record the default gateway, the DHCP server, the resolver, and which device holds the provider's voice registration. In the example used here the ISP router is 10.50.0.1 and the new gateway will sit at 10.50.0.2, with the remote site on 10.60.0.0/24. Nothing in that plan changes the first three roles, which is exactly the point. Then confirm the second box can actually terminate the tunnel you need: check the protocol, the throughput you expect, and whether it receives firmware or package updates. A device with a VPN logo and no update path is a liability rather than an addition.

If you cannot state who owns the voice service, stop. Changing the router that holds a registration without a rollback plan is how a VPN project becomes a phone outage.

Give the new gateway one address and one job

Reserve its LAN address outside the DHCP pool so it cannot move after a reboot, and give it no default route of its own unless you intend it to become an internet path. Its job is to hold the tunnel and answer for remote prefixes. On the LAN hosts that must reach the remote site, prove which path they take now and which one you want them to take after the change. Running the same two commands before and after is the cheapest evidence you will get.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

If the lookup already returns the ISP router and the traceroute dies at the internet edge, the host has no remote-site path yet, which is expected. If it returns something unexpected, resolve that first, because every later step assumes this baseline.

Choose who owns the remote-prefix route

Option A is the ISP router: it holds a static route for 10.60.0.0/24 pointing at the gateway, and every host follows its default gateway as before. Option B is per host: only the machines that need the remote site get an explicit route through 10.50.0.2, and everything else stays untouched. Option A is cleaner for many hosts but usually means the provider's router must accept a static route at all, which some do not. Option B needs no cooperation from the provider but leaves you maintaining host configuration, so it suits a small approved set of machines.

Either way, the return direction has to exist. If a remote reply comes back to the gateway and the gateway forwards straight to a LAN host, the traffic skips any firewall state the ISP router was keeping on the forward path. When the gateway is not the LAN's default router, that asymmetry is a design decision, not a bug you can ignore.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Persist the entry through the host's configuration owner rather than a login script. A route that only exists after someone logs in will fail the first time the machine is rebooted for an unrelated reason.

Arrange a reachable inbound endpoint

The gateway needs an address the remote site can reach. Behind the ISP router that means a port forward or a DMZ entry, and both depend on the ISP actually delivering the traffic to you. A local forward cannot overcome carrier-grade NAT on the provider's side. If the provider will not give you a reachable endpoint, invert the direction: let both sites initiate toward a hub you control. That is a valid design, but it adds a third dependency for forwarding, trust and availability, and dynamic DNS does not substitute for it.

Confirm the forward with a capture at the gateway, not with a port-scanning website. Scanners report the port closed until the listener is actually bound, and a forward that never delivers traffic looks identical to a closed port from outside.

Accept the private service and the voice line together

Test the intended operation from a LAN host, using private DNS and the application's own credentials. A routed tunnel does not make remote browsing look like a local Ethernet segment, so discovery and name resolution need their own arrangements.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Then confirm that ordinary internet access still works from the same host and that the phones are still registered. Those two checks are the ones that catch an accidental default-route change, which is the most common way this project breaks something it never intended to touch. Finish with a written recovery note: which device owns which role, the reserved addresses, and how to remove the remote-prefix route in one step. A private path that can be withdrawn cleanly is worth more than one that merely works today.