Premise: I haven't done NAT on NPF since like NetBSD 7.x and unfortunately I no longer run a NPF-based home router (switched to ISP's as I moved over a optical fiber connection).
Nevertheless, I decided to perform some tests on one of my machines and check whether what used to apply back then still does (NPF changes fast).
My legacy IBM thinkpad has a statically assigned internal address, which is 192.168.1.3. I decided to make sshd listen on 2200, which results in being cut out when trying to get a remote shell on it through the standard 22 TCP port.
$ ssh 192.168.1.3
ssh: connect to host 192.168.1.3 port 22: Connection refused
Now, I'll edit my /etc/npf.conf to do inbound IP forwarding from port 22 to 2200 (without explicitely allowing requests on 2200)
$int_if = inet4(fxp0)
$int_IP = { 192.168.1.3 }
# translate inbound requests from port 22 to 2200
map fxp0 dynamic $int_IP port 2200 <- $int_IP port 22
Which once loaded generates:
$ npfctl show
[...]
map fxp0 dynamic 192.168.1.3 port 2200 <- any pass family inet4 proto { tcp, udp } to 192.168.1.3 port 22 # id="2"
[...]
Looks like it will let me in now:
$ ssh 192.168.1.3
Password for vincent@thinkpad_R51.sdf.org:
Last login: Sat Mar 27 09:24:26 2021 from 192.168.1.35
NetBSD 9.1 (GENERIC) #0: Sun Oct 18 19:24:30 UTC 2020
Looking ath the npfd log, I see:
$ tcpdump -enr /var/log/npflog0.pcap
[...]
09:25:01.482352 rule 15.rules.0/0(match): pass in on fxp0: 192.168.1.35.41366 > 192.168.1.3.2200: Flags [.], ack 7108, win 1815, options [nop,nop,TS val 7572469 ecr 24], length 0
09:25:02.470493 rule 15.rules.0/0(match): pass out on fxp0: 192.168.1.3.22 > 192.168.1.35.41366: Flags [P.], seq 7108:7240, ack 1566, win 4197, options [nop,nop,TS val 26 ecr 7572469], length 132
Which accounts for the fact the NAT is properly set up.
As a counter-proof, I comment the map line in my npf.conf, I'm rejected again, and the npfd log shows:
09:31:29.826419 rule 21.rules.0/0(match): block in on fxp0: 192.168.1.35.41366 > 192.168.1.3.22: Flags [FP.], seq 1566:1954, ack 7324, win 1849, options [nop,nop,TS val 7579810 ecr 16], length 388
So, at least we know it should work,
Now, as I mentioned above, this:
lib7 map ure0 dynamic any -> ifaddrs(ure0) pass family inet4 from 192.168.1.0/24 # id="1"
looks like a malformed outbound NAT; the internal network show be directly mapped to the public IP of the internet-facing NIC (or to a generic inet4(ure0) list if the address assigned to the interface is one and one only), not to the dynamic net-seg assigned to it by the local DHCP server.
Would you mind editing your configuration as I posted above?
map ure0 dynamic $localnet -> $my_external_ip
Which should result in:
map ure0 dynamic any -> $my_external_ip pass family inet4 from 192.168.1.0/24 # id="1"
In addition, is your internal DNS properly configured and working?
Is the target device on 192.168.1.30 actually listening on 17106?