Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    WireGuard client NAT with alias IP breaks handshake on pfSense 2.8.1

    Scheduled Pinned Locked Moved WireGuard
    2 Posts 1 Posters 45 Views 1 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N Offline
      nobanzai
      last edited by nobanzai

      Hi all,

      I’m running pfSense 2.8.1-RELEASE in an HA setup, and I’m running WireGuard as a client. I need all LAN traffic for certain subnets to be NATed through the WireGuard interface so that the server sees a specific public IP.

      Here’s my configuration:

      WireGuard Client IP (Tunnel-IP): 10.19.57.2
      WireGuard Server IP: 10.19.57.1
      Public Alias IP for NAT: 192.168.10.10 (configured as a Virtual IP / IP Alias on the WIREGUARD interface)
      LAN Subnets: 192.168.1.0/24, 192.168.129.0/24
      Destination Subnets behind server: 192.168.10.0
      Outbound NAT: Source = LAN subnets, Translation = Alias-IP 192.168.10.10
      LAN Firewall rule: Gateway = WIREGUARD_GW
      

      Problem:

      When the Alias-IP is configured for NAT, WireGuard handshakes stop and no traffic flows.
      Tunnel-IP alone works fine → handshakes are stable.
      NAT on the Tunnel-IP alone works for traffic, but then the server sees the wrong source IP.
      I’ve verified AllowedIPs on the server, MTU, firewall rules, and HA failover – everything else is correct.

      It seems that pfSense cannot reliably NAT LAN traffic through a WireGuard client interface while keeping the handshake stable if the NAT IP is an alias on the same interface.

      Has anyone found a working solution for NATing LAN traffic through WireGuard with a separate “known” public IP while keeping the handshake stable?

      TIA.

      Bye.
      Michael.

      N 1 Reply Last reply Reply Quote 0
      • N Offline
        nobanzai @nobanzai
        last edited by

        Found a solution:
        When using the desired outbound address in the outbound nat rule for translation directly, instead of using an alias ip, it seems to work as desired.

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.