npf map works for http traffic but not https... on same port

[David Brownlee <abs%absd.org@localhost>]

... but only when the original traffic is over wireguard... not openvpn

So this is an "interesting" one.

I have a case where remote access was provided via openvpn to a NetBSD
box running npf, using map to allow access to some devices which are
not directly routed over the vpn. All was fine. Now we're converting
to wireguard (using wireguard-go initially), and the rules are failing
for https traffic... but an http request *on the same port* works (at
least enough for the remote device to return a redirect to https).

The remote end seems to send a packet of the form
IP 192.168.203.11.8006 > 10.52.98.14.16827: Flags [.], seq 1:1449, ack
315, win 507, options [nop,nop,TS val 3775379581 ecr 2], length 1448
which is never sent on via npf

There is a set of small NetBSD boxes that provide a selection of
services, including remote vpn access. One feature is to allow certain
remote connections to access certain non VPN-routed IPs, using npf
map.

The base layout layout is a typical VPN "star", with a fixed centre,
and multiple clients, (some servers, some workstations), and some
remote proxy boxes

[client] - on random IP, typically no external visible IP
    ^
    | VPN
    v
[vpn-server] - on fixed Internet visible IP
    ^
    | VPN
    v
[remote] - on random IP, typically no external visible IP

Things on the [remote] end have a little further complexity as the
remote NetBSD system provides access to a /24 of other devices, and
may be running as a VM in a proxmox box which sits *upstream* to it,
and needs to provide client access to both

So, when the VPN above is OpenVPN, all seems fine, but when switched
to wireguard we see the "https fails, http on same port works" symptom



npf.conf is simple enough:

$internal_nets_to_nat = { 10.222.0.0/16, 172.16.1.0/24 }
$remote_admin = { 172.16.1.229 }
$ext_if = vioif0
$wg_if = tun1
$proxmox = 192.168.203.11

alg "icmp"

# Nat on external interface
map $ext_if dynamic $internal_nets_to_nat -> inet4($ext_if)

# proxmox
map $wg_if dynamic $proxmox port 8006 <-> 0.0.0.0 \
  pass from $remote_admin to inet4($wg_if) port 8006

group default {
  pass stateful out final all
  pass final all
}


interface config, again simple enough (tun0 is the old OpenVPN link to
allow continued access when messing with wireguard)

vioif0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ec_capabilities=0x1<VLAN_MTU>
        ec_enabled=0
        address: xx:xx:xx:xx:xx:xx
        status: active
        inet6 fe80::a1be:11a4:43d0:5e17%vioif0/64 flags 0 scopeid 0x1
        inet 10.52.98.14/16 broadcast 10.52.255.255 flags 0
vioif1: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ec_capabilities=0x1<VLAN_MTU>
        ec_enabled=0
        address: xx:xx:xx:xx:xx:xx
        status: active
        inet6 fe80::be24:11ff:fe09:e17f%vioif1/64 flags 0 scopeid 0x2
        inet 10.222.3.254/24 broadcast 10.222.3.255 flags 0
lo0: flags=0x8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33624
        status: active
        inet6 ::1/128 flags 0x20<NODAD>
        inet6 fe80::1%lo0/64 flags 0 scopeid 0x3
        inet 127.0.0.1/8 flags 0
tun0: flags=0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        status: active
        inet6 fe80::be24:11ff:fed0:4029%tun0/64 ->  flags 0 scopeid 0x4
        inet 10.222.222.97/32 -> 10.222.222.98 flags 0
tun1: flags=0x151<UP,POINTOPOINT,RUNNING,PROMISC> mtu 1420
        status: active
        inet 172.16.1.3/32 ->  flags 0



Packet traces from client sending, remote receiving, and remote
sending onto proxmox for both http and https at:

https://sync.absd.org/nvpn/http-but-not-https/