Re: Wireguard woes
El 21/1/26 a las 10:49, Martin Husemann escribió: On Wed, Jan 21, 2026 at 10:44:45AM +0100, Ramiro Aceves wrote: Do you think that in NetBSD-current may I have better luck? I am not aware of any changes that have not been pulled up. Did you try enabling the debug sysctl? Martin Hi Martin , Thanks for answering. Yes, plenty of messages on dmesg after activating debug sysctl (messages that I do not understand from an user perspective :-) ) . Here just an example with the real IPs, no problem at all showing them: Regards. [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 172.234.192.12 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=96, encrypted_len=80 [ 97929.799124] wg_handle_msg_data: outsize=64 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 137.184.215.78 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97929.799124] wg_handle_msg_data: outsize=48 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 95.168.178.138 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97929.799124] wg_handle_msg_data: outsize=48 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 95.168.178.138 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97929.799124] wg_handle_msg_data: outsize=48 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 142.147.97.21 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=128, encrypted_len=112 [ 97929.799124] wg_handle_msg_data: outsize=96 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 44.27.132.76 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 44.27.132.76 [ 97929.799124] wg_send_data_msg: inner=84, padded=96, encrypted_len=112 [ 97929.799124] wg_fill_msg_data: counter=1 [ 97929.849220] wg_overudp_cb: type=4 [ 97929.849220] wg_handle_msg_data: mlen=128, encrypted_len=112 [ 97929.859239] wg_handle_msg_data: outsize=96 [ 97929.859239] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.859239] wg_validate_inner_packet: af=2 [ 97929.859239] wg_pick_peer_by_sa: sa=inet: 44.27.132.76 [ 97929.859239] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97939.759119] wg_overudp_cb: type=4 [ 97939.759119] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97939.759119] wg_handle_msg_data: outsize=48 [ 97939.759119] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97939.759119] wg_validate_inner_packet: af=2 [ 97939.759119] wg_pick_peer_by_sa: sa=inet: 178.20.210.151 [ 97939.759119] wg_handle_msg_data: time_uptime32=97939 wgs_time_last_data_sent=97929 [ 97939.759119] wg_schedule_peer_task: tasks=0, task=16 [ 97939.759119] wg_send_data_msg: inner=0, padded=0, encrypted_len=16 [ 97939.759119] wg_fill_msg_data: counter=2 [ 97946.592533] wg_overudp_cb: type=4 [ 97946.592533] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97946.592533] wg_handle_msg_data: outsize=48 [ 97946.592533] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97946.592533] wg_validate_inner_packet: af=2 [ 97946.592533] wg_pick_peer_by_sa: sa=inet: 79.124.40.114 [ 97946.592533] wg_handle_msg_data: time_uptime32=97946 wgs_time_last_data_sent=97939 [ 97949.383826] wg_overudp_cb: type=4 [ 97949.383826] wg_handle_msg_data: mlen=96, encrypted_len=80 [ 97949.383826] wg_handle_msg_data: outsize=64 [ 97949.383826] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97949.383826] wg_validate_inner_packet: af=2 [ 97949.383826
Re: Wireguard woes
On Wed, Jan 21, 2026 at 10:44:45AM +0100, Ramiro Aceves wrote: > Do you think that in NetBSD-current may I have better luck? I am not aware of any changes that have not been pulled up. Did you try enabling the debug sysctl? Martin
Re: Wireguard woes
El 20/1/26 a las 20:22, Ramiro Aceves escribió: El 20/1/26 a las 18:38, Martin Husemann escribió: On Tue, Jan 20, 2026 at 06:25:42PM +0100, Ramiro Aceves wrote: And then it works again from the local network. This may be related to the absence of the PersistentKeepalive = 20 parameter that comes in the configuration file sent by email from the tunnel provider and that does not exist in NetBSD implementation of WireGuard. It has a default keep alive of 10s, you can adjust it with sysctl net.wg.keepalive_timeout If you want to find out what goes wrong you should enable sysctl net.wg.debug and see if it logs something interesting. Martin Thanks Martin, Oh yes, that is the default, 10 seconds, but this way the connection drops, I do not know why if they recommend a keepalive of 20 seconds, it shoud be enough. It seems to always resurrect with ping to 44.x.y.z from the raspberry pi. netbsd-raspaZeroW# sysctl net.wg.keepalive_timeout net.wg.keepalive_timeout = 10 The "big" problem now is that I cannot ping the 44 IP from the outside. Regards. Ramiro. Hello, Do you think that in NetBSD-current may I have better luck? Thanks.
Re: Wireguard woes
El 20/1/26 a las 18:38, Martin Husemann escribió: On Tue, Jan 20, 2026 at 06:25:42PM +0100, Ramiro Aceves wrote: And then it works again from the local network. This may be related to the absence of the PersistentKeepalive = 20 parameter that comes in the configuration file sent by email from the tunnel provider and that does not exist in NetBSD implementation of WireGuard. It has a default keep alive of 10s, you can adjust it with sysctl net.wg.keepalive_timeout If you want to find out what goes wrong you should enable sysctl net.wg.debug and see if it logs something interesting. Martin Thanks Martin, Oh yes, that is the default, 10 seconds, but this way the connection drops, I do not know why if they recommend a keepalive of 20 seconds, it shoud be enough. It seems to always resurrect with ping to 44.x.y.z from the raspberry pi. netbsd-raspaZeroW# sysctl net.wg.keepalive_timeout net.wg.keepalive_timeout = 10 The "big" problem now is that I cannot ping the 44 IP from the outside. Regards. Ramiro.
Re: Wireguard woes
El 20/1/26 a las 19:53, Sad Clouds escribió: On Tue, 20 Jan 2026 18:25:42 +0100 Ramiro Aceves wrote: And then it works again from the local network. This may be related to the absence of the PersistentKeepalive = 20 parameter that comes in the configuration file sent by email from the tunnel provider and that does not exist in NetBSD implementation of WireGuard. If I'm not mistaken, persistent keepalive setting is sometimes needed for NAT firewalls that keep state. You can try running ping in a while loop every 10 seconds and see if this resolves connectivity issues. Hello Sad Thanks so much for your suggestion but it does not work. The trick mantains active the connection but I cannot ping from outside the local network to the asignated 44 net IP. I have just tested from Debian just to see and it works fine. I will continue investigating. Regards.
Re: Wireguard woes
On Tue, 20 Jan 2026 18:25:42 +0100 Ramiro Aceves wrote: > And then it works again from the local network. This may be related to > the absence of the PersistentKeepalive = 20 parameter that comes in the > configuration file sent by email from the tunnel provider and that does > not exist in NetBSD implementation of WireGuard. If I'm not mistaken, persistent keepalive setting is sometimes needed for NAT firewalls that keep state. You can try running ping in a while loop every 10 seconds and see if this resolves connectivity issues.
Re: Wireguard woes
On Tue, Jan 20, 2026 at 06:25:42PM +0100, Ramiro Aceves wrote: > And then it works again from the local network. This may be related to the > absence of the PersistentKeepalive = 20 parameter that comes in the > configuration file sent by email from the tunnel provider and that does not > exist in NetBSD implementation of WireGuard. It has a default keep alive of 10s, you can adjust it with sysctl net.wg.keepalive_timeout If you want to find out what goes wrong you should enable sysctl net.wg.debug and see if it logs something interesting. Martin
Re: Wireguard woes
El 20/1/26 a las 15:00, Sad Clouds escribió:
These are my notes for NetBSD and Linux.>
My normal subnet is 10.0.0.0/16 and wireguard VPN subnet is 10.1.0.0/16.
rp4-4g is my Raspberry Pi 4 4GB NFS server.
rp4-8g is my Raspberry Pi 4 8GB Debian NFS client.
z600 is my HP Z600 Debian NFS client.
Substitute these for your own IP addresses and peers. Good luck.
Configure NetBSD as WireGuard server:
Load if_wg module on boot:
vi /etc/modules.conf
if_wg
and then reboot
Generate server private and public keys:
umask 0077
mkdir /etc/wireguard
wg-keygen > /etc/wireguard/wg0.prv
wg-keygen --pub < /etc/wireguard/wg0.prv > /etc/wireguard/wg0.pub
umask 0022
Configure wg0 interface and add peers (max peer name length is 16 chars):
cat > /etc/ifconfig.wg0 << 'EOF'
inet 10.1.0.5/16
!wgconfig ${int} set private-key /etc/wireguard/${int}.prv
!wgconfig ${int} set listen-port 51820
!wgconfig ${int} add peer z600
--allowed-ips=10.1.0.2/32
!wgconfig ${int} add peer rp4-8g
--allowed-ips=10.1.0.6/32
up
EOF
rp4-4g$ ifconfig
genet0: flags=0x8843 mtu 1500
ec_capabilities=0x1
ec_enabled=0
address: dc:a6:32:31:71:32
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::dea6:32ff:fe31:7132%genet0/64 flags 0 scopeid 0x1
inet 10.0.0.5/16 broadcast 10.0.255.255 flags 0
lo0: flags=0x8049 mtu 33624
status: active
inet6 ::1/128 flags 0x20
inet6 fe80::1%lo0/64 flags 0 scopeid 0x2
inet 127.0.0.1/8 flags 0
wg0: flags=0x8041 mtu 1420
status: active
inet6 fe80::dea6:32ff:fe31:7132%wg0/64 flags 0 scopeid 0x3
inet 10.1.0.5/16 flags 0
Configure Debian as WireGuard client:
sudo aptitude install wireguard
Generate client private and public keys:
prv_key=$(wg genkey) &&
pub_key=$(echo ${prv_key:?} | wg pubkey) &&
echo "prv_key: ${prv_key}" &&
echo "pub_key: ${pub_key}" &&
unset prv_key pub_key
Manual config:
cat > /etc/network/interfaces.d/wg0 << 'EOF'
auto wg0
iface wg0 inet static
address 10.1.0.6
netmask 255.255.0.0
pre-up ip link add $IFACE type wireguard
pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf
#post-up ip route add 10.1.0.0/16 dev wg0
post-down ip link del $IFACE
EOF
cat > /etc/wireguard/wg0.conf << 'EOF'
[Interface]
PrivateKey =
[Peer]
Endpoint = 10.0.0.5:51820
PublicKey =
AllowedIPs = 10.1.0.5/32
EOF
Network manager config (alternative to manual config):
Connection name: vpn-rp4-4g
Interface name : wg0
Private key: XXX
Peers:
Public key : XXX
Allowed IPs: 10.1.0.5/32
Endpoint : 10.0.0.5:51820
IPv4 Settings:
Method : Manual
IP : 10.1.0.2
Netmask: 16
Gateway:
Thanks so much Sad for your great notes. I appreciate them very much. I
see that my NetBSD configuration is same as yours except for the
"wgconfig set listen-port " that I did not use cause I am in the
client side.
I observe that:
-Pinging from outside of the local network to 44.x.y.z: it doesn’t
work.
-Pinging from another machine on the local network to 44.x.y.z: it
works. But it only works for a while; afterwards it stops working. To
make it work again I have to do:
ifconfig wg0 down
ifconfig wg0 up
And then it works again from the local network. This may be related to
the absence of the PersistentKeepalive = 20 parameter that comes in the
configuration file sent by email from the tunnel provider and that does
not exist in NetBSD implementation of WireGuard.
I do not know...
I have tested the same thing in RaspberrypiZeroW and Raspberrypi4 with
same result. Both systems in NetBSD 10.1
Regards.
Ramiro.
Re: Wireguard woes
These are my notes for NetBSD and Linux.
My normal subnet is 10.0.0.0/16 and wireguard VPN subnet is 10.1.0.0/16.
rp4-4g is my Raspberry Pi 4 4GB NFS server.
rp4-8g is my Raspberry Pi 4 8GB Debian NFS client.
z600 is my HP Z600 Debian NFS client.
Substitute these for your own IP addresses and peers. Good luck.
Configure NetBSD as WireGuard server:
Load if_wg module on boot:
vi /etc/modules.conf
if_wg
and then reboot
Generate server private and public keys:
umask 0077
mkdir /etc/wireguard
wg-keygen > /etc/wireguard/wg0.prv
wg-keygen --pub < /etc/wireguard/wg0.prv > /etc/wireguard/wg0.pub
umask 0022
Configure wg0 interface and add peers (max peer name length is 16 chars):
cat > /etc/ifconfig.wg0 << 'EOF'
inet 10.1.0.5/16
!wgconfig ${int} set private-key /etc/wireguard/${int}.prv
!wgconfig ${int} set listen-port 51820
!wgconfig ${int} add peer z600
--allowed-ips=10.1.0.2/32
!wgconfig ${int} add peer rp4-8g
--allowed-ips=10.1.0.6/32
up
EOF
rp4-4g$ ifconfig
genet0: flags=0x8843 mtu 1500
ec_capabilities=0x1
ec_enabled=0
address: dc:a6:32:31:71:32
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::dea6:32ff:fe31:7132%genet0/64 flags 0 scopeid 0x1
inet 10.0.0.5/16 broadcast 10.0.255.255 flags 0
lo0: flags=0x8049 mtu 33624
status: active
inet6 ::1/128 flags 0x20
inet6 fe80::1%lo0/64 flags 0 scopeid 0x2
inet 127.0.0.1/8 flags 0
wg0: flags=0x8041 mtu 1420
status: active
inet6 fe80::dea6:32ff:fe31:7132%wg0/64 flags 0 scopeid 0x3
inet 10.1.0.5/16 flags 0
Configure Debian as WireGuard client:
sudo aptitude install wireguard
Generate client private and public keys:
prv_key=$(wg genkey) &&
pub_key=$(echo ${prv_key:?} | wg pubkey) &&
echo "prv_key: ${prv_key}" &&
echo "pub_key: ${pub_key}" &&
unset prv_key pub_key
Manual config:
cat > /etc/network/interfaces.d/wg0 << 'EOF'
auto wg0
iface wg0 inet static
address 10.1.0.6
netmask 255.255.0.0
pre-up ip link add $IFACE type wireguard
pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf
#post-up ip route add 10.1.0.0/16 dev wg0
post-down ip link del $IFACE
EOF
cat > /etc/wireguard/wg0.conf << 'EOF'
[Interface]
PrivateKey =
[Peer]
Endpoint = 10.0.0.5:51820
PublicKey =
AllowedIPs = 10.1.0.5/32
EOF
Network manager config (alternative to manual config):
Connection name: vpn-rp4-4g
Interface name : wg0
Private key: XXX
Peers:
Public key : XXX
Allowed IPs: 10.1.0.5/32
Endpoint : 10.0.0.5:51820
IPv4 Settings:
Method : Manual
IP : 10.1.0.2
Netmask: 16
Gateway:
Re: Wireguard woes
El 28/9/25 a las 21:51, Peter Miller escribió: On Sat, Sep 27, 2025 at 1:10 PM beaker wrote: sudo ifconfig wg0 create sudo ifconfig wg0 inet 10.2.0.2/32 # /etc/wg/wg0 contains just the Proton PrivateKey sudo wgconfig wg0 set private-key /etc/wg/wg0 sudo wgconfig wg0 add peer Proton '' \ --allowed-ips=0.0.0.0/0,::/0 --endpoint= sudo ifconfig wg0 up fi I have wireguard working fine on NetBSD server and client with a similar looking config. No experience with Proton, but I don't see anything wrong here. My understanding is that changing the default route shouldn't be needed with wireguard and doing so via 'sudo route -f add default 10.2.0.2' consistently hangs the system.. try this # change default route to the Proton servers Peer address. I'm just guessing that it's 10.2.0.1 route change default 10.2.0.1 You might want to remove the DNS line too just while troubleshooting, or set it to 1.1.1.1 or something first. Hello I have the same problem trying to make a tunnel from https://connect.44net.cloud work using the built in NetBSD WireGuard. They provide a free IP address in 44.0.0.0 range for amateur radio registered hams and a tunnel. I see the tunnel ok and "connected" in green colour in the provider WEB admin page but if I ping my IP from outside it does not return. I am using a RaspberryPi Zero W with this config wgconfig script: #!/bin/sh set -x ifconfig wg0 create ifconfig wg0 inet 44.x.y.z/32 ifconfig wg0 inet6 a::b:c:d:f/128 wgconfig wg0 set private-key /etc/wg/wg0.priv wgconfig wg0 add peer A \ xzxzxzxzxzxzxzxcccxvzcxcxzc= \ --allowed-ips=0.0.0.0/0,::/0 \ --endpoint=44.r.s.1:44000 ifconfig wg0 up wg0 is up and running: netbsd-raspaZeroW# ifconfig wg0 wg0: flags=0x8041 mtu 1420 status: active inet6 a::b:e:f:8547%wg0/64 flags 0 scopeid 0x3 inet6 a::b:c:d:bae9%wg0/128 flags 0 scopeid 0x3 inet 44.x.y.z/32 flags 0 Sorry for destroying the IPs, hope not to difficult reading. I also could not replicate this provider settings, I di not found a NetBSD wg equivalent: DNS = 1.1.1.1,1.0.0.1 MTU = 1380 PersistentKeepalive = 20 netbsd-raspaZeroW# route -n show Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface default192.168.1.1UGS -- - bwfm0 44.x.y.z wg0UHl -- - wg0 44.x.y.z/3244.x.y.z U -- - wg0 127/8 127.0.0.1 UGRS-- 33176 lo0 127.0.0.1 lo0UHl -- 33176 lo0 192.168.1/24 link#2 UC -- - bwfm0 192.168.1.230 link#2 UHl -- - lo0 192.168.1.203 d8:3a:dd:99:78:45 UHL -- - bwfm0 192.168.1.160:8d:26:32:34:23 UHL -- - bwfm0 Thanks. Ramiro.
Re: Wireguard woes
On Sat, Sep 27, 2025 at 1:10 PM beaker wrote: > sudo ifconfig wg0 create > sudo ifconfig wg0 inet 10.2.0.2/32 > # /etc/wg/wg0 contains just the Proton PrivateKey > sudo wgconfig wg0 set private-key /etc/wg/wg0 > sudo wgconfig wg0 add peer Proton '' \ > --allowed-ips=0.0.0.0/0,::/0 --endpoint= > sudo ifconfig wg0 up > fi I have wireguard working fine on NetBSD server and client with a similar looking config. No experience with Proton, but I don't see anything wrong here. > My understanding is that changing the default route shouldn't be needed with > wireguard and doing so via 'sudo route -f add default 10.2.0.2' consistently > hangs the system.. try this # change default route to the Proton servers Peer address. I'm just guessing that it's 10.2.0.1 route change default 10.2.0.1 You might want to remove the DNS line too just while troubleshooting, or set it to 1.1.1.1 or something first. -- Thanks Peter
