Quote from: Schubbie on August 16, 2020, 01:59:24 pmTake a look at the list.jpg I think so.If I type a false key in the Windows-Client I get another screen. So I think that the Server is started.I have the issue too, that the Server didn't start, if I configure and aktivate more than 1 Client on the WireGuard-Server.My other WireGuard-Server on my Synology runs in a VM and works after the last WireGuard Update only with WireGuard on OPNsense I have such issues.This usually happens when endpoint has no /32
Take a look at the list.jpg I think so.If I type a false key in the Windows-Client I get another screen. So I think that the Server is started.I have the issue too, that the Server didn't start, if I configure and aktivate more than 1 Client on the WireGuard-Server.My other WireGuard-Server on my Synology runs in a VM and works after the last WireGuard Update only with WireGuard on OPNsense I have such issues.
Thanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.
root@OPNsense:~ # /usr/local/etc/rc.d/wireguard restart[#] rm -f /var/run/wireguard/wg0.sock[#] wireguard-go wg0INFO: (wg0) 2020/08/17 09:15:09 Starting wireguard-go version 0.0.20200320[#] wg setconf wg0 /tmp/tmp.UvX0PTXh/sh-np.B2qr90[#] ifconfig wg0 inet 10.10.11.1/24 10.10.11.1 alias[#] ifconfig wg0 mtu 1420[#] ifconfig wg0 up[+] Backgrounding route monitor
/usr/local/etc/rc.d/wireguard restartwg-quick: `wg0' is not a WireGuard interface[#] wireguard-go wg0INFO: (wg0) 2020/08/17 09:40:08 Starting wireguard-go version 0.0.20200320[#] wg setconf wg0 /tmp/tmp.IKz26dvT/sh-np.UBog8P[#] ifconfig wg0 inet 100.65.0.1/24 100.65.0.1 alias[#] ifconfig wg0 mtu 1420[#] ifconfig wg0 up[#] resolvconf -a wg0 -x[#] route -q -n add -inet 100.65.0.9/32 -interface wg0[#] route -q -n add -inet 100.65.0.8/32 -interface wg0[#] route -q -n add -inet 100.65.0.7/32 -interface wg0[#] route -q -n add -inet 100.65.0.6/32 -interface wg0[#] route -q -n add -inet 100.65.0.5/32 -interface wg0[#] route -q -n add -inet 100.65.0.4/32 -interface wg0[#] route -q -n add -inet 100.65.0.3/32 -interface wg0[#] route -q -n add -inet 100.65.0.2/32 -interface wg0[#] route -q -n add -inet 100.65.0.15/32 -interface wg0[#] route -q -n add -inet 100.65.0.14/32 -interface wg0[#] route -q -n add -inet 100.65.0.13/32 -interface wg0[#] route -q -n add -inet 100.65.0.12/32 -interface wg0[#] route -q -n add -inet 100.65.0.11/32 -interface wg0[#] route -q -n add -inet 100.65.0.10/32 -interface wg0[#] route -q -n add -inet 192.168.6.0/24 -interface wg0[#] resolvconf -d wg0[#] rm -f /var/run/wireguard/wg0.sock
Code: [Select]root@OPNsense:~ # /usr/local/etc/rc.d/wireguard restart[#] rm -f /var/run/wireguard/wg0.sock[#] wireguard-go wg0INFO: (wg0) 2020/08/17 09:15:09 Starting wireguard-go version 0.0.20200320[#] wg setconf wg0 /tmp/tmp.UvX0PTXh/sh-np.B2qr90[#] ifconfig wg0 inet 10.10.11.1/24 10.10.11.1 alias[#] ifconfig wg0 mtu 1420[#] ifconfig wg0 up[+] Backgrounding route monitor
After a little bit of testing I can give the following infos:When one of the clients attached to a wireguard server contains more then one ip address / network the interface for this server seems not to be starting. if you only have clients with only one ip adress in the server subnet, the interface for the server is starting and you can connect to the server.
Do you see packets in wg0 when you ping 10.10.11.1 from endpoint?
Quote from: gurpal2000 on August 16, 2020, 04:50:00 pmThanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.Two things to check:First, make sure that your firewall allows for traffic from WG to your other subnets. Second, on the client side, make sure that your allowed subnets includes the ones you want to access.
I mean a packet capture on wg interface, do you see incoming packets?
Quote from: tezgno on August 17, 2020, 05:02:21 amQuote from: gurpal2000 on August 16, 2020, 04:50:00 pmThanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.Two things to check:First, make sure that your firewall allows for traffic from WG to your other subnets. Second, on the client side, make sure that your allowed subnets includes the ones you want to access.I think the default wg firewall entry is "all inclusive" (Any).Anyway, previously I would have had entries like this "10.10.0.0/24, 192.168.2.0/24" in the Allowed IPs. To me, these are ranges of IP addresses.Under the new version, I have to change these to "10.10.0.2/32,192.168.2.1/24". Now first is a very specific IP (no range) which is the only end of the tunnel in a VPS. It's fine.The second is actually the IP address of an LXC bridge on a VPS where the wg client lives. But because /24 is a range, it includes other IP addresses on the 2.x subnet. Which is also fine.So things work better, and I can do what I used to do before I think. I don't understand why - which is worrying for me (a newbie).
Quote from: murmelbahn on August 17, 2020, 10:03:22 amAfter a little bit of testing I can give the following infos:When one of the clients attached to a wireguard server contains more then one ip address / network the interface for this server seems not to be starting. if you only have clients with only one ip adress in the server subnet, the interface for the server is starting and you can connect to the server.Which is normal behavior except for Site 2 Site. FreeBSD was more relaxed against misconfig