Connecting a remote worker or a remote branch raises one question: once this path is open, who else can walk it. The design answers that question first.
Done Dynamics designs and operates VPN setups, site-to-site branch connectivity and remote worker access. We treat two needs separately: one person connecting to the company from home or the road is not the same job as two locations behaving permanently as a single network. The first is decided by authentication and device trust; the second by address planning, routing and redundancy. In both cases we keep configuration files under version control, monitor tunnels continuously, and write down what happens when a link drops before the deployment starts. On site around Alanya and Antalya, remotely across Turkey.
In most networks we inherit, remote access has been solved with a port forward on the modem rather than a VPN. It works the day it is set up and causes problems in the weeks that follow.
The most common mistake we inherit. Someone needs the accounting software from home, a port forward gets written on the modem, and the matter is considered closed. It is not: a remote desktop port facing the internet is found within minutes by automated scanners that sweep the entire address space continuously. Once found, password guessing traffic arrives around the clock and never stops.
Using 33890 instead of 3389 is not protection. Scanners do not try known ports one by one; they sweep the whole range and identify the service behind it from its response. A non-standard port only makes your own logs harder to read — it does not shrink the attack surface.
Leaked credential lists and passwords reused inside the organisation mean single-factor access does not survive long. As long as guessing traffic continues at a steady rate, finding the right password becomes a statistical question of time. Lockout policy slows this down; it does not remove it.
Failed login attempts are already recorded in most organisations, but nobody looks at them. A sudden rise in attempt volume is the warning that precedes the next step. On every access path we build, we define up front where the log is written, how long it is kept and who reads it.
A single user connecting to the company. The easy part is bringing the tunnel up; the real work is proving the person is who they claim to be, that the device belongs to the company, and that only the required resources are reachable at the far end.
Multi-factor authentication
A password alone is no longer considered sufficient. On client VPN deployments we enable the second factor by default: an app-generated one-time code or a hardware key. Even if the password leaks, it is not enough to get in on its own.
Device-level authorisation
Verifying the user is half the job; the other half is whether the connecting device belongs to the company. With certificate-based device identity, the same username connecting from a personal laptop is either refused or given access to a limited segment only.
Narrowing the access scope
Not everyone who connects to the VPN needs to see the whole network. Accounting staff should not reach server management interfaces, and field staff should not reach the accounting database. Which addresses and which ports are open at the far end of the tunnel is written per user group.
The split tunnel decision
Should all traffic go through the tunnel, or only traffic destined for company resources? If everything goes through, corporate rules and content filtering apply to the remote user too, but their internet speed depends on the head office link. If only company traffic goes through, speed is preserved and control is reduced. This is a business preference rather than a technical constraint; we can build either.
Closing the DNS leak
The most frequently skipped detail in split tunnelling. The tunnel comes up, traffic flows correctly, but name resolution keeps going to the device local DNS server. The result splits two ways: either internal server names never resolve, or internal names are asked of an external resolver. DNS routing is configured explicitly and verified after the connection is established.
Account lifecycle
Removing VPN access for a departing employee is simple on paper and the step that fails most often in practice. We bind access to the corporate identity directory; when the staff record is closed the tunnel closes with it, and no separate list needs updating.
A site-to-site VPN joins two or more locations with a permanent tunnel. The difference from a client VPN is that the user launches nothing and logs in nowhere. The tunnel is built device to device and stays up continuously; a branch workstation reaches the head office server as if it were in the next room. Done properly, the user never knows the VPN exists — which is the point.
This design is not built for file sharing alone. Branches joining central authentication, cameras and phone systems managed from head office, backup traffic flowing without touching the public internet — all of it rides on the same tunnel. Five separate problems that would otherwise be reconsidered at every branch opening collapse into one design decision.
This is the most frequent site-to-site problem we see in the field. Deployment finishes, both ends complete their handshake, the tunnel status shows green — and yet not a single packet reaches head office from the branch. The cause is almost always the same: both locations use the same default local address block. When modems are commissioned with factory settings, this is unavoidable.
The mechanism is this: when a branch machine tries to send a packet to an address at head office, it assumes that address is on its own local network and never hands the packet to the tunnel. The tunnel is healthy and the routing is correct; the fault is in the address plan, not in the device. That is why we catch overlaps during discovery rather than during deployment.
The permanent fix is renumbering: each location gets its own non-overlapping block and the plan is documented. Where renumbering is impossible — hundreds of devices carrying static addresses, for example — we apply address translation over the tunnel so each location presents itself to the other with a different block. That approach works, but left undocumented it turns into a network nobody understands a few years later. So we hand over the translation table together with the configuration.
Example address plan
| Location | Block | Scope |
|---|---|---|
| Head office | 10.10.0.0/16 | Servers and staff |
| Branch 1 | 10.21.0.0/16 | Local network and POS |
| Branch 2 | 10.22.0.0/16 | Local network and cameras |
| Client VPN | 10.90.0.0/16 | Remote user pool |
The scheme is an example. What matters is not the numbers but the principle: a distinct and predictable block per location, room reserved in advance for new branches, and the client pool kept apart from branch blocks.
With two locations there is no topology debate: one tunnel is built and the job is done. The first decision point arrives with the third location. In a hub-and-spoke layout every branch connects only to head office. Management is simple, the tunnel count equals the location count, and because all traffic passes through the centre, security rules live in one place. The cost is that branch-to-branch traffic detours through head office and the central link becomes a shared bottleneck.
In a full mesh every branch connects directly to every other branch. Latency drops to its minimum, but the tunnel count grows with the square of the location count: five branches mean ten tunnels, ten branches mean forty-five. Nobody maintains that by hand. In practice the layout we build most often sits between the two: the base scheme stays hub-and-spoke, and direct tunnels are added only between branches with heavy mutual traffic. That call rests on measurement rather than preference — we measure which branch talks to which, and how much, before deciding.
All three are sound. The choice is set by your device list and throughput expectation, not by ideology.
Speed and simplicity
A small code base makes it easy to review, and connection setup is nearly instant. On the same hardware it delivers noticeably higher throughput than IPsec. Its configuration file is short, which reduces the chance of a misconfiguration.
When: Newly built networks, server-to-server tunnels, remote worker access, and branch links where throughput matters.
Enterprise device support
Supported by almost every brand of router, firewall and business-grade modem. When a tunnel has to be built between two different vendors without replacing existing hardware, this is usually the common language. The trade-off is a longer, more error-prone parameter list.
When: Mixed-vendor networks, inherited infrastructure, tunnels to partner networks, and organisations required by audit to use a specific cipher suite.
Flexibility
It can run over the port used by ordinary web traffic, so it survives on restricted networks. Its certificate infrastructure and per-user rule handling are mature. The price is performance: on the same hardware it is not as fast as WireGuard.
When: Users connecting from restricted guest networks such as hotels and airports, and client deployments needing detailed per-user permissions.
Redundancy is measured not by the existence of a second link but by whether work continues during the outage.
Two subscriptions arriving at the same building along the same fibre route provide no redundancy; one digger cuts both. The backup link needs a different carrier or a different technology, such as mobile broadband. This is the first question we ask during design.
When a link drops, re-establishing the tunnel over the second one takes seconds, and open sessions are lost in that window. How long failover takes and which applications tolerate it is written down up front — a file copy and a point-of-sale session do not experience it the same way.
The most overlooked side of redundancy. A branch that cannot reach head office must still be able to sell and let staff log in. We decide before deployment which services keep running locally: a local authentication replica, a local DNS cache, point-of-sale software that works offline.
Making branches redundant does not help when the single tunnel terminator at head office fails. On critical deployments we install a second terminator with automatic takeover between the two, and branches are defined against both endpoints.
Tunnel traffic is encrypted, and a processor does that work. A small router can saturate at a few hundred Mbit of tunnel throughput on a 1 Gbit link. On devices with hardware acceleration that ceiling rises significantly. The deciding factor is not link speed but the device encryption capacity — it is the first figure we check when selecting hardware.
The classic problem and the hardest to diagnose. Tunnel headers enlarge the packet, so traffic exceeding the smallest packet size along the path is fragmented or dropped. The symptom is odd: ping works, small requests succeed, but some websites never load and file copies stall halfway. The fix is a correct MTU on the tunnel interface plus MSS clamping at session setup.
A link should not be chosen before measuring what the branch will send upstream. Camera streams, backup windows and remote desktop sessions are very different profiles. On asymmetric links where upload is slower than download, the bottleneck almost always appears in the upload direction.
Traffic can be prioritised inside the tunnel as well. Voice calls and point-of-sale transactions are latency sensitive; backups are not. Capping backup traffic or moving it into a night window ends day-to-day branch slowness with a single setting.
An unmonitored tunnel is one whose failure you learn about from a phone call. Every tunnel we build enters monitoring, and alert thresholds are set to fire ahead of the first complaint.
The address plan comes before deployment; an overlap missed at discovery costs time during the build.
Locations, existing devices, link types and the IP blocks in use are documented. Overlaps surface here. The output is a diagram and an address plan document.
Hub-and-spoke or mesh topology based on branch count, tunnel technology based on device compatibility, redundancy level and failover behaviour are all decided.
Tunnels are built, routing is written, access rules are applied, MTU and MSS are tuned. Configurations go into a version-controlled repository.
Reachability tests in every direction, a deliberate link cut, failover timing, DNS and MTU checks. Test records are delivered as a report.
Tunnel monitoring is activated, a certificate calendar is set up, monthly utilisation reports are produced. A new branch adds a block; the scheme stays the same.
Pricing a VPN as a one-off job is misleading. The tunnel works the day it is built; the real cost is renewing certificates, updating configuration when the link provider changes, testing the backup path periodically, and knowing who does what the moment something drops. So the proposal is written as two lines: a fixed-fee deployment and a monthly operation fee. If hardware is needed it appears as a separate third line. Response times and out-of-hours coverage are stated explicitly in the contract; negotiating that during an outage serves nobody.
The choice is largely determined by the hardware you already own. If both ends run modern devices and throughput matters, we prefer WireGuard: faster, shorter to configure, less room for error. Where different vendors sit side by side or the infrastructure is inherited, IPsec provides the common denominator because nearly every device supports it. If people will connect from restricted guest networks, OpenVPN survives because it can run over the standard web port. During discovery we list the devices and write down which option fits, with the reasoning.
Usually yes, but it should not be claimed without checking. Three things matter: which tunnel technologies the device supports, whether it has hardware acceleration for encryption, and whether the vendor still supports it. We do not recommend a device that has reached end of support, because even if it can build a tunnel it will no longer receive security patches. If there is an incompatibility, there are two paths: replace the device, or place a small terminator at the tunnel endpoint and leave the existing device untouched.
Branch count changes the topology. Up to roughly ten locations, a central hub-and-spoke layout keeps both management and cost simple, with all traffic passing through head office. If branches exchange heavy traffic directly, or routing through the centre makes latency unacceptable, we add direct tunnels between selected branches. Beyond twenty locations, writing every tunnel by hand stops being sustainable, so we move to a template-based configuration distributed from a central point.
This is the obstacle we meet most often, and it has a solution. The symptom is this: the tunnel comes up, both ends appear to see each other, but no traffic flows. The cause is that both locations use the same local address block — the device believes the remote address is on its own network and never hands the packet to the tunnel. The permanent fix is to redesign the address plan and give each location its own block. Where renumbering is impossible, we apply address translation over the tunnel so each location presents itself to the other with a different block. That works, but without documentation it becomes unmaintainable, so wherever possible we fix the address plan first.
On redundant deployments the tunnel is rebuilt over the second link within seconds; open sessions drop and applications reconnect. If there is no backup link, or it is down too, the real question is whether the branch can keep working through the outage. That is why we decide during design which services continue to run locally at the branch — point-of-sale software, local authentication, a local DNS cache. Removing dependence on head office entirely is not realistic, but between zero and a full stop there is a wide range, and design decides where you land in it.
Yes. All three technologies have mobile clients, and IPsec ships inside the operating system on most phones, so no extra app is needed. Two things get attention on mobile devices: narrowing the access scope when personal phones connect to company resources, and being able to revoke the key for a single lost device on its own. For the second we issue a separate key per device rather than distributing a shared profile.
Yes, and this is necessary for both operations and compliance. Who connected, when, from which device and how long the session lasted are recorded. Where the logs are stored, how long they are kept and who can access them is written as part of the deployment. We do not record traffic content; what should be retained is connection metadata, not the data passing through the tunnel.
We split the work into two lines. The first is deployment: discovery, address plan, design, tunnel build and verification testing. This is quoted as a fixed fee, and its scope is set by the number of locations and the state of the existing hardware. The second is continuity: tunnel monitoring, certificate renewal, configuration backup, incident response and monthly reporting. That is written as a recurring monthly fee. If hardware is required it appears as a separate third line; we do not hide equipment margin inside the deployment fee.
Related services
Network design, cabling, VLAN scheme, monitoring and ongoing management — the layer the VPN sits on.
The layer that writes the rule set at the tunnel endpoint: who reaches what, and which traffic is logged.
Configuration of the devices carrying the tunnel: routing, WAN failover, VLANs and version-controlled configs.
The servers at the other end of the tunnel: hosting, backup and access management together.
Ongoing support that owns tunnel monitoring, the certificate calendar and incident response.
Book a free 30-minute discovery call with our team.
Our network and cyber security work is carried out by a team holding internationally recognised Cisco certification.
Issued by Cisco · Holder: Devrim Tunçer
A certification covering security operations centre (SOC) competency: security monitoring, incident response and analysis of network attacks. It is the foundation we rely on for intrusion detection, log correlation and post-incident response work.
Cisco training certificate · completed January 2023
Covers networking fundamentals: routing, switching, IP addressing and network security. The knowledge base we draw on for enterprise network setup and segmentation.