[Bug 252990] net/wireguard: WG don't use CARP IP as source

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252990

            Bug ID: 252990
           Summary: net/wireguard: WG don't use CARP IP as source
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: decke at FreeBSD.org
          Reporter: m.muenz at gmail.com
          Assignee: decke at FreeBSD.org
             Flags: maintainer-feedback?(decke at FreeBSD.org)

Hi,

I asked Jason regarding CARP HA with FreeBSD twice since when using CARP IP as
the destination, the reply packet will be sent as the system IP and therefore
doesn't match.

https://lists.zx2c4.com/pipermail/wireguard/2020-September/005840.html

Now I thought I can maybe do some tricks via pf and NAT.

My first test was outbound NAT with source as CARP and source port wireguard:

nat on igb0 inet proto udp from (self) port 51820 to any -> 82.34.74.60
static-port # Outbound NAT fuer WireGuard HA

But for reply packets, so when other side connects first, this doesn't match:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:24:19.887082 IP 80.151.56.127.19335 > 82.34.74.60.51820: UDP, length 148
11:24:19.887422 IP 82.34.74.61.51820 > 80.151.56.127.19335: UDP, length 92
11:24:25.037698 IP 80.151.56.127.19335 > 82.34.74.60.51820: UDP, length 148
11:24:25.038026 IP 82.34.74.61.51820 > 80.151.56.127.19335: UDP, length 92

82.34.74.60 = CARP IP
82.34.74.61 = IP of Firewall1

Then I tried a portforward when connecting to CARP IP redirecting to localhost,
but it has the same result and I don't see the packets on interface lo0:

rdr log on igb0 inet proto udp from {any} to {82.34.74.60} port {51820} ->
127.0.0.1 port 51820 # Portforward auf localhost fuer WireGuard HA

I would guess it's blocked when I don't see the packet on lo0, but I still see
the reply in the tcpdump going out.

Also, I flip between LTE and Wifi so it's nothing like pf state.

Any idea how to dig deeper into it? Maybe is there an option for outgoing NAT
to be state-less like with usual pf rules?

I add kprovost@ like discussed via Twitter.

-- 
You are receiving this mail because:
You are the assignee for the bug.