kkcarlc

Following up with some more information on this after reading up about the route I thought was suspect `128.0.0.0/1`. I understand now this is to split the ipv4 address space...

The problem seems to be that OPNsense is not configuring the endpoint route as [documented in the Wireguard docs](https://www.wireguard.com/netns/#the-classic-solutions) (emphasis mine): > The most straightforward technique is to just replace...

I am glad that it worked for you @gsacre. I believe we are using Wireguard in two separate ways. Yours is a connection into your LAN, so your client (e.g....

I have isolated the commit that introduces the bug to dbe52eeaa. I reverse patched `src/opnsense/scripts/Wireguard/wg-service-control.php` in order from `e0cee10ad` to `77fba066b`: ``` e0cee10ad dbe52eeaa 30862f871 c1d2d18a7 0d7d48eb1 77fba066b ``` I...

**Who Is Affected** This issue is specific for users of Wireguard who are intending to send all traffic through a VPN tunnel from their LAN to an upstream provider. They...

@masterhuh I believe that is a separate issue. This bug is only in regard to the initial handshake. Wireguard has two peers, but for discussion one can be called client...

Thanks @cedoromal for your input on this. @fichtner I am currently on 24.1.8, not sure the patch level, but it is the most recent on that version. I have been...

> well specifically I'm wondering if this helps: https://github.com/opnsense/changelog/blob/727f3153899c978ea84682ea5db08e3769f58809/community/24.1/24.1.9#L12 As mentioned just prior, I can test this out a bit later and report back.

@fichtner I just upgraded to 24.1.9_3 and it looks like the issue still exists. Methodology: I disabled the explicit route for Wireguard endpoint, started VPN, did not receive a handshake....

> I remember when I used wireguard on linux and used `::/0`, it would not complete the handshake since it would send it through the tunnel. > > Thats why...