theradgrad 1 Posted ... Hello all, A few years ago I had forwarded some ports through AirVPN's site. It worked just fine and so I left it alone all of this time later. For some reason now, it doesn't seem to be actually forwarding them. I'm using OpenBSD and am connected to AirVPN's servers through openvpn. Port checks fail, connections time out, but the servers I'm running locally have indeed occupied those ports (I can access via its local IP). The firewall (pf) has those ports allowed over tun0. Is there something I'm missing or doing wrong, or is there a tiny chance Helvetios (server in question) has some issues? FWIW I tried reconnecting to AirVPN multiple times in the hopes of reaching a different server, but every single time it connected to Helvetios. Thank you in advance if you can help shed some light on this. Quote Share this post Link to post
Staff 10569 Posted ... @theradgrad 13 hours ago, theradgrad said: Port checks fail, connections time out, Hello! In reality your current error message is connection refused (111). It means in general that the packets were forwarded and reached the destination (your node), but it actively reset the connection via TCP RST. We have also checked in real time on the server you mention and packets are properly forwarded from the correct ports to your VPN IP address:port. 13 hours ago, theradgrad said: The firewall (pf) has those ports allowed over tun0. Please make sure that tun0 is the correct interface name. If it is, the fact that the packets reach the OpenBSD host and it actively replies with a TCP RST suggests the kernel accepted the packet but decided there was no valid listening socket or the packet didn't belong to an existing connection. Please follow this checklist: https://airvpn.org/forums/topic/66388-port-forwarding/?do=findComment&comment=243305 Kind regards Quote Share this post Link to post
theradgrad 1 Posted ... (edited) Hi, thank you for the reply. 13 hours ago, Staff said: In reality your current error message is connection refused (111). In the AirVPN web interface, I only see that for TCP connections, but never for any UDP ones (regardless of that, though, none of them work unfortunately). Here's an example of one of my forwarded ports that uses both: 13 hours ago, Staff said: Please make sure that tun0 is the correct interface name. Yes, I just confirmed it now. bge0 is the name of my physical NIC and tun0 is OpenVPN's virtual NIC: $ ifconfig lo0: flags=2008049<UP,LOOPBACK,RUNNING,MULTICAST,LRO> mtu 32768 index 3 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 bge0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500 lladdr xx:xx:xx:xx:xx:xx index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.1.181 netmask 0xffffff00 broadcast 192.168.1.255 enc0: flags=0<> index 2 priority 0 llprio 3 groups: enc status: active pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136 index 4 priority 0 llprio 3 groups: pflog tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 index 14 priority 0 llprio 3 groups: tun status: active inet 10.xxx.xxx.xxx --> 10.xxx.xxx.1 netmask 0xffffff00 inet6 fe80::xxxx:xxxx:xxxx:xxxx%tun0 --> prefixlen 64 scopeid 0xe inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 --> prefixlen 64 Here's a copy of my pf.conf (with some irrelevant data stripped for privacy/security), if that helps: # Define macros: ext_if = "bge0" # Ethernet interface (physical) vpn_if = "tun0" # OpenVPN interface (virtual) # Don't filter on loopback interfaces: set skip on lo # Scrub incoming packets: match in all scrub (no-df random-id) # Modify incoming IPv4 packets of all protocols (TCP, UDP, ICMP, etc.) over all # interfaces (excl. loX) in order to remove their "don't fragment" bit, and to # randomize their IP identification field in the event it's set to zero. May # help in situations where weird NFS implementations send fragmented packets # containing "don't fragment" bits, and where annoying OSes send zero IP ID # fields. It _may_ cause HTTPS to break, as noted here: # https://serverfault.com/questions/412083 # Honestly, not entirely sure what it does, but it sounds okay I suppose... # Block everything by default: block # Enforce antispoofing measures: block in quick from urpf-failed # https://dylanharris.org/blog/2017/b28.shtml # All data leaving the internal network must go through tun0, and never outside # it, so as per the above article this should be enabled. # Whitelist incoming protocol/port connections over bge0: pass on $ext_if proto {tcp udp} from $ext_if:network to $ext_if port {22 XXXXX} # XXXXX is a forwarded port that should also be accessible locally (I have # confirmed that it is). pass in on $ext_if proto icmp from $ext_if:network to any pass out on $ext_if proto icmp from any to $ext_if:network # Allow DNS (for server IP lookup): pass quick proto {tcp udp} from any to any port 53 keep state # https://daemonforums.org/showthread.php?t=11666 # Whitelist VPN IP addresses: include "/etc/pf.conf.d/vpn_server_ips.conf" # Generated through the relevant steps mentioned here: # https://airvpn.org/forums/topic/65332-prevent-leaks-with-bsd-pf/ pass in log (to pflog1) on $vpn_if proto {tcp udp} to any port {YYYYY ZZZZZ} pass in log (to pflog1) on $vpn_if proto udp to any port {XXXXX} # YYYYY/ZZZZZ = other forwarded ports (traffic on these ports should only # traverse over AirVPN) pass on $vpn_if all 13 hours ago, Staff said: Please follow this checklist: https://airvpn.org/forums/topic/66388-port-forwarding/?do=findComment&comment=243305 Thanks for linking me to this. Here's what I've determined: >please make sure that the listening program is really running and listening to the correct port, and that it is started only after the VPN connection has been established <Confirmed via access to the server from another device on the local network. Also, the server daemon was started after connecting to AirVPN with openvpn. >if a bind option is available on the listening program settings please make sure that the program binds to the VPN interface and not to the physical network interface <Intentionally left unbound so it broadcasts on all interfaces (desired operation for the server daemon in particular I'm trying to access). I bound it anyway as a test but was still unable to connect externally. >if automatic port mapping options, including UPnP and NAT-PMP, are available on the listening program settings please make sure that they are all disabled <It's unsupported in all of the server daemons I have. >please make sure that no firewall rule blocks incoming packets to the listening program. You need to check while the system is connected to the VPN as some firewall tools change rule set according to the network type the system is connected to <From what I understand of my pf.conf, those connections should not be blocked (I did as much research as I could but may still be mistaken). >if the listening program runs on a machine that's not directly connected to the VPN but shares the connection with another device, remember to forward packets from the tun interface of the device creating the tunnel to the final destination (typical example, a router sharing VPN traffic with all the devices behind it) <My OpenBSD host is connected directly to AirVPN, and it only acts as an external server (ports XXXXX/YYYYY/ZZZZZ) and internal server (ports 22/XXXXX) for a few daemons. Would you happen to know what steps I should try next, or if there are any config files/command outputs that would be beneficial to see? Many thanks Edited ... by theradgrad Added `ipconfig` output. Quote Share this post Link to post
Staff 10569 Posted ... @theradgrad Hello! The fact that the host is sending a RST strongly suggests the packet is making it through PF and reaching the TCP stack, where no matching listening socket exists for that specific destination IP and port. The port tester does not test UDP, only TCP. Please ascertain whether the listening program is really listening to all interfaces with: netstat -an -f inet Look specifically for something like 0.0.0.0:YYYYY or VPN_IP:YYYYY If instead it shows 127.0.0.1:YYYYY or LAN_IP:YYYYY then the kernel will immediately send RSTs for packets addressed to the VPN IP. Also, please send the output of the following commands: sudo sockstat -4 -l sudo netstat -rn Finally, a simultaneous packet capture while reproducing the issue: sudo tcpdump -ni tun0 tcp port YYYYY Kind regards 1 theradgrad reacted to this Quote Share this post Link to post
theradgrad 1 Posted ... (edited) Hello, thank you for replying and demystifying more details for me. I started running through the commands you listed and I think I may have discovered what the problem was (EDIT: probably not, see bottom). I was running my one server binary through an SSH session, which I could've sworn I've done without any issues (maybe I only thought it was okay because of using the host's local IP in those instances), but running it in a terminal window on the host itself seemed to completely resolve the issue. I figure this is a default security measure of OpenBSD which is honestly for the better. As for the other two forwarded ports, they seem to be working perfectly, despite still receiving those strange TCP RSTs through AirVPN's Web-based port checker and on other various port checking sites. Thank you for all of the guidance and helping me look in just the right places for me to figure out the issue. Cheers! If you or anyone else would still like me to post the command outputs, feel free to reply and ask me. EDIT: Never mind, I celebrated too quickly. I temporarily closed the server binary and reopened it, and now I'm back to square one. I'm currently investigating further. EDIT 2: A system restart got it working again. The only change I made to my system in between then was updating something unrelated in FVWM and relaunching that, but maybe it then leading to a different X11 process caused further issues (I'm still fairly new to OpenBSD). Anyway, seems okay now...only time will tell. EDIT 3: It stopped working again. The openvpn connection was up (uninterrupted) and the server binary was up (uninterrupted), it worked just fine initially, then I tried it a second time and it won't work anymore. Investigating some more. Edited ... by theradgrad Stopped working again. Quote Share this post Link to post
theradgrad 1 Posted ... Further testing reveals no pattern as to when it works and when it doesn't (95% of the time it doesn't work). Below are the command outputs for the ones suggested by Staff. I had to adjust some slightly as behavior differs between Linux/FreeBSD (what I presume the commands may be for) and OpenBSD. $ netstat -an -f inet Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address TCP-State tcp 0 64 192.168.1.181.22 192.168.1.187.53299 ESTABLISHED tcp 0 0 *.22 *.* LISTEN tcp 0 0 127.0.0.1.25 *.* LISTEN Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address udp 0 0 10.xxx.xxx.xxx.33179 172.234.25.10.123 udp 0 0 10.xxx.xxx.xxx.28723 66.244.16.123.123 udp 0 0 10.xxx.xxx.xxx.3525 166.88.142.52.123 udp 0 0 10.xxx.xxx.xxx.15687 72.14.186.59.123 udp 0 0 *.42358 *.* udp 0 0 *.9248 *.* udp 0 0 *.* *.* udp 0 0 *.* *.* udp 0 0 192.168.1.181.68 *.* 22 hours ago, Staff said: Look specifically for something like 0.0.0.0:YYYYY or VPN_IP:YYYYY If instead it shows 127.0.0.1:YYYYY or LAN_IP:YYYYY then the kernel will immediately send RSTs for packets addressed to the VPN IP. Sadly, none of the ports I have forwarded (XXXXX/YYYYY/ZZZZZ) come up in the output. 23 hours ago, Staff said: sudo sockstat -4 -l OpenBSD doesn't natively have sockstat, but I was able to find a similar script on GitHub Gist (also attached). $ chmod +x ~/Downloads/sockstat && doas ~/Downloads/sockstat USER CMD PID MOUNT MODE ADDR _slaacd slaacd 30811 internet6 udp *:0 root slaacd 1097 internet6 udp *:0 root openvpn 27593 internet udp *:42358 _dhcp dhcpleased 13172 internet udp 192.168.1.181:68 _smtpd smtpd 24634 internet tcp 127.0.0.1:25 theradgrad run-server 59906 internet udp *:XXXXX root dhcpleased 78891 internet udp *:0 root sshd 88044 internet6 tcp *:22 XXXXX does appear in this list (although YYYYY and ZZZZZ do not). $ doas netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 192.168.1.1 UGS 0 13 - 8 bge0 0/1 10.xxx.xxx.1 UGS 1 23 - 8 tun0 128/1 10.xxx.xxx.1 UGS 5 48 - 8 tun0 224/4 127.0.0.1 URS 0 0 32768 8 lo0 10.xxx.xxx/24 10.xxx.xxx.1 UGS 0 0 - 8 tun0 10.xxx.xxx.1 10.xxx.xxx.xxx UHh 3 3 - 8 tun0 10.xxx.xxx.xxx 10.xxx.xxx.xxx UHl 0 46680 - 1 tun0 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1 2 32768 1 lo0 192.168.1/24 192.168.1.181 UCn 2 1467 - 4 bge0 192.168.1.1 xx:xx:xx:xx:xx:xx UHLch 2 364 - 3 bge0 192.168.1.181 xx:xx:xx:xx:xx:xx UHLl 0 119221 - 1 bge0 192.168.1.187 xx:xx:xx:xx:xx:xx UHLc 3 707 - 3 bge0 192.168.1.255 192.168.1.181 UHb 0 0 - 1 bge0 204.8.98.32/32 192.168.1.1 UGS 1 1 - 8 bge0 Internet6: Destination Gateway Flags Refs Use Mtu Prio Iface ::/3 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 UGS 0 0 - 8 tun0 ::/96 ::1 UGRS 0 0 32768 8 lo0 ::1 ::1 UHhl 10 20 32768 1 lo0 ::ffff:0.0.0.0/96 ::1 UGRS 0 0 32768 8 lo0 2000::/4 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 UGS 1 29 - 8 tun0 2002::/24 ::1 UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1 UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1 UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1 UGRS 0 0 32768 8 lo0 3000::/4 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 UGS 0 0 - 8 tun0 fc00::/7 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 UGS 0 0 - 8 tun0 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:/64 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 UCn 1 0 - 4 tun0 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:/64 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 UGS 0 0 - 8 tun0 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 link#0 UHch 4 8 - 3 tun0 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 UHhl 1 11 - 1 tun0 fe80::/10 ::1 UGRS 0 2 32768 8 lo0 fec0::/10 ::1 UGRS 0 0 32768 8 lo0 fe80::1%lo0 fe80::1%lo0 UHl 0 0 32768 1 lo0 fe80::%tun0/64 fe80::xxxx:xxxx:xxxx:xxxx%tun0 Un 0 0 - 4 tun0 fe80::xxxx:xxxx:xxxx:xxxx%tun0 fe80::xxxx:xxxx:xxxx:xxxx%tun0 UHl 0 0 - 1 tun0 ff01::/16 ::1 UGRS 0 3 32768 8 lo0 ff01::%lo0/32 fe80::1%lo0 Um 0 1 32768 4 lo0 ff01::%tun0/32 fe80::xxxx:xxxx:xxxx:xxxx%tun0 Um 0 1 - 4 tun0 ff02::/16 ::1 UGRS 0 3 32768 8 lo0 ff02::%lo0/32 fe80::1%lo0 Um 0 1 32768 4 lo0 ff02::%tun0/32 fe80::xxxx:xxxx:xxxx:xxxx%tun0 Um 0 2 - 4 tun0 No XXXXX/YYYYY/ZZZZZ here. On 6/29/2026 at 6:03 AM, Staff said: Finally, a simultaneous packet capture while reproducing the issue: $ doas tcpdump -ni tun0 tcp port XXXXX tcpdump: listening on tun0, link-type LOOP ^C 829 packets received by filter 0 packets dropped by kernel I started the packet capture for XXXXX, then tried connecting to the server externally (failed), then SIGINTed the capture process. Strangely, no packets were dropped. YYYYY and ZZZZZ (these should only be accessible externally) both show a bunch of traffic when connecting externally, which seems work significantly more reliably. External port checks on those also show traffic upon each check (but still claim to be closed). Thank you sockstat Quote Share this post Link to post
theradgrad 1 Posted ... (edited) Tested it again today. My server was off entirely, so I turned it back on and logged in. Ran the server binary, connected externally (XXXXX port forward), worked just fine for about 10 minutes until I disconnected my client manually. Went to connect again, didn't work. Relaunch the server binary, still doesn't work. I am very confused... I'm contemplating on going full scorched earth with my OpenBSD install but I don't entirely look forward to doing that, considering how much labor I've put into it over the past few years. Edited ... by theradgrad Explained what further steps I may have to take. Quote Share this post Link to post
Not connected, Your IP: 216.73.217.100
Online: 43220 users - 466737 Mbit/s total BW