WireGuard site-to-site pfsense-to-pfsense no handshake?
-
Hi I was trying to set up a site-to-site pfsense-to-pfsense setup, but I can not get the pfsense to connect to each other
Tunnel - Site 1
Tunnel: tun_wg0 (Site 1)
Public key: PK1Peer - Site 1
Tunnel: tun_wg0 (Site 1)
Endpoint: Dynamic
Public Key: PK2Tunnel - Site 2
Tunnel: tun_wg0 (Site 2)
Public key: PK2Peer - Site 2
Tunnel: tun_wg0 (Site 2)
Endpoint: <Public IP of Site 1>
Public Key: PK1Site 2 never contacts site 1 to start a handsake, how do it get it to do that, how to a get the peer to work as a client, like server-client, what am I doing wrong?
(I have a firewall rule on site 1 to allow UDP traffic on the wiregard port on the WAN interface)
-
@mikki-10
did you assing interface ?? -
@mikki-10
create tunnel no ip
just port number desired
create your key's
saved !
go to interfaces add tun_wg0
now add static ipv4
set mtu to 1420
10.100.100.2/24
add gateway
10.100.100.1/24
repeat on other side
static ipv4
10.100.100.3/24
add gateway
10.100.100.1maybe this one need different (10.100.100.254/24)i used this setup 10.100.100.1 for gateway on both pfsense no issued yet
-
-
Now it works? (the handshake)
But why? -
I now have this setup
Tunnel - Site 1
Tunnel: tun_wg0 (Site 1)
Public key: PK1Peer - Site 1
Tunnel: tun_wg0 (Site 1)
Endpoint: Dynamic
Public Key: PK2Interface - Site 1
Description: WG
IPv4: Static IPv4
MTU: 1420
IPv4 Address: 192.168.77.2/24Gateway- Site 1
Interface: WG
Name: WG_Gateway
IPv4 Address: 192.168.77.1Tunnel - Site 2
Tunnel: tun_wg0 (Site 2)
Public key: PK2Peer - Site 2
Tunnel: tun_wg0 (Site 2)
Endpoint: <Public IP of Site 1>
Public Key: PK1Interface - Site 2
Description: WG
IPv4: Static IPv4
MTU: 1420
IPv4 Address: 192.168.77.3/24Gateway- Site 2
Interface: WG
Name: WG_Gateway
IPv4 Address: 192.168.77.1I now have a handshake with the above, but the gateways is offline, I do allow "any" traffic on the WG interface
-
of course the gateway is offline this ins’t real wan traffic ! it’s only wireguard traffic
just unchek monitor the gatheway
now here the thicky part
for subnet A to reach subnet B and virce versa you need to add a static routing
ex : on router A
you put subnet b and assing to gateway done before for wireguard and vice versahere i thing that painful right now ! if you restart wireguard service, static routing dissapear fron the route
you need to go back to stating routing and apply back
-
Why do the WireGuard not start a connection if the gateway is either not set or set to not to monitor, that is so odd. But I do understand the painful part.
but why do they not work more similar to a tunnel interface, where insted of setting a gateway that do not exist, why don't we use the opposite IP, site 1 used the IP from site 2 as gateway and so on, or just use an different monitor IP to keep it alive, so we also have ping stats do that work?
also ping (to and from site 1 and 2) do not seem to work after done the above.
-
if you go on github wireguard fron theonemcdonald issue #43 they are working on it. experimental don’t forget ! for the ping make sure your route are corresponding to your static routing ! cannot help anymore !
i have try also to set the gateway as the same ip
of the tunnel but the speed was 1/2 but it worked !so thing are broken on site to site
use openvpn for now ! work like a charm
i use openvpn site to multi site for 3 years never had an issue
-
Im want to kill my openVPN (Layer2 TAP) tunnels as they do not at all work like a charm for me at all, I have a lot of tunnels and some is just working and some are sometimes broken.
(Yes I know WG is Layer 3 tunnel)
-
@mikki-10
openvpn never gave me problem ! maybe you have someting misconfigure !but listen bro ! theonemcdonald is working hard to fix thing.
wireguard will live and rise but not yet :)
i do know that wireguard in pfsense 2.5.0
was working great for site to site but they kill it for reason ! so we will wait fow nowmaybe you should stop your openvpn instance for your testing purpose ! maybe you should do a backup and remove all openvpn ! i remember having issue when openvpn was there with wireguard site to site
-
Hi I know, I have followed he's youtube videos and github pagem, and wanted to jump head first when pfsense 2.5.2 was out, as the 2.5.0 WG just worked so well for me, and therefore hoped for the best, but I did not know how broken site-to-site was at this point, but I have not lost hope, and can't wait for the new WG to get better and more stable.
But thanks for your help so fare, I will see if I can get it working somehow.
-
@mikki-10
like i said do backup remove all vpn and start from scratch only wireguard!never know
anyway if problem just restore
have a good one
-
Hi I am on OPT18 as the next interface, not gonna happen over night, plus all the firewall rules, that is a big one
-
@mikki-10
i tested on 2 pfsense today with no ovpn
no problemive did the same procedure on pfsense main office with lot’s of ovpn nothing was going as expected so ! look like openvpn is messing some shit arround
-
There was a closed github issue like that but just with IPsec, same thing.
-
question your openvpn problematic
is it on the clients side ? if so just add
nobind in the *.ovpnnobind
that it
here’s the symptoms client connect but traffic is not goiing thru .
-
It is also site-to-site pfsense-to-pfsense, not sure if that will do anything for that.
And other clients eg windows or linux, work just fine, but again that is an other tunnel in this case, but thanks for the tip
-
@mikki-10
hahahaha
i did some more digging !
this is hilarious !
now my wireguard SITEA GATEWAY is the ip of SITEB
and my SITEB GATEWAY is the ip of SITEA !
when the handshake occur all gateway are online !! and ping goes on !absolutely ASOME OR RIDICULOUS
I PUT THE CONFIG BASE ON YOUR IPInterface - Site 1
Description: WG
IPv4: Static IPv4
MTU: 1420
IPv4 Address: 192.168.77.1/24Gateway- Site 1
Interface: WG
Name: WG_Gateway
IPv4 Address: 192.168.77.2/24Interface - Site 2
Description: WG
IPv4: Static IPv4
MTU: 1420
IPv4 Address: 192.168.77.2/24Gateway- Site 2
Interface: WG
Name: WG_Gateway
IPv4 Address: 192.168.77.1/24 -
@mikki-10
My SITEA -
-
Super nice, seems like we were able to help eachother out a bit then
I redid some of the steps, I now have one tunnel all working now!
-
Hello,
I also have the same problem, site to site impossible with Wireguard on pfsense in version 2.5.2.
You mentioned OpenVPN, Wireguard and IPSEC in the conversation, is your last messages for solving the problem about Wireguard? -
yes the problem is solve with wireguard just read the complete post
-
I have succeeded, in addition to adding the gateways on the interfaces, we must add the static routes.
If you follow the netgate documentation everything should be automatic :D ! -
already mentionned in that post
static routing is up there
just read carefully
every thing is there
-
Updated documentation is something we are working on
-
@yazur I will try to do my best to sum it up :)
- Create a tunnel, on Site 1 and Site 2, eg change the port number if you do not like the default value, generate the keys for the site, it follows the setup as below.
- Assign the interface (eg tun_wg0) and set a static IP, this is the tunnel network, set the MTU to 1420, see settings below, i use the subnet 192.168.77.0/24 in this exampel.
- Set a firewall rule (UDP) to allow traffic on the WAN interface to the Wireguard tunnel port. (eg UDP port 51820 to WAN address on the WAN interface) (And no it is not a NAT rule (Port forward))
- Set the needed firewall rules for WireGuard and the WireGuard interface WG
- Add the peers, on both sites, where the public key for the peer is the opposite sites public tunnel key. At least one of the peers shall have an endpoint, the opposite can be dynamic. So the site that have and public IP, can have its peers to be dynamic, we can call that site the server (the site with an public IP) and the other sites for clientes (those eg behind a CGNAT) if you like. Also add Allowed IPs here, you will need to add the LAN IP and the tunnel IP subnets
- Add the gateway, with the opposite sites tunnel IP.
- The gateway should come online at this point and the handshake should now be green-
- Now set the need static route on both sites
Tunnel - Site 1
Tunnel: tun_wg0 (Site 1)
Public key: PK1Peer - Site 1
Tunnel: tun_wg0 (Site 1)
Endpoint: Dynamic
Public Key: PK2
Allowed IPs: <LAN Subnet of Site 2>
Allowed IPs: 192.168.77.0/24Interface - Site 1
Description: WG
IPv4: Static IPv4
MTU: 1420
IPv4 Address: 192.168.77.1/24Gateway- Site 1
Interface: WG
Name: WG_Gateway
IPv4 Address: 192.168.77.2Tunnel - Site 2
Tunnel: tun_wg0 (Site 2)
Public key: PK2Peer - Site 2
Tunnel: tun_wg0 (Site 2)
Endpoint: <Public IP of Site 1>
Public Key: PK1
Allowed IPs: <LAN Subnet of Site 2>
Allowed IPs: 192.168.77.0/24Interface - Site 2
Description: WG
IPv4: Static IPv4
MTU: 1420
IPv4 Address: 192.168.77.2/24Gateway- Site 2
Interface: WG
Name: WG_Gateway
IPv4 Address: 192.168.77.1 -
@mikki-10 said in WireGuard site-to-site pfsense-to-pfsense no handshake?:
Peer - Site 2
Tunnel: tun_wg0 (Site 2)
Endpoint: <Public IP of Site 1>
Public Key: PK1
Allowed IPs: <LAN Subnet of Site 2>
Allowed IPs: 192.168.77.0/24I made a small mistanke, and can not edit my post?
Allowed IPs: <LAN Subnet of Site 2> should be <LAN Subnet of Site 1>Peer - Site 2
Tunnel: tun_wg0 (Site 2)
Endpoint: <Public IP of Site 1>
Public Key: PK1
Allowed IPs: <LAN Subnet of Site 1>
Allowed IPs: 192.168.77.0/24 -
wow your nice guys
every thing was already said in all the post for a pfsense user to do their jobs !
reposting all the procedure was kind of useless but friendly :)
have a nice one bro
-
Thank you for this summary!
I hope it helps other people too :)! -
That’s for the tutorial. I was following a German dude tutorial on YouTube and setting gateways for site 1 the site 1 ip and for site 2 the site 2 up. Result was losing handshake and pings after a few hours or randomly. Even with keep alive settings.
For now I reverted back to IPSec for site to site vpn as is more stable and easy to setup. Manual creation of static routes and gateways it’s as bit of pain if you’re on relatively big environment.
I know, I know… it’s experimental. Works great for mobile warriors though.
-
This was working fine on version 0.1.3. Updated to 0.1.5 and now I cannot access any of my peers subnet defined in static routing. I can ping from pfsense but pinging from any address on the lan subnet doesn’t work. Site one can’t ping site 2 and vice versa.
-
With hybrid nat the automatic nat rules for the WG interface look like a hot mess, especially if you have multiple interfaces. Anyone have examples of what it should look like?
-
What is your goal with the Outbound NAT change? It is not required for site-to-site.
If the goal is to change all traffic to the interface ip you can do that by setting to roules:
Interface: WG interface
Source: 127.0.0.0/8
Source port: *
Destination: * or what you need
Destination port: *
NAT Address WG address
NAT port: *
Static port: falseInterface: WG interface
Source: <Your LAN ip
Source port: *
Destination: * or what you need
Destination port: *
NAT Address WG address
NAT port: *
Static port: falseNot sure if this is what you are looking for?
-
After much hair pulling I finally made this work and stable.
You need to specify / create and assign he gateway to the WG Interface when you create it else you'll have or sort of routing issues
You also need to create static routes to the gateway with the subnets you want to access on the other side of the tunnel.Oh and the instructions above are wrong the Gateway ip needs to be the ip of tunnel on your side and not on the opposite side or it won't work.
Unfortunately then entire wireguard project seems to be quite secondary at this point for negate (they didn't even bothered updating the documents)... I know it's still experimental, but ok...
The developer is also never available never replies to anything in any of the platforms he mentions on his videos. He just ignores 99% of problems people are having (I hope they are not expecting us to start opening pointless stuff on redmi) -
Hi the use of the Gateway ip from the other side is not wrong, you do that with OpenVPN site to site as well when using layer 2 (TAP interface) and it give you the correct ping to the other side, and it helps keep the connection/session alive.
You do not need to do any NAT config if you follow the above.
Just remember to set the
MTU: 1420 and
MSS: 1420
That fix most problems. -
there is also a bug here that causes no handshake.
https://forum.netgate.com/topic/167279/wireguard-won-t-handshake-package-bug?_=1634581891833 -
This bug should be resolved in the latest version (0.1.5_2 and above). This package is available CE 2.5.2/2.6.0 and Plus 21.05.2/22.01. Give it a shot :)
-
@cmcdonald I don’t see any 0.1.5_2 update on my end