Building a hybrid AWS VPN with BGP over IPsec on Palo Alto firewalls

Many Australian businesses still run workloads in on-premises data centres while pushing new services into AWS. Linking those environments securely remains a recurring task for network engineers in Sydney and Melbourne, especially when AWS Local Zones or Outposts aren't an option. A site-to-site IPsec tunnel with BGP routing is often the simplest path that satisfies both security teams and auditors.

Palo Alto Networks firewalls are common across larger Australian enterprises, partly because the ACSC's Essential Eight maturity controls push for next-gen capabilities. Pairing a PAN running PAN-OS with an AWS Virtual Private Gateway creates a resilient hybrid fabric without the recurring cost of Direct Connect. BGP brings dynamic failover, which matters when you're balancing an NBN business-grade circuit against an enterprise Ethernet link.

This walkthrough focuses on configuration steps rather than marketing slides. The aim is a working BGP-over-IPsec tunnel engineers can replicate in a home lab, then promote to production. If you're still assembling lab gear, the home lab with Proxmox VE guide is a useful starting point for hosting a virtual PAN and a mock on-prem router.

Laying out the topology and AWS side

Before touching the firewall, sketch the addressing plan on paper. In the AWS Sydney region (ap-southeast-2), create a dedicated VPC for the hybrid transit, with a /16 CIDR that doesn't overlap your corporate ranges. Deploy a Virtual Private Gateway, attach it to the VPC, and propagate its routes into the relevant route tables. Stand up an EC2 instance you can ping and trace from later; it saves hours when troubleshooting.

On the on-premises side, decide which physical interface on the Palo Alto will terminate the tunnel. Most teams in Brisbane and Perth offices dedicate a copper or fibre handoff from the ISP router, then create a dedicated Layer 3 interface and Zone for VPN peers. Naming things clearly — for example Trust-VPN-AWS-Sydney — makes life easier when staring at a commit window at 5pm AEST.

Reserve two ASN values: one for AWS (typically 64512 for the VGW) and one for your firewall. Private ASN space in the 64512–65534 range is fine and avoids the paperwork of requesting public ASNs from APNIC. Keep a record of the customer gateway IP, which is the public address of the firewall's egress interface.

Building the IPsec tunnel on PAN-OS

Palo Alto's IKE Gateway configuration is where most engineers trip up. Use IKEv2 with AES-256-GCM and SHA-256 for the phase one proposal, which lines up with the defaults AWS advertises. Dead Peer Detection should be enabled with short intervals — 10 seconds and three retries is a reasonable starting point for a noisy consumer-grade link, though enterprise fibre tolerates longer values.

Under Network > IPSec Tunnels, create a new tunnel and bind it to the IKE Gateway. The tunnel interface gets its own logical interface, a /30 from the family reserved earlier, and a virtual router assignment. Many engineers skip the Proxy ID configuration entirely when using route-based tunnels; AWS accepts traffic based on the encrypted routing rather than a strict policy. Add the tunnel to the appropriate Zone and enable IPv4 forwarding.

The pre-shared key is generated on the AWS side and copied into the PAN. Treat it like a password — store it in your secrets vault, rotate it on a schedule, and never paste it into a Confluence page. Commit the candidate config and watch system logs for IKE negotiation messages. A successful phase one and phase two will show as IKEv2 SA established followed by IPSec SA established.

Bringing up BGP between PAN and AWS

BGP gives automatic failover and removes the need to maintain static routes every time someone adds a subnet on either side. On the Palo Alto, create a BGP peer group under the logical router that owns the tunnel interface. Set the local AS to your assigned number, configure the peer IP as the AWS side of the /30, and enter 64512 as the remote AS.

Authentication is optional but recommended for defence-in-depth. A simple MD5 key is enough; AWS accepts it without complaint. Set the hold timer to 90 seconds and keepalive to 30 seconds, which gives BGP enough time to detect a black-holed tunnel during a Telstra outage without flapping on transient packet loss. Import the default route from AWS and advertise internal corporate prefixes — but filter them carefully to avoid leaking private RFC1918 space back into the cloud.

After committing, verify the session with show routing protocol bgp peer on the firewall and aws ec2 describe-vpn-connections from a workstation. Both routes from the on-prem side should appear in the VPC route table once propagation is enabled. If prefixes stay stuck in idle, check that the firewall's source interface for BGP matches the tunnel interface IP — a classic mistake.

Failover, health checks and ongoing operations

A hybrid tunnel is only useful if it recovers from failure. Enable Bidirectional Forwarding Detection on the tunnel interface so the firewall can detect a one-way black hole, which is common when an upstream provider filters traffic silently. Pair this with AWS's published CloudWatch metrics for tunnel state — alarm on TunnelState changes and route them to your PagerDuty or Opsgenie rotation.

For Australian environments, consider running two tunnels to different AWS endpoints across separate ISPs. The cost of a second IPsec session is negligible compared to the productivity loss when an NBN fibre cut isolates a remote office from its Sydney-hosted control plane. Some teams also terminate a second tunnel on a different Palo Alto in HA active/passive mode, which protects against the appliance itself.

Document the BGP communities used so the network team can identify cloud-learned routes quickly. A simple scheme — 64512:100 for AWS-default, 64512:200 for AWS-region-specific — is enough to start. Review the routing table monthly and prune prefixes that no longer exist on-prem; BGP will happily advertise dead networks forever otherwise.

Comparing the common hybrid connectivity options

The breakdown below maps the usual connectivity choices against criteria that matter to Australian infrastructure teams. Your mileage will vary depending on bandwidth needs, existing carrier relationships, and appetite for managed services.

Option	Typical bandwidth	Lead time	Cost profile	Best fit
IPsec VPN over internet	Up to ~1.25 Gbps per tunnel	Hours	Lowest, data egress only	Branch offices, DR, small workloads
AWS Direct Connect	1–100 Gbps	Weeks to months	Higher, port + data	Steady-state east-west traffic
AWS Site-to-Site VPN with acceleration	Higher throughput per tunnel	Hours	Low to medium	Latency-sensitive apps without DX
AWS Transit Gateway + VPN	Aggregated routing	Hours	Medium	Multi-VPC estates

Most mid-sized Australian organisations start with IPsec and graduate to Direct Connect once monthly data transfer justifies the cross-connect fee. Until then, a well-tuned BGP-over-IPsec configuration on the Palo Alto delivers the resilience and observability teams need without the lead time of a fibre install.