[solved] Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes

[Ramiro Aceves <ea1abz%gmail.com@localhost>]

Hello,

After many days of blind experimenting, I have got it working (I have to test it a bit more cause now I am too excited ;-) )


Tunnel configuration:

netbsd-raspaZeroW# cat levantatunel.sh
#!/bin/sh
set -x
ifconfig wg0 create mtu 1380
#ifconfig wg0 create mtu 1280
ifconfig wg0 inet 44.27.132.76/32
ifconfig wg0 inet6 fe80::644d:cf7a:c00:bae9/128
wgconfig wg0 set private-key /etc/wg/wg0.priv
wgconfig wg0 add peer A \
asdfasdfasdfasdfasdfasdf= \
--allowed-ips=0.0.0.0/0,::/0 \
--endpoint=44.27.227.1:44000
ifconfig wg0 up


Route modification:

netbsd-raspaZeroW# cat cambia_rutas.sh
#!/bin/sh
set -x
route add 44.27.227.1 192.168.1.1
route delete default
route add default 44.27.132.76


The routes:

netbsd-raspaZeroW# route -n show
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            44.27.132.76       UGS         -        -      -  wg0
44.27.132.76       wg0                UHl         -        -      -  wg0
44.27.132.76/32    44.27.132.76       U           -        -      -  wg0
44.27.227.1        192.168.1.1        UGHS        -        -      -  bwfm0
127/8              127.0.0.1          UGRS        -        -  33176  lo0
127.0.0.1          lo0                UHl         -        -  33176  lo0
192.168.1/24       link#2             UC          -        -      -  bwfm0
192.168.1.230      link#2             UHl         -        -      -  lo0
192.168.1.200      1c:69:7a:0a:83:9d  UHL         -        -      -  bwfm0
192.168.1.1        60:8d:26:32:34:23  UHL         -        -      -  bwfm0

netbsd-raspaZeroW# ifconfig wg0
wg0: flags=0x8041<UP,RUNNING,MULTICAST> mtu 1380
	status: active
	inet6 fe80::ba27:ebff:feed:8547%wg0/64 flags 0 scopeid 0x3
	inet6 fe80::644d:cf7a:c00:bae9%wg0/128 flags 0 scopeid 0x3
	inet 44.27.132.76/32 flags 0



netbsd-raspaZeroW# cat /etc/resolv.conf
# Generated by resolvconf
domain remigio
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 1.0.0.1
netbsd-raspaZeroW#


But the most important thing:

by default:

 sysctl variable  net.inet.tcp.mss_ifmtu=0

setting it to

 sysctl -w  net.inet.tcp.mss_ifmtu=1340 (that was the first guess)

or

 sysctl -w  net.inet.tcp.mss_ifmtu=1

Both appear to work, but have to test more to see if there is a difference

As man page says, only 0 or 1 values seem to be valid.


             tcp.mss_ifmtu
                     If set to 1, TCP calculates the outgoing maximum segment
                     size based on the MTU of the appropriate interface.  If
                     set to 0, it is calculated based on the greater of the
                     MTU of the interface, and the largest (non-loopback)
                     interface MTU on the system.

Looking at the code in

/usr/src/sys/netinet/tcp_subr.c :


	if (tcp_mss_ifmtu == 0)
		switch (af) {
#ifdef INET6
		case AF_INET6:	/* FALLTHROUGH */
#endif
		case AF_INET:
			mss = uimax(in_maxmtu, mss);
			break;
		}

seems that 1 or 1340 should be the same but the experts will say.

I can run now successful ssh sessions from outside.

netbsd-nuc$ ssh 44.27.132.76

(ramiro@44.27.132.76) Password for ramiro@netbsd-raspaZeroW:
Last login: Fri Feb  6 20:14:07 2026 from 85.48.187.62
NetBSD 10.1 (RPI) #0: Mon Dec 16 13:08:11 UTC 2024

Welcome to NetBSD!

netbsd-raspaZeroW$


I have setup a lighttpd server to test and also serves the WEB page.

Also think that sending a ping from the Rpi to the 44.27.132.76 IP is mandatory to mantain the tunnel alive. If not, when time passes, It becomes a bit lazy until it responds to the external requests. 
Have to experiment that subject.


Regards.
Ramiro.