Site-to-Site VPN Setup: Office-Cloud Integration Guide

Expert Guide to Connecting Office Networks with Cloud VPCs via VPN

We regularly face the challenge of establishing Site-to-Site VPN tunnels between an office and cloud VPCs (AWS, GCP, Azure). The requirement is that cloud services see internal hosts via private addresses—without NAT hairpinning or extra hops. In practice, many nuances accumulate: MTU mismatch on the tunnel, drifting Phase 2 SAs on IKEv1, subnet conflicts between the office and the default VPC CIDR, or the scenario where a BGP session is up, routes are advertised, but traffic only flows one way due to an asymmetric stateful firewall on the corporate edge. With over 50 projects integrating offices with cloud environments under our belt, we know the typical pitfalls and how to avoid them. Our certified engineers guarantee stability and security for every tunnel. Typical service cost ranges from $1,500 to $5,000, potentially saving you up to 40% on cloud data transfer costs. Get an engineer consultation for your project.

Which Topology and Protocol to Choose?

For office-cloud connectivity, we employ IPsec IKEv2 as the base transport. IKEv2 establishes connections 30% faster than IKEv1 and recovers more reliably after a disconnection. We use GRE over IPsec when we need to carry multicast or OSPF/BGP inside the tunnel; otherwise, the overhead isn't justified.

A standard AWS VPN setup with BGP looks like this:

Customer Gateway (CGW): office router's external IP
Virtual Private Gateway (VGW) or Transit Gateway (TGW): on AWS side
Client BGP ASN: 65001 (private range)
AWS BGP ASN: 64512 (default) or custom
Two tunnels: mandatory for HA, each with a separate pre-shared key

AWS automatically creates two tunnels with different endpoint IPs—this isn't redundancy for show, but real failover. The first tunnel drops during AWS endpoint maintenance; without the second, you'll have an outage window from 30 seconds to several minutes.

On the office side, a typical configuration for MikroTik (RouterOS 7.x):

/ip ipsec profile add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=aws-profile
/ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1h name=aws-proposal pfs-group=modp2048
/ip ipsec peer add address=<AWS_TUNNEL1_IP>/32 exchange-mode=ike2 name=aws-tunnel1 profile=aws-profile
/ip ipsec identity add peer=aws-tunnel1 secret=<PSK_TUNNEL1>
/ip ipsec policy add dst-address=10.0.0.0/16 peer=aws-tunnel1 sa-dst-address=<AWS_TUNNEL1_IP> \
    sa-src-address=<OFFICE_PUBLIC_IP> src-address=192.168.1.0/24 tunnel=yes

/ip firewall mangle add action=change-mss chain=forward new-mss=1387 out-interface=<ipsec-tunnel> \
    passthrough=yes protocol=tcp tcp-flags=syn

BGP over the Tunnel

Note: when you need to advertise multiple subnets or set up failover between two tunnels, we run BGP over IPsec. AWS Transit Gateway is especially useful for hub-and-spoke topologies—multiple offices connect to a single TGW, which then routes traffic between them and the VPC.

Example BGP configuration on Cisco IOS for a tunnel to AWS:

crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 28800
crypto ipsec transform-set AWS-TS esp-aes 256 esp-sha256-hmac
 mode tunnel
interface Tunnel1
 ip address 169.254.10.2 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination <AWS_TUNNEL1_OUTSIDE_IP>
 ip tcp adjust-mss 1387
router bgp 65001
 neighbor 169.254.10.1 remote-as 64512
 neighbor 169.254.10.1 timers 10 30
 network 192.168.0.0 mask 255.255.0.0

Link-local addresses 169.254.x.x/30 are standard for BGP peer addresses on AWS tunnels. Don't try to use your own addresses—the VGW won't accept them.

What Problems Arise with Site-to-Site VPN?

CIDR Conflict. Scenario: office on 10.0.0.0/8, VPC created with default 10.0.0.0/16. Tunnel is up, BGP established, but traffic to EC2 instances doesn't flow—local route overrides tunnel. Solution: when creating VPC, use 172.16.0.0/12 or 192.168.0.0/16 for cloud networks, leaving 10.x.x.x for offices.

Dead Peer Detection. By default, DPD on AWS tunnels has a 10-second interval and 3 retries. With an unstable ISP on the office side, the tunnel reinitializes every 30 seconds. If Phase 1 and Phase 2 don't come up quickly (Cisco IOS with crypto isakmp keepalive 10 periodic), you get packet loss on every reconnect.

Asymmetric Routing. Office has two ISPs—failover via the second link. Return traffic comes back through the primary. A stateful firewall on the office edge drops packets from the “unexpected” interface. This is fixed either with policy-based routing or by moving tunnel traffic into a separate firewall zone without stateful inspection.

How We Set Up Site-to-Site VPN: Step-by-Step Process

1. Network Audit—analyze existing topology, subnets, equipment, and software versions.
2. Design—choose topology, protocol, addressing scheme, and high availability.
3. Configuration—set up IPsec and BGP on both sides, apply MSS clamping.
4. Testing—verify failover, measure recovery time, load test MTU.
5. Documentation—network diagram, annotated configs, runbook for disaster recovery.

Comparison: IKEv1 vs IKEv2

What's Included in the Result

After completing the work, you receive:

• Documented network diagram (draw.io or Mermaid)
• Configuration files with comments
• Runbook for tunnel restoration after ISP failure
• Stability guarantee (contractually agreed)

Timelines depend on complexity: from 1 day for a simple tunnel to 2 weeks for a hybrid network with AD, DNS, and NTP. Cost is determined after analysis—contact us to discuss your project.

Optimizing routing can save up to 40% on cloud traffic, and operational costs drop by 20% thanks to automated failover. Get an engineer consultation to evaluate your project. Contact us to order the service. For more on secure connection design, refer to RFC 4301 and vendor documentation: AWS VPN, GCP VPN, Azure VPN Gateway, and official MikroTik guide.