Messages

Can you post a screenshot of this portforward please?

this is how I have it:

Assuming you already have Site 1 (Client) LAN + Internet  going over Site 2 (Server) Public IP and you want to NAT something from that public IP back to the client LAN

- Port forward rule
- WAN rule automatically created by Port forward rule
- Then Outbound NAT rule on server side to remote LAN Alias/IP on WG interface

not sure if this is the correct way to do NAT over the tunnel but is working sharp

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

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.

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...

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 

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

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

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

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

After turning off openVPN I wold do a reboot of the OPNsense before trying wireguard...

I have rebooted both peers 20 times today...

this is my windows output

Do you see Routes in System: Routes: Status with the networks mentioned?

I have tried windows client just to try to troubleshoot and when I try to connect it says handshake failed, waiting for retry, so not sure if this is a bug with keys or something else, the tunnel seems up and traffic listed as passing but no routing, unless I failed miserably  in one of the steps I should be able to ping remote subnets or at lest the remote peer IP itself

Do you see Routes in System: Routes: Status with the networks mentioned?

yes on client I see the remote subnet and on server I see the client subnet

Also I have a any to any rule on the wireguard interface on both locations

Do your LAN rules on both sides allow traffic to the respective remote LANs?

I haven't touch the LAN interface rules, I have several OpenVPN working with no rules on LAN, whenever I try to reach remote OpenVPN subnets from LAN it just works, I understand wireguard works different than OpenVPN so I might need those rules specifically allowing ?

I have a rule that says From LAN goes everywhere so should work by default

Client:

Server