When setting up an IPsec VPN between peers that aren’t both directly reachable by static public IPs, for example, when one side sits behind NAT and uses a dynamic DNS hostname like shown in my post here, pfSense’s “My Identifier” and “Peer Identifier” settings become critical.

These fields determine how each peer identifies itself during IKE authentication, and mismatched identifiers are one of the most common causes of AUTH_FAILED errors.

In this post, we’ll break down what these identifiers mean, how pfSense uses them internally, and how to configure them correctly for scenarios involving DynDNS, NAT, or cloud-based peers like Azure.


The following scenario, the on-prem pfSense appliance sits behind NAT and using a dynamic DNS hostname like shown here, and the other pfSense appliance in Azure like shown here, is using a public IP on its WAN NIC.

In this case there are a few key details that make or break the connection:

  • Ports and NSGs: On Azure, make sure the Network Security Group (NSG) attached to the WAN subnet or NIC allows inbound and outbound UDP 500 (IKE) and UDP 4500 (NAT-T). These are essential for IKEv2 negotiation through NAT.
  • Public IP and IP Forwarding: The Azure pfSense WAN NIC must have a direct public IP and IP forwarding enabled, otherwise Azure will drop VPN traffic.
  • Identifiers: When one side uses a DynDNS hostname, matching identifiers are critical. Set the My Identifier on each pfSense to reflect its actual public identity (for example, the on-prem side uses its DynDNS hostname, and the Azure side uses its public IPv4). If identifiers don’t align, you’ll see an AUTH_FAILED error during IKE_AUTH.


Once these points are aligned, the tunnel will establish immediately, even when one or both peer is dynamic and behind NAT.


On the on-prem pfSense appliance for the Phase 1 tunnel under Proposal (Authentication) set the My identifier and Peer identifier as mentioned and shown below.


The same settings on the Azure pfSense appliance for the Phase 1 tunnel under Proposal (Authentication).


If the IPsec tunnel fails during Phase 1 because of this mismatch in authentication parameters, we can easily spot this in the pfSense (strongSwan) logs.

e.g. the logs on the on-prem pfSense appliance under Status → System Logs → IPSec

<IKE> authentication of '<hostname>.ddns.net' (myself) with pre-shared key
<IKE> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
<IKE> received AUTHENTICATION_FAILED notify error


These entries show that:

  • The local device successfully starts authentication using the ID <hostname>.ddns.net.
  • The peer responds with AUTH_FAILED, meaning the credentials or identifiers didn’t match what it expected.


Also keep in mind, that when using APIPA (169.254.x.x) addresses for the transit network in pfSense, we must first enable APIPA traffic in the advanced system settings to allow traffic between both sites as shown in my following post.

pfSense and APIPA (169.254/16): Enabling Link-Local Transit Networks for IPsec VTI and BGP

Links

Phase 1 Settings
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p1.html

strongSwan
https://strongswan.org/

Identity Parsing
https://docs.strongswan.org/docs/latest/config/identityParsing.html

Configuration Quickstart
https://docs.strongswan.org/docs/latest/config/quickstart.html