-
-
anav
Forum Guru
- Posts: 17447
- Joined: Sun Feb 18, 2018 11:28 pm
- Location: Nova Scotia, Canada
- Contact:
Re: Wireguard / Windows 11 client handshake for peer did not complete
Sun Jun 18, 2023 2:22 pm
In windows 11, check firewall or antivirus is not blocking.
Further ensure you didnt get Wireguard from Microsoft but got it from the wireguard site.
-
-
anticson
just joined
- Posts: 14
- Joined: Sat Feb 05, 2022 3:00 pm
Topic Author
Re: Wireguard / Windows 11 client handshake for peer did not complete
Sun Jun 18, 2023 2:33 pm
i disable bitdefender antivirus.
But i try with ios and i have tha same problem
-
-
anav
Forum Guru
- Posts: 17447
- Joined: Sun Feb 18, 2018 11:28 pm
- Location: Nova Scotia, Canada
- Contact:
Re: Wireguard / Windows 11 client handshake for peer did not complete
Sun Jun 18, 2023 4:42 pm
Then its your config!
/export file=anynameyouwish ( minus router serial #, any public WANIP information, keys etc )
Also you do have a public IP right?
-
-
anticson
just joined
- Posts: 14
- Joined: Sat Feb 05, 2022 3:00 pm
Topic Author
Re: Wireguard / Windows 11 client handshake for peer did not complete
Sun Jun 18, 2023 11:06 pm
No i dont have public ip
I enable ip cloup ddns from mikrotik
I attach you the config file
You do not have the required permissions to view the files attached to this post.
-
-
anav
Forum Guru
- Posts: 17447
- Joined: Sun Feb 18, 2018 11:28 pm
- Location: Nova Scotia, Canada
- Contact:
Re: Wireguard / Windows 11 client handshake for peer did not complete
Mon Jun 19, 2023 2:37 am
I think you meant I dont have a static IP. DDNS cloud is good if you have a dynamic IP.
If you dont get a public IP from your ISP provider this means that your mikrotik router gets a private IP from an upstream ISP router.
Typically in this case the ISP provides you with a combined modem/router which only provides you with a static LANIP behind their router.
In this case port forwarding and such things like WIREGUARD, are STILL POSSIBLe, assuming you have enough access on their modem router to at least forward ports to LANIPs.
IF so then you will need to forward the listening port to the WANIP they give to your router.
Please confirm if your MT device gets a public or private IP!
-
-
anticson
just joined
- Posts: 14
- Joined: Sat Feb 05, 2022 3:00 pm
Topic Author
Re: Wireguard / Windows 11 client handshake for peer did not complete
Mon Jun 19, 2023 7:43 am
I am sorry if I didn’t explain it exactly.
I have dynamic ip that’s the reason I enable DDNS cloud in MT.
And as you told MT gets private IP.
But I thought that with WireGuard I didn’t have to make changes like port forward in ISP router.
-
-
anav
Forum Guru
- Posts: 17447
- Joined: Sun Feb 18, 2018 11:28 pm
- Location: Nova Scotia, Canada
- Contact:
Re: Wireguard / Windows 11 client handshake for peer did not complete
Mon Jun 19, 2023 2:22 pm
Nope, its basic routing 101.
If you have an external user trying to reach the mikrotik, the IP Cloud URL of the mikrotik will resolve to the ISP public IP.
The user will reach the ISP router and since the router is not setup to accept the incoming port traffic it will get dropped ( there is no routing for this traffic ).
You will need to port forward on the main router to the WANIP of the MT router for that port.
If you are unable, then you wireguard is not possible but you could use zerotier instead.
Many times people rent a Server in the cloud to provide a connection point for the router and external users thus gaining access to the router.
-
-
anticson
just joined
- Posts: 14
- Joined: Sat Feb 05, 2022 3:00 pm
Topic Author
Re: Wireguard / Windows 11 client handshake for peer did not complete
Tue Jun 20, 2023 3:51 pm
The ISP router gives to MT 192.168.0.34.
So i must port forward to WANIP (192.168.0.34) of the MT router for the listen port (default 13231)
-
-
anav
Forum Guru
- Posts: 17447
- Joined: Sun Feb 18, 2018 11:28 pm
- Location: Nova Scotia, Canada
- Contact:
Re: Wireguard / Windows 11 client handshake for peer did not complete
Tue Jun 20, 2023 4:03 pm
1. On the ISP ROUTER, you must port forward the listening port 13231 to the WANIP of the mikrotik router 192.168.0.34 YES!
2. On the MT router you use the input chain rule to allow the incoming port 13231 with protocol udp
-
-
anticson
just joined
- Posts: 14
- Joined: Sat Feb 05, 2022 3:00 pm
Topic Author
Re: Wireguard / Windows 11 client handshake for peer did not complete
Tue Jun 20, 2023 6:08 pm
1.I port forward only 13231 didnt work.
So i port in ISP router i port forward all the port but still didnt work
2. In MT router i use input chain
(/ip firewall filter
add action=accept chain=input comment=»allow WireGuard» dst-port=13231 \
protocol=udp)
I attach the port forward and the config
You do not have the required permissions to view the files attached to this post.
-
-
anav
Forum Guru
- Posts: 17447
- Joined: Sun Feb 18, 2018 11:28 pm
- Location: Nova Scotia, Canada
- Contact:
Re: Wireguard / Windows 11 client handshake for peer did not complete
Tue Jun 20, 2023 9:02 pm
Please do not open all ports, only 13231, and ensure the protocol is UDP if there is a choice.
Lets look at the config!
(1) I see no real issues with your config.
You should be able to reach both the config and the subnet with those rules??
(2) Can you show me what your IP routes output looks like. ( just cover up anything related to your ISP modem/router public IP, although it probably wont show )
(3) Confirm you have not mixed up keys………
(4) Confirm you have keep alive set on peers
(5) Confirm you have 0.0.0.0/0 as allowed IPs on peers
-
-
anticson
just joined
- Posts: 14
- Joined: Sat Feb 05, 2022 3:00 pm
Topic Author
Re: Wireguard / Windows 11 client handshake for peer did not complete
Tue Jun 20, 2023 10:06 pm
I change and i put only 13231 port and udp protocol
1) i didnt understand what you mean reach each both the config and the subnet with those rules
2)i attach the file for the route
3)i though that it is ok and no mixed the keys
4)i have put 10 seconds keep alive
5)i Confirm you have 0.0.0.0/0 as allowed IPs on peers
6) i attach the log file of wizard, and i check when i activate the tunnel i didnt have neither wifi neither athernet.Like media disconnected
You do not have the required permissions to view the files attached to this post.
@angristan Here is what they say:
NAT and Firewall Traversal Persistence
By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it’s not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well. However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of «connections», if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don’t need this feature, don’t enable it. But if you’re behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the «connection» open in the eyes of NAT.
If you are using Starlink or any other ISP behind a CGNAT, I’d really think this option PersistentKeepalive = 25 is required, and the script shall offer the option during peer creation.
EDIT: anyway, I have issues, I’ll try without the script and do it with ArchWiki.
У меня есть сервер vpn wireguard который прекрасно работает. Я подключаюсь к нему из ubuntu 20.04 и со своего телефона на android. И там и там нет никаких проблем. Но есть проблема на windows 11. Там при подключении к впн просто пропадает интернет. Я пробовал скармливать те же самые конфиги что и ubuntu клиенту и андроид клиенту. Но оно не работает. Вообще никак. Так же я пробовал создавать нового юзера на сервере и скармливать его конфиг windows клиенту. Тоже не работает. Делаю ctrl+c ctrl+v Этого конфига на линукс и всё запускается с первой попытки. Из этого я сделал два вывода:
- Никаких проблем с сервером нет (иначе почему линукс и андроид клиенту отлично работают?)
- Никаких проблем с конфигом клиента так же нет. Потому что когда я скармливаю тот же самый конфиг линукс и андроид клиента то всё прекрасно работает.
Значит проблема исключительно с моим любимым майкрософтом и его виндой, у которого постоянно какие-то танцы с бубном. Конфиг который я вставляю в клиент:
[Interface]
PrivateKey = <private_key>
Address = 10.0.0.5/32
DNS = 8.8.8.8
[Peer]
PublicKey = <public_key>
AllowedIPs = 0.0.0.0/0
Endpoint = <server_ip>:51830
PersistentKeepalive = 20
Я пробовал отключать брандмауэр винды это никакого профита не принесло. Всё тоже самое. Антивирус только встроенный в винду. Его я тоже пробовал отключать тоже 0 профита. Так же эта проблема не связана с моим роутером. Т.к. линукс установлен на этом же компе и на этом же ssd диске, работает он так же через этот роутер и не имеет никаких проблем. Логи wireguard выглядят так:
2022-06-29 23:46:27.267: [TUN] [myvpn] Sending handshake initiation to peer 1 (<server_ip>:51830)
2022-06-29 23:46:32.428: [TUN] [myvpn] Handshake for peer 1 (<server_ip>:51830) did not complete after 5 seconds, retrying (try 2)
2022-06-29 23:46:32.428: [TUN] [myvpn] Sending handshake initiation to peer 1 (<server_ip>:51830)
2022-06-29 23:46:37.437: [TUN] [myvpn] Sending handshake initiation to peer 1 (<server_ip>:51830)
2022-06-29 23:46:42.515: [TUN] [myvpn] Handshake for peer 1 (<server_ip>:51830) did not complete after 5 seconds, retrying (try 2)
2022-06-29 23:46:42.515: [TUN] [myvpn] Sending handshake initiation to peer 1 (<server_ip>:51830)
При этом сам клиент пишет что всё ок и соединение активно. То что что-то не так становится понятно только по логам и по тому что нет интернета. В логах он жалуется что не получает ответа от сервера. Но я на 99% уверен что запросы клиента даже не доходят до сервера благодаря винде и где-то теряются во всяких брандмауэрах (хотя я его отключил, непонятно что ещё может быть). Так же заметил интересную особенность. После активации тоннеля адаптер создаётся, но там почему-то написано, что у него нет доступа к интернету.
Не знаю должно ли так быть в винде. Но это странно, ведь весь трафик после активации через этот адаптер отправляется. А как он отправится если у него нет доступа к инету?
route print выводит это (при включенном тоннеле):
C:\Windows\system32>route print
===========================================================================
Список интерфейсов
18...........................WireGuard Tunnel
10...40 b0 76 0d a7 4d ......Realtek PCIe GbE Family Controller
1...........................Software Loopback Interface 1
===========================================================================
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.69 35
0.0.0.0 128.0.0.0 On-link 10.0.0.5 5
10.0.0.5 255.255.255.255 On-link 10.0.0.5 261
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 10.0.0.5 261
128.0.0.0 128.0.0.0 On-link 10.0.0.5 5
192.168.0.0 255.255.255.0 On-link 192.168.0.69 291
192.168.0.69 255.255.255.255 On-link 192.168.0.69 291
192.168.0.255 255.255.255.255 On-link 192.168.0.69 291
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.0.69 291
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.0.69 291
===========================================================================
Постоянные маршруты:
Отсутствует
Hello,
I am failing to setup a WireGuard VPN tunnel on my OPNsense (v22.7.4 with «os-wireguard» plugin v1.12) and I begin to think multi-WAN configuration (load balancing, outbound rules, gateway groups, …) is causing issues.
I have, using the guide, already setup a «Road Warrior» WireGuard VPN server on another OPNsense box, but there was only a single WAN.
I’ve read (on this forum?) that WireGuard is not really (yet?) capable of multi-WAN, and I get it: But could I at least, get it to work over one of the WAN I have (without load balacing nor automatic failover)?
I am using the iOS client and logs shows:
Handshake did not complete after 5 seconds, retrying (try 3)
In the «VPN: WireGuard: List Configuration», the peer part does display «endpoint», «allowed ips» and some «transfer» values, but no «latest handshake» (which the «Handshakes» tab confirms: the timestamps for the peer is at «0»).
Here is what I want to have in the end:
- Allow an user to connect to my LAN network from outside Internet
- It does not need to access Internet via the VPN (he’ll use it’s ISP for that)
- Restrict it to a fixed local IP address
- Apply some restrictions to what local IP addresses it can access (eg. only allow access to a printer having IP 10.0.0.78/24 (I’ll try to set this up once I get the previous 3 points up and running)
Here is my setup:
(My LAN is on 10.0.0.0/24)
VPN: WireGuard:
* Local:
* Enabled: ☑
* Name: WG_VPN
* Public Key: Mo_d…Vb1p
* Listen Port: 51820
* Tunnel Port: 10.3.0.1/26
* Peers:
* user1
* Endpoint:
* Enabled: ☑
* Name: user1
* Public Key: Fx+p…Zw3d
* Shared Secret: (empty)
* Allowed IPs: 10.3.0.2/32
* Endpoint Address: (empty)
* Endpoint Port: (empty)
* Keepalive: (empty)
* List Configuration:
interface: wg1
public key: Mo_d…Vb1p
private key: (hidden)
listening port: 51820
peer: Fx+p…Zw3d
allowed ips: 10.3.0.2/32
Interfaces: [WG_VPN]:
* Enabled: ☑
* Lock: ☑
* Device: wg1
* IPv4 Configuration Type: None
* IPv6 Configuration Type: None
Firewall: NAT: Outbound:
* Mode: Hybrid outbound NAT rule generation
* Manual rules:
| Interface | Source | NAT Address | NAT Port |
| WAN_1 | 10.0.0.0/24 | Interface address | * |
| WAN_2 | 10.0.0.0/24 | Interface address | * |
Firewall: Rules: LAN:
| Source | Port | Destination | Port | Gateway | Description |
| 10.0.0.0/24 | * | 10.3.0.0/26 | * | * | Allow LAN clients to contact WG_VPN clients |
| 10.0.0.0/24 | * | 10.3.0.0/26 | * | GW_LoadBalancing | Set the gateway for LAN clients |
Firewall: Rules: WG_VPN:
| Source | Port | Destination | Port | Gateway | Description |
| * | * | * | * | * | Allow all WG_VPN clients to contact LAN clients (for now) |
I tried deleting all the WireGuard setup and starting fresh without much success.
Full logs from the iOS client:
[APP] startActivation: Entering (tunnel: MyCompany)
2022-10-03 17:22:06.517
[APP] startActivation: Starting tunnel
2022-10-03 17:22:06.518
[APP] startActivation: Success
2022-10-03 17:22:06.542
[APP] Tunnel ‘MyCompany’ connection status changed to ‘connecting’
2022-10-03 17:22:06.672
[NET] App version: 1.0.15 (26)
2022-10-03 17:22:06.673
[NET] Starting tunnel from the app
2022-10-03 17:22:06.756
[NET] DNS64: mapped 1.2.3.4 to itself.
2022-10-03 17:22:06.756
[NET] Attaching to interface
2022-10-03 17:22:06.757
[NET] UAPI: Updating private key
2022-10-03 17:22:06.757
[NET] Routine: decryption worker 1 — started
2022-10-03 17:22:06.757
[NET] Routine: event worker — started
2022-10-03 17:22:06.757
[NET] Routine: encryption worker 1 — started
2022-10-03 17:22:06.757
[NET] Routine: handshake worker 1 — started
2022-10-03 17:22:06.757
[NET] Routine: decryption worker 2 — started
2022-10-03 17:22:06.757
[NET] Routine: handshake worker 2 — started
2022-10-03 17:22:06.758
[NET] Routine: encryption worker 2 — started
2022-10-03 17:22:06.758
[NET] Routine: TUN reader — started
2022-10-03 17:22:06.759
[NET] UAPI: Removing all peers
2022-10-03 17:22:06.761
[NET] peer(Mo_d…Vb1p) — UAPI: Created
2022-10-03 17:22:06.763
[NET] peer(Mo_d…Vb1p) — UAPI: Updating endpoint
2022-10-03 17:22:06.765
[NET] peer(Mo_d…Vb1p) — UAPI: Updating persistent keepalive interval
2022-10-03 17:22:06.767
[NET] peer(Mo_d…Vb1p) — UAPI: Removing all allowedips
2022-10-03 17:22:06.769
[NET] peer(Mo_d…Vb1p) — UAPI: Adding allowedip
2022-10-03 17:22:06.771
[NET] UDP bind has been updated
2022-10-03 17:22:06.771
[NET] Routine: receive incoming v4 — started
2022-10-03 17:22:06.773
[NET] peer(Mo_d…Vb1p) — Starting
2022-10-03 17:22:06.773
[NET] Routine: receive incoming v6 — started
2022-10-03 17:22:06.775
[NET] peer(Mo_d…Vb1p) — Sending keepalive packet
2022-10-03 17:22:06.775
[NET] peer(Mo_d…Vb1p) — Routine: sequential sender — started
2022-10-03 17:22:06.775
[NET] peer(Mo_d…Vb1p) — Routine: sequential receiver — started
2022-10-03 17:22:06.777
[NET] peer(Mo_d…Vb1p) — Sending handshake initiation
2022-10-03 17:22:06.780
[NET] Interface state was Down, requested Up, now Up
2022-10-03 17:22:06.781
[NET] Device started
2022-10-03 17:22:06.783
[NET] Tunnel interface is utun2
2022-10-03 17:22:06.786
[APP] Tunnel ‘MyCompany’ connection status changed to ‘connected’
2022-10-03 17:22:06.787
[NET] Network change detected with satisfied route and interface order [pdp_ip0]
2022-10-03 17:22:06.788
[NET] DNS64: mapped 1.2.3.4 to itself.
2022-10-03 17:22:06.790
[NET] peer(Mo_d…Vb1p) — UAPI: Updating endpoint
2022-10-03 17:22:06.792
[NET] Routine: receive incoming v4 — stopped
2022-10-03 17:22:06.792
[NET] Routine: receive incoming v6 — stopped
2022-10-03 17:22:06.796
[NET] UDP bind has been updated
2022-10-03 17:22:06.796
[NET] Routine: receive incoming v6 — started
2022-10-03 17:22:06.796
[NET] Routine: receive incoming v4 — started
2022-10-03 17:22:07.044
[NET] Network change detected with satisfied route and interface order [pdp_ip0, utun2]
2022-10-03 17:22:07.045
[NET] DNS64: mapped 1.2.3.4 to itself.
2022-10-03 17:22:07.072
[NET] peer(Mo_d…Vb1p) — UAPI: Updating endpoint
2022-10-03 17:22:07.074
[NET] Routine: receive incoming v4 — stopped
2022-10-03 17:22:07.074
[NET] Routine: receive incoming v6 — stopped
2022-10-03 17:22:07.076
[NET] UDP bind has been updated
2022-10-03 17:22:07.078
[NET] Routine: receive incoming v6 — started
2022-10-03 17:22:07.078
[NET] Routine: receive incoming v4 — started
2022-10-03 17:22:11.509
[APP] Status update notification timeout for tunnel ‘MyCompany’. Tunnel status is now ‘connected’.
2022-10-03 17:22:12.044
[NET] peer(Mo_d…Vb1p) — Handshake did not complete after 5 seconds, retrying (try 2)
2022-10-03 17:22:12.045
[NET] peer(Mo_d…Vb1p) — Sending handshake initiation
2022-10-03 17:22:17.210
[NET] peer(Mo_d…Vb1p) — Handshake did not complete after 5 seconds, retrying (try 2)
2022-10-03 17:22:17.210
[NET] peer(Mo_d…Vb1p) — Sending handshake initiation
2022-10-03 17:22:22.497
[NET] peer(Mo_d…Vb1p) — Handshake did not complete after 5 seconds, retrying (try 2)
2022-10-03 17:22:22.497
[NET] peer(Mo_d…Vb1p) — Sending handshake initiation
2022-10-03 17:22:27.681
[NET] peer(Mo_d…Vb1p) — Handshake did not complete after 5 seconds, retrying (try 3)
2022-10-03 17:22:27.682
[NET] peer(Mo_d…Vb1p) — Sending handshake initiation
2022-10-03 17:22:32.936
[NET] peer(Mo_d…Vb1p) — Handshake did not complete after 5 seconds, retrying (try 4)
Loading