Wireguard site-to-site setup only works on default WAN IP not VIP

[chemlud]

And the public key has been correctly generated for the respective private key? I have seen yesterday a wireguard with traffic going back and forth but not getting the handshake done before actually sending some traffic from a LAN client.

[akron]

Handshake errors are not good. You should be able to connect with that client.
WAN has a rule to allow that traffic? Do you see anything in the live view? Enable logging on rules, that have something to do with your traffic.

the WAN rule is working because the tunnel comes up, you can see the rule bellow

from server I try to reach the client peer on 172.20.20.2 and it passes, but doesn't reach the other side, same problem with client trying to reach 172.20.20.1 on server side

[Gauss23]

Please enable logging for the WAN rule. You should see the traffic arriving.

And just because traffic is leaving through the wg0 interface doesn't mean it's reaching its destination. WG is stateless, unlike OpenVPN.

[akron]

And the public key has been correctly generated for the respective private key? I have seen yesterday a wireguard with traffic going back and forth but not getting the handshake done before actually sending some traffic from a LAN client.

ok interesting, Pease explain, I am generating the keys simply by emptying the public and private fields on the local menu on server and client

then copying the pub key and pasting on the peer side at each location, meaning server Pub key goes to the client peer config as the server to connect to and client pub key goes on the peer config of the server on the endpoint menu

[akron]

Please enable logging for the WAN rule. You should see the traffic arriving.

And just because traffic is leaving through the wg0 interface doesn't mean it's reaching its destination. WG is stateless, unlike OpenVPN.

ok further interesting, what does stateless mean exactly and how it differs form OpenVPN that is running also on the same server fine

[Gauss23]

OpenVPN can tell if a connection is living or not.

With WireGuard every packet is on its own. You can only tell when the last handshake took place

[chemlud]

ok interesting, Pease explain, I am generating the keys simply by emptying the public and private fields on the local menu on server and client

then copying the pub key and pasting on the peer side at each location, meaning server Pub key goes to the client peer config as the server to connect to and client pub key goes on the peer config of the server on the endpoint menu

I always generate both key pairs on another linux machine (never take the first one ;-) )

Code Select Expand

$ (umask 077 && wg genkey > wg-server-private.key)
$ wg pubkey < wg-server-private.key > wg-server-public.key

and

Code Select Expand

$ (umask 077 && wg genkey > wg-client-private.key)
$ wg pubkey < wg-client-private.key > wg-client-public.key

..and don't forget to delete the files after configuring

[akron]

ok I may be into something, the word "stateless" rings alarm bells on my rule setup as this is a bit messy at present

if the problem is what I think it will be I have no one to blame but myself for overlooking this.

I'm relatively new to WG and always used OpenVPN without issues since forever

will clean up and start fresh

[akron]

OpenVPN can tell if a connection is living or not.

With WireGuard every packet is on its own. You can only tell when the last handshake took place

ok I had some sort of success, however not sure how to fix it on a permanent basis

the problem was because I use multiple VIPs on the Site A public WAN interface, the VPN public IP is one of those VIPs, if I use the actually IP of the network interface the tunnel comes up and I can ping both locations subnets, however I would prefer to use a dedicated VIP for WG and not the default public IP.


OpenVPN been working in this manned without any problems, although the client connects to a specific public IP, the reply comes on a different IP which is the default IP of the firewall. This behaviour obviously did not work on WG and it wont work if the reply comes on a different IP than the default outbound WAN interface IP.

I guess  what I need to do is to create an outbound rule on server side to make sure the replica back to the client goes on the actual VIP public IP and not the default one to fix this problem?


like this: WAN    WireGuard net    *    *    51820    185.xx VIP IP    *    YES    WG 

[Gauss23]

As far as I know that's currently not possible.

[akron]

As far as I know that's currently not possible.

ok that is interesting, so this is a know limitation of the WG on OPNsense platform or is in all platforms?

I am still confused how WG works only by using the default public IP of the firewall and not a simple VIP part of that same WAN interface?

there isn't a way or outbound rule that can be created to force the reply back to the client to go on the same public IP as the IP client connects to the server?

not a killer problem but would be nice to know if we can escape this situation with a outbound NAT rule on the server side.

still trying to figure it out why this doesn't affect OpenVPN tunnels, how does the client know that the reply comes on a different IP than the one he connects to as the server?

very confusing for me indeed...

[akron]

As far as I know that's currently not possible.

Just a quick update, thanks for all the help, I got to the bottom of the problem by simply using the default WAN public IP for the tunnel and not one of the several VIPs I use on the WAN interface.

maybe others have the same problem and know how to fix it, however as far I tested the WG site to site tunnel only works when using the default public IP address of the firewall doesn't work if we use public IP VIPs or alias.

if anyone knows a work around would be nice.

[mimugmail]

Its unsupported by WireGuard, already asked Jason several times

[akron]

Its unsupported by WireGuard, already asked Jason several times

yes I got to the bottom of it all, using only default WAN IP, also have outbound internet over the tunnel working and NAT port forwarding back over the tunnel to clients working

one small tip for other users experiencing problems, you need to setup manual MSS value on destination WG interface otherwise the TCP traffic wont work properly from client behind the tunnel, not sure why but I found this if in one of mimugmail posts about wireguard MTU and MSS issues

all looking good so far, retired all OpenVPN tunnels

[mimugmail]

Can you post a screenshot of this portforward please?