Messages

[only if each CHILD_SA configuration is instantiated not more than once. The default uses dynamic reqids, allocated incrementally]

Hey cknight725, thanks for the detailed guide.
The docs about VTI IPSEC mention to explicitly associate the reqid of the VTI to the Phase 2 children[1][2], is it necessary in your experience?

Honestly this is part of the frustration with the old documentation -- its not up to date at all.    the tooltip for ReqID on the Child today says it pretty clearly "This might be helpful in some scenarios, like route based tunnels (VTI), but works only if each CHILD_SA configuration is instantiated not more than once. The default uses dynamic reqids, allocated incrementally". Basically -- not important.   In my case the reqIds are 1 and 2.

[AWS Site-to-Site VPN with an OPNsense 26+ Customer Gateway (BGP over FRR)]

AWS Site-to-Site VPN with an OPNsense 26+ Customer Gateway (BGP over FRR)
About this guide. I have found myself using AWS much more in my day to day. For a couple of years I struggled to find a good, working set of documents to get this running. Because I struggled, and because in the end it was all pretty simple once the pieces were in one place, I am putting this together to share with the OPNsense community in the hope it helps many. What follows is what worked for me. Treat it as a starting point and build on it.

What this covers. A working, end-to-end way to terminate an AWS Site-to-Site VPN on an OPNsense firewall running a 2026-series release (26.x), using route-based tunnels and dynamic routing with BGP through the FRR (os-frr) plugin.

How to read the flags in this document:
•  VERIFY means the exact UI path, field name, or value changed across OPNsense releases
and should be confirmed on your 26.x build before you trust it.
•  TODO means something to make a note of or keep track of as you go, such as a tested
value or a screenshot. Keep anything sensitive in your own private notes, never in a shared copy of this document.
•  GOTCHA marks a known failure mode that wastes hours if missed.

Why I wrote this. The good information was scattered across a hundred different sources, and a lot of it no longer matches current OPNsense. Many guides are written against the old IPsec screens (the legacy "Tunnel Settings" model) and rarely cover BGP through FRR. OPNsense moved IPsec to the improved swanctl based "Connections" UI in the console, so older click-by-click guides do not line up anymore. I've also tried to go deeper into firewall and routing than I've found in most other guides out there.  This guide targets the current model and flags the spots where you should confirm against your own build.

1. Scope and assumptions
In scope:
•  One AWS Site-to-Site VPN connection (two tunnels) terminating on a single OPNsense box.
•  Route-based tunnels using Virtual Tunnel Interfaces (VTI).
•  Dynamic routing with BGP, run by FRR via the os-frr plugin.

Out of scope:
•  Transit Gateway ECMP across multiple VPN connections.
•  Two OPNsense nodes with CARP for high availability.
•  Static-route (policy-based) VPN. This draft assumes BGP.

Assumptions:
•  OPNsense 26.x is installed, reachable, and has a routable public WAN address or a 1:1
NAT with the required UDP ports forwarded. See GOTCHA in Section 6 about NAT-T.
•  You can create AWS resources in the target account and Region.
•  You have chosen a customer-side BGP ASN. A private ASN in the 64512 to 65534 range is
Typical

TODO: make a note of the customer-side ASN you choose.

2. Architecture overview
AWS Site-to-Site VPN always provisions two tunnels for redundancy. Each tunnel has:
•  An AWS outside (public) endpoint IP.
•  A tunnel inside /30 from the 169.254.0.0/16 APIPA range. AWS assigns both inside addresses. One is the AWS BGP peer, the other is your OPNsense side.
•  A pre-shared key (or certificate, not covered here).
•  A BGP session that runs inside the tunnel over the inside /30. 

Design decisions for this build:
•  Route-based (VTI), not policy-based. BGP requires route-based tunnels. This is the single most common reason a BGP build fails. GOTCHA: if you configure a traffic selector of your LAN to remote LAN (policy-based), BGP will not come up.
•  Child SA traffic selectors for VTI are 0.0.0.0/0 to 0.0.0.0/0. Routing decides what enters the tunnel, not the IPsec policy.
•  Both tunnels stay up. BGP and route preference decide the active path. Expect asymmetric or single-tunnel-preferred behavior unless you tune it (Section 9).

Termination target on the AWS side is either:
•  A Virtual Private Gateway (VGW) attached to one VPC, or
•  A Transit Gateway (TGW) for multi-VPC or scaled designs.

TODO: keep track of which one you are using and its ID.

3. AWS-Side Configuration
3.1 Create the Customer Gateway (CGW)
•  Console path: VPC > Customer Gateways > Create customer gateway.
•  Routing: Dynamic.
•  BGP ASN: your customer-side ASN from Section 1.
•  IP address: your OPNsense public WAN IP. If OPNsense sits behind 1:1 NAT, use the public IP in front of it and see the NAT-T GOTCHA in Section 6.

3.2 Create or identify the AWS gateway
•  VGW: VPC > Virtual Private Gateways > create, then attach to the VPC. The Amazon side
BGP ASN default is 64512. It is set on the gateway, not the VPN connection.
•  TGW: VPC > Transit Gateways. The Amazon side ASN is a property of the TGW and is
configurable at creation. Default is 64512.

3.3 Create the Site-to-Site VPN connection
•  VPC > Site-to-Site VPN Connections > Create.
•  Target gateway type: VGW or TGW as chosen.
•  Customer Gateway: the one from 3.1.
•  Routing options: Dynamic (requires BGP).
•  Tunnel inside IP version: IPv4 for this draft.
•  Tunnel options.
Recommended: let AWS auto-generate the inside CIDRs and the pre-shared keys. Fewer moving parts, and it avoids picking a /30 that collides with something. The downloaded config (3.4) is then your source of truth for whatever AWS assigned. Set them by hand only if you must match an existing addressing plan.

A note on AWS naming. Each tunnel has two inside addresses, and AWS labels them from each side's point of view, which is where people get lost. The one labeled Customer Gateway inside address is yours: put it on the OPNsense VTI. The one labeled Virtual Private Gateway inside address (or Transit Gateway for a TGW) is the AWS side: that is the address you point FRR at as your BGP neighbor. Do not guess from the last octet, read the labels in the downloaded config.

TODO: keep track of the tunnel facts after creation, from the downloaded config (see 3.4).

3.4 Download the configuration
•  On the VPN connection, choose Download Configuration.
•  Vendor: Generic is the safest starting point. There is no OPNsense profile. Some people pick a strongSwan or a generic Linux FRR/Quagga profile for the BGP hints.

VERIFY: which genericprofile most closely matches, then translate values by hand.

•  Keep this file. It is the source of truth for outside IPs, inside /30s, PSKs, and the AWS BGP peer addresses.

3.5 Recommended tunnel IKE/IPsec parameters
Set these on each tunnel under Tunnel options (Edit) so both ends agree. Confirm the current allowed sets in the console because AWS updates them.
•  IKE version: IKEv2 only. Simpler and more stable than IKEv1 here.
•  Phase 1 (IKE SA): AES256, SHA256, DH group 14 or higher (19, 20, 21 for ECP).
•  Phase 2 (Child SA): AES256, SHA256, PFS DH group 14 or higher.
•  Rekey and lifetime: leave AWS defaults unless you have a reason.
•  DPD timeout action: restart.

GOTCHA: mismatchedlifetimes cause periodic renegotiation drops that look random.
TODO: make a note of the exact algorithm set you settle on so both ends stay in lockstep.

3.6 Route propagation
•  VGW: enable Route Propagation on the VPC route tables that should learn BGP routes
(Route Tables > Route propagation > enable the VGW).
•  TGW: routes appear in the TGW route table. Confirm the attachment association and
propagation, and add static or propagated routes toward the VPC attachments.

GOTCHA: tunnels UP and BGP established still moves no traffic if route propagation is off or the security groups and NACLs block it.

4. OPNsense prerequisites
•  Confirm the release: System > Firmware.

TODO: make a note of your exact release (for example 26.1).

•  Install the FRR plugin: System > Firmware > Plugins > install os-frr.
•  Confirm IPsec uses the Connections model: VPN > IPsec > Connections should exist.

VERIFY:the menu label on 26.x. Older builds showed VPN > IPsec > Tunnel Settings instead.

•  Choose your customer-side BGP ASN. This is your end of the session and is separate from the AWS side.
•  The AWS side defaults to ASN 64512. You can change it, but the default is fine to keep.
•  Pick a private ASN for your side. The 16-bit private range is 64512 to 65534. A 32-bit private range also exists, 4200000000 to 4294967294, if you prefer.

GOTCHA: your ASN must not equal the AWS side ASN. If the AWS side is 64512, do not also choose 64512.  Keep it unique across your environment. Do not reuse an ASN that another VPN connection, Direct Connect, or BGP partner already uses, or you invite AS-path loop rejection and confusing routing.

•  Also note the two OPNsense inside addresses from the AWS downloaded config (the Customer Gateway inside addresses), one per tunnel.

5. OPNsense IPsec configuration (route-based, new Connections model)
The goal is two route-based tunnels, one per AWS tunnel, each producing a VTI you can route over and run BGP across.
VERIFY: the entire click path in this section against your 26.x build. Field names below reflect the swanctl Connections model, but labels could shift between releases.
Screenshot 1

5.1 Create Connection for Tunnel 1
•  VPN > IPsec > Connections > add a Connection.
•  Local address: your WAN interface or its address.
•  Remote address: AWS Tunnel 1 outside IP.
•  IKE version: IKEv2.
•  Proposals (IKE SA): match Section 3.5 (for example aes256-sha256-modp2048 for DH14).
•  Pre-shared key: create a Local and Remote authentication entry using the Tunnel 1 PSK.

GOTCHA: local and remote IKE identifiers. When behind NAT, set the local identifier to the public IP AWS expects (the CGW IP), not the private WAN address, or IKE auth fails.

Screenshot 2

5.2 Child SA for Tunnel 1 (VTI mode)
•  Add a Child SA under the Connection.
•  Mode: route-based (VTI). VERIFY the exact control that selects route-based versus policy-based in the Connections model. This is the crux of the whole build.
•  Traffic selectors: local 0.0.0.0/0, remote 0.0.0.0/0.
•  ESP proposals: match Section 3.5, with PFS group set.
Screenshot 3

5.3 Create the VTI interface for Tunnel 1
•  Assign a VTI: In recent builds VTI can be created as part of the Connection or under Interfaces. The VTI carries the tunnel inside /30.
•  OPNsense inside address: the customer inside IP from the AWS config (for example 169.254.x.2/30).
•  Remote or gateway inside address: the AWS inside IP (for example 169.254.x.1). This is your BGP neighbor.
•  Interfaces > Assignments: assign the VTI as an interface, enable it, name it clearly (for example AWSVPN1). Do not set an upstream gateway that would create a default route.
Screenshot 4

5.4 Repeat for Tunnel 2
•  Duplicate 5.1 to 5.3 with Tunnel 2 outside IP, its inside /30, and its PSK. Name the VTI AWSVPN2.

GOTCHA: reusing the same PSK or the same inside /30 across both tunnels. They are distinct.

Screenshot 5
Child - Screenshot 6

6. Firewall rules
On WAN (to allow the tunnels to form):
•  Allow UDP 500 (IKE) from the two AWS outside IPs to your WAN address.
•  Allow UDP 4500 (NAT-T) from the two AWS outside IPs.
•  Allow ESP (IP protocol 50) from the two AWS outside IPs.

GOTCHA: many guides forget ESPand only open 500 and 4500, which works only while NAT-T encapsulates everything. If your path is not NATed, missing ESP breaks the tunnel.

Screenshot 7

On each VTI interface (AWSVPN1, AWSVPN2):
•  Allow BGP: TCP 179 to and from the AWS inside address. (Consider a single floating rule for BGP)
•  Allow the traffic you intend to route across the tunnels (for example your LAN subnets to the VPC CIDRs, and return).
•  Consider an MSS clamp.

GOTCHA: without MSS clamping on the tunnel interfaces, largepackets over the reduced tunnel MTU cause hangs that look like a routing problem. Set the interface MTU and MSS deliberately.
TODO: keep track of the MTU and MSS you land on.

WAN - Screenshot 8

Tunnel 1 - Screenshot 9

Tunnel 2 - Screenshot 10

NAT-T GOTCHA: if OPNsense sits behind another NAT device, forward UDP 500 and UDP 4500 and protocol ESP from that device to OPNSense (passthrough-mode), and set the IKE local identifier to the public CGW IP. Pure ESP does not survive NAT, so NAT-T on 4500 must be available end to end.

7. FRR and BGP configuration (os-frr)
7.1 Enable FRR and BGP
•  Routing > General (FRR): enable the plugin.
•  Routing > BGP > General: enable BGP. Set your customer BGP ASN. Set the Router ID to a stable local address, for example a loopback or a LAN IP.

TODO: make a note of the Router ID you use.

7.2 Prefix Lists
Prefix lists are the most flexible prefix-based match in FRR. Define them first, as named lists, because the peer group and the route maps you build next reference them.
•  Navigate to Routing > BGP > Prefix Lists.
•  Create one list for the prefixes you advertise to AWS, and one for the prefixes you accept back.
•  Add each entry as a name, a sequence number, an action (permit or deny), and a network, with an optional le or ge length range.
Screenshot 11

GOTCHA: keep the advertised list specific. A permit-any or an overly broad prefix can blackhole traffic or be rejected by AWS.

7.3 Peer Group
Peer groups define the configuration for the neighbors in a modular way. FRR applies one shared set of settings to every member and generates the same updates for all of them, which improves scaling. Define the group once, then both tunnel neighbors join it and stay identical.
•  Navigate to Routing > BGP > Peer Groups.
•  Create one peer group for the two AWS tunnel sessions.
•  Set the shared settings on the group: remote AS (the AWS side ASN, default 64512) and timers.
•  Bind the inbound and outbound prefix lists and route maps here, so the policy lives in one place rather than on each neighbor.
Screenshot 12

7.4 Route Maps
Route maps are the policy tool the neighbors use. They filter routes and set attributes such as local-preference, AS-path prepend, and MED, per direction. Build them here as named policies, then apply them through the peer group.
•  Navigate to Routing > BGP > Route Maps.
•  Create one inbound map and one outbound map so the intent is clear.
•  In each map, match on the prefix lists from 7.2, then permit or deny and set attributes as needed.
•  Apply the maps through the peer group (or directly on the neighbors) so both tunnels share the same policy.
Screenshot 13

7.5 Neighbors (one per tunnel)
Create two BGP neighbors, one per AWS inside address.
•  Neighbor 1: peer IP = AWS Tunnel 1 inside address (for example 169.254.x.1), remote AS =
AWS side ASN (default 64512).
•  Neighbor 2: peer IP = AWS Tunnel 2 inside address, remote AS = same AWS ASN.
•  Update source: bind each neighbor to the matching VTI or its inside address, so the BGP session sources from the correct tunnel. VERIFY the field name for update-source or interface binding in the os-frr UI.
•  Timers: AWS uses common defaults (hold 30, keepalive 10). Match to avoid flaps.
•  eBGP multihop: normally not needed because the peer is directly connected across the /30.  If sessions will not establish, verify whether your VTI setup needs multihop of 2.
Neighbors - Screenshot 14

AWS Neighbor 1 - Screenshot 15

AWS Neighbor 2 - Screenshot 16

8. Bring-up order
1.  Confirm AWS VPN connection exists and both tunnels show DOWN (expected before OPNsense
is configured).
2.  Bring up IPsec on OPNsense. Watch VPN > IPsec > status.
3.  Confirm both Child SAs (VTI) install and the VTI interfaces show the inside /30.
4.  Confirm you can ping the AWS inside address from OPNsense across each VTI.

GOTCHA: ifping to 169.254.x.1 fails, BGP will never come up. Fix IPsec and routing first.

5.  Bring up BGP. Confirm sessions reach Established.
6.  Confirm routes are learned and propagated on both sides.

9. Verification
AWS side:
•  VPN connection > Tunnel details: both tunnels should show UP and BGP routes as the number learned from you.
•  Route table (VGW) or TGW route table: your advertised prefixes appear.

OPNsense side:
•  IPsec status: two connections, Child SAs installed.
•  Ping each AWS inside address across each VTI.
•  SSH to the OPNsense command line and use vtysh commands:
    show ip bgp summary both neighbors should be Established with a nonzero prefix count.
    show ip route bgp should list the VPC prefixes with the tunnel next hops.

End to end:
•  From a host behind OPNsense, reach an instance in the VPC and back. Check both security
groups and NACLs if it fails after routing looks correct.

Getting console access over SSH:
•  Enable SSH first. VERIFY the path on 26.x: System > Settings > Administration, turn on Secure Shell, and permit an admin user (with a key or password) to log in.
•  Connect with ssh <user>@<opnsense-LAN-IP>, using an account that has shell access.

GOTCHA: keep SSH on the LAN or a management network. Do not expose it on the WAN.

Where FRR keeps its config, and how to treat it:
•  The os-frr plugin runs FRR as its own daemons, and their configuration lives in the FRR config directory on disk.
VERIFY: the exact path on 26.x, commonly /usr/local/etc/frr/ on the FreeBSD base, as an integrated frr.conf or per-daemon files such as bgpd.conf.

GOTCHA: do not edit these files by hand. OPNsense generates them from your GUI settings and overwrites manual edits on the next apply or reboot. Treat the files as a read-only reflection of what the GUI built, useful for reading and confirming, not for changing.

•  Make every change in Routing > BGP and let OPNsense regenerate the config. To see what FRR is actually running rather than what is on disk, use vtysh below.

Useful vtysh Commands (read-only, run these to verify):

show ip bgp summary	both AWS neighbors should reach Established with a nonzero prefix count. A state of Active or Connect means the session is not up yet.
show bgp neighbor <AWS-inside-ip>	full detail for one session, including timers, negotiated capabilities, and the last reset reason
show ip route bgp	the BGP routes actually installed, with the tunnel next hops. show ip bgp shows the full table, and show ip bgp <prefix> shows one prefix.
show bgp neighbor <ip> advertised-routes and show bgp neighbor <ip> received-routes	confirm exactly what you send to AWS and what AWS sends you.
show ip prefix-list and show route-map	confirm the prefix lists and route maps from 7.2 and 7.4 exist and match what you built.
show bgp peer-group	confirm both tunnels are members of the peer group from 7.3.
show running-config	the running FRR configuration in one view, the read-only reflection mentioned above.
clear bgp <ip> soft in and clear bgp <ip> soft out	reapply inbound or outbound policy without tearing down the session, after a prefix-list or route-map change.

10. Troubleshooting
•  Wrong VPN mode. BGP requires route-based VTI. Policy-based traffic selectors kill BGP.
•  Missing ESP rule on WAN when the path is not NATed.
•  NAT in front of OPNsense without NAT-T on UDP 4500 and without the correct IKE identifier.
•  Inside address ping fails, so BGP never starts. Prove the /30 reachability first.
•  MTU and MSS not clamped, causing large-flow hangs that masquerade as routing faults.
•  Route propagation disabled on the AWS route table, so tunnels are UP but nothing routes.
•  Mismatched Phase 1 or Phase 2 proposals or lifetimes, causing renegotiation drops.
•  Advertising too broad a prefix to AWS.
•  OPNsense version drift. UI paths in older guides do not match the Connections model.

GOTCHA: Confirm every path on your build.

11. References to Validate (Do not trust me blindly!)
•  AWS Site-to-Site VPN user guide, especially tunnel options and BGP requirements.
•  AWS downloadable configuration for your VPN connection (the authoritative source for outside IPs, inside /30s, PSKs, and AWS BGP peer addresses).
•  OPNsense IPsec Connections documentation for your exact release.
•  OPNsense os-frr and BGP plugin documentation.
•  FRR BGP documentation for vtysh verification commands.

Any Update on this -- annoucement was made about Route53 protocol support added to ddclient, but I can't see AWS or Route53 in the services ....

I'm a little lost with the new OPNSense IPSEC UI --- Specfically Mutual Pre-Shared Keys -- how do I associate the preshared key to be used with a connection?    Is there an IPSEC to AWS write-up that someone has completed with the new UI?