AWS to pfSense: Lessons from an Early Site-to-Site VPN
A 2015 field note on connecting an AWS VPC to an old pfSense firewall—and the troubleshooting lessons that still apply.
Archive note: Originally published on Mullener in 2015. This version has been edited for clarity and historical context. The product screens and supported cryptography have changed considerably, so treat this as a troubleshooting retrospective—not a current build guide.
In 2015 I needed to connect an Amazon VPC to a company pfSense firewall using an IPsec site-to-site VPN. The firewall was already old: pfSense 1.2.3, built in December 2009, running as part of a redundant embedded pair.
The interesting question was not simply whether AWS supported IPsec. It was whether a managed cloud endpoint and a much older on-premises implementation could agree on every detail needed to bring a tunnel up.
The AWS-side model
Three AWS objects formed the connection:
- A Customer Gateway represented the public IP address of the pfSense endpoint.
- A Virtual Private Gateway terminated the AWS side of the VPN and attached to the VPC.
- A VPN Connection joined the two gateways and supplied the tunnel configuration.
The remote network also needed to appear in the VPN connection’s static routes. Creating the tunnel objects without completing the routing was not enough: negotiation could succeed while useful traffic still had nowhere to go.
AWS terminology was the first source of friction. Mapping the managed-service names back to familiar IPsec concepts made the setup much easier to reason about.
The pfSense side
The downloaded AWS configuration provided the peers, pre-shared keys, encryption settings and Phase 1/Phase 2 parameters. The old pfSense interface presented some of those options differently from newer documentation—particularly Dead Peer Detection.
One memorable detail was the cipher name. AWS documented AES-128, while the pfSense interface used Rijndael, the name of the wider cipher family from which AES was standardised. They referred to the compatible choice in this context, but the naming difference was enough to make the setting look suspicious.
The practical process was:
- verify both peers used matching Phase 1 proposals;
- verify the Phase 2 networks and proposals;
- check that the on-premises and AWS route tables described the same networks;
- allow time for both ends to negotiate;
- read the logs on the endpoint that exposed the most detail.
Where the useful evidence lived
The AWS console could report that the tunnel was up, but at the time it exposed little diagnostic detail. pfSense’s logs showed racoon, its IPsec daemon, negotiating and bringing the tunnel up when traffic required it.
That asymmetry is common with managed services: one side gives you a health indicator, while the other gives you protocol events. Successful troubleshooting means correlating both rather than expecting either view to tell the entire story.
What still holds up
Do not copy decade-old algorithms or interface instructions into a modern deployment. Current pfSense and AWS documentation should be the authority for supported ciphers, integrity algorithms, lifetimes and routing options.
The durable lesson is the method: translate provider terminology into protocol components, make routes explicit, compare proposals at both ends, and use the most detailed logs available. The consoles change; the need for both sides to agree does not.