OPNsense Forum
English Forums => Development and Code Review => Topic started by: seitzbg on May 24, 2018, 07:54:08 pm
-
With the addition of Wireguard clients to freebsd ports, is it possible to get this added to Opnsense?
TIA,
https://svnweb.freebsd.org/ports?view=revision&revision=470763
https://svnweb.freebsd.org/ports?view=revision&revision=470762
-
This may provide a bit of context.... https://twitter.com/opnsense/status/999746722015469568 :D
Cheers,
Franco
-
Hello,
as the twitter post was nearly one month ago, I was wondering if there's already an ETA for the wireguard package?
Kind Regards,
JD
-
It's already there ...
pkg install wireguard
via CLI.
-
Ah, thanks a lot for pointing that out!
Couldn't find anything on the forum search nor in any of the latest release notes...
Cheers,
JD
-
Hi,
We don't do release notes for development changes. Wireguard is also still in alpha phase, so even if somebody writes a plugin it won't be in the release for as long as they say it shouldn't be used in production.
I also don't know what their ultimate time frame is.
Cheers,
Franco
-
Some news
https://www.phoronix.com/scan.php?page=news_item&px=Linus-Likes-WireGuard
-
Some more news:
https://github.com/opnsense/plugins/pull/779
-
how can i test it?
-
Via Console:
pkg install os-wireguard-devel
opnsense-patch -c plugins 202b7c9
Then you have Wireguard under VPN.
This guide will be released when the pkg is stable:
https://github.com/mimugmail/docs/blob/master/source/manual/how-tos/wireguard-s2s
-
Hey.
I just want to try this VPN but I have trouble during setup the tunnels.
Trying the docs from mimugmail.
Firewall rules are set on both WAN interfaces for the port 51820.
Firewall rules to allow all traffic in both directions on the interfaces for the test are enabled.
Site A:
Tunnel Address: 10.25.20.1/24
interface: wg0
public key: (hidden)
private key: (hidden)
listening port: 51820
peer: (hidden)
endpoint: <IP from Site B>:51820
allowed ips: 192.168.116.0/24, 192.168.117.0/24
latest handshake: 11 minutes, 37 seconds ago
transfer: 240 B received, 43.31 KiB sent
Site B:
Tunnel Address: 192.168.116.1/24
interface: wg0
public key: (hidden)
private key: (hidden)
listening port: 51820
peer: (hidden)
endpoint: <IP from Site A>:51820
allowed ips: 10.25.20.0/24
latest handshake: 9 minutes, 8 seconds ago
transfer: 29.53 KiB received, 2.59 KiB sent
PING test from Site A > Site B:
ping 192.168.116.10
PING 192.168.116.10 (192.168.116.10): 56 data bytes
^C
--- 192.168.116.10 ping statistics ---
334 packets transmitted, 0 packets received, 100.0% packet loss
Where is my problem?
-
I think you should have at least one tunnel network, where server is e.g. 10.12.12.1/24 and endpoint 10.12.12.2/24. the remote networks can be set in addition to route them
-
Hey.
I still have problems with testing wireguard.
I think the tunnel is up.
But no trafficflow > in the firewall logs: wg0 default deny rule
I'm confused. There is a new interface under assignments: wg0 with zero dotted MAC.
Is this right? What should I do with this interface?
-
Please dont assign it. Can you post screenshot of Server/Endpoints tab and firewall rules?
-
Hi.
Here are the screenshots:
Site-A:
https://ibb.co/kPWzv9 (https://ibb.co/kPWzv9)
https://ibb.co/hizKv9 (https://ibb.co/hizKv9)
firewall-rules:
Interface: https://ibb.co/n1tONp (https://ibb.co/n1tONp)
WAN: https://ibb.co/iKf3Np (https://ibb.co/iKf3Np)
Site-B:
https://ibb.co/jGrchp (https://ibb.co/jGrchp)
https://ibb.co/kv76a9 (https://ibb.co/kv76a9)
firewall-rules:
Interface: https://ibb.co/nuxiNp (https://ibb.co/nuxiNp)
WAN: https://ibb.co/cAv3Np (https://ibb.co/cAv3Np)
If I ping from Site-B to Site-A
I get this in firewall-logs on Site-A:
https://ibb.co/fo1A2p (https://ibb.co/fo1A2p)
-
Have you applied the single patch after installing the plugin?
It looks good, no idea why the packets get blocked ...
-
Yes, patch is applied.
-
Hm, I can only offer to have a look via Teamviewer since WireGuard is very new technology I'm not very experienced with it.
-
Took a stab at testing this tonight with somewhat mixed results, it looks like I get the tunnel up but can't get to the outside from LAN
My normal setup is a OpenVPN (client) connection to a VPN provider and all LAN traffic is routed through this (Outbound NAT rules). So I disabled the OpenVPN client & outbound NAT rules and added Google's DNS server instead of the VPN provider one. Also tested that everything still works at this point.
Installed Wireguard & the patch and proceeded with the Server/Endpoint setup -> Enable. I'm guessing this is the point when wg0.conf is created in /usr/local/etc/wireguard. I can generate a config file with the needed keypairs on the VPN providers website so went ahead and did that. Tested that the config works on my laptop before I copied the contents and pasted them into the .conf file.
[Interface]
PrivateKey = ########################################
Address = ip-supplied-by-vpn-provider/32,aaaa:bbbb:cccc:dddd::1234/128
DNS = vpn-provider-dns-address
[Peer]
PublicKey = ########################################
AllowedIPs = 0.0.0.0/0,::0/0
Endpoint = vpn-providers-server:51820
Added a firewall rule for port 51820 and restarted the Wireguard service, the interface came up and saw some outbound packets on the wg0 interface as well so I assume the tunnel is working, but couldn't reach any sites from the LAN side. Ping requests and trace routes all time out, ie. stop at the OPNsense box, but looking at the firewall log live view nothing is blocked. From what I read AllowedIPs = 0.0.0.0/0,::0/0 should allow any address, also tried with my local subnet but the result was the same.
In a desperate attempt to get it working I tried assigning wg0 to a new interface (although I read on the previous page it shouldn't be done) and replicated the outging NAT rules from my OpenVPN setup, but alas to no avail.
Any pointers what I should be looking at next in order to get it working?
-
I havent tested default route via WireGuad yet, I'll try to reproduce.
Assigning tun interfaces is a bit complicated but there is some progress in core right now.
-
I'm trying to test out WireGuard too.
I can't seem to get my setup to generate the keys. After saving I still get the results in the attached screenshot.
Any ideas what I'm missing?
-
Can you delete the instance and create a new one? This shouldn't happen at all ..
-
I've tried delete and recreate several times with no success.
Are there any logs or anything that might help?
-
Via console
clog /var/log/system.log
clog /var/log/configd.log
You can also PM me and I'll have a short look via Teamviewer
-
Uhm .. you are the guy with the broken configd daemon? I think your system has some more bigger problems and that's why it doesn't work
-
I am indeed that guy.
Getting the configd service to work seems to have fixed the WireGuard issue. I am getting keys generated just fine now.
-
Hi.
Here are the screenshots:
Site-A:
https://ibb.co/kPWzv9 (https://ibb.co/kPWzv9)
https://ibb.co/hizKv9 (https://ibb.co/hizKv9)
firewall-rules:
Interface: https://ibb.co/n1tONp (https://ibb.co/n1tONp)
WAN: https://ibb.co/iKf3Np (https://ibb.co/iKf3Np)
Site-B:
https://ibb.co/jGrchp (https://ibb.co/jGrchp)
https://ibb.co/kv76a9 (https://ibb.co/kv76a9)
firewall-rules:
Interface: https://ibb.co/nuxiNp (https://ibb.co/nuxiNp)
WAN: https://ibb.co/cAv3Np (https://ibb.co/cAv3Np)
If I ping from Site-B to Site-A
I get this in firewall-logs on Site-A:
https://ibb.co/fo1A2p (https://ibb.co/fo1A2p)
Ok, found the error, try to fix it the next days.
-
On Thursday hopefully we got also 0.3 devel where everything is fixed, also pushing default gateway via WireGuard works pretty fine.
-
Sounds great as I am also having issues connecting to the wireguard.com test connection and the azirev configurations. Also, please update the howto to include instructions on how to connect to VPN servers/providers.
Thanks
-
I have a connection to the Wireguard instance from Android.
No traffic is flowing and I also do not see a new interface in firewall rules for wireguard.
How can I get the traffic to flow and allow for access to my LAN over wireguard?
-
My theme was preventing me from seeing the Wireguard interface in Firewall rules. Switching back to the default theme made it visible.
-
AzireVPN Guide:
https://www.routerperformance.net/opnsense-wireguard-plugin-azirevpn/
-
I read through the howto and it references the wireguard 0.3 plugin. However, when I checked the version installed with pkg I see I am 0.1. Do you know when 0.3 will be available through pkg?
Thanks
-
When 18.7.2 is released, around Thursday
-
@mimugmail should I stop trying to get 0.1 to work? I can't figure it out and was wondering if it's a bug that will be fixed. I can ping the client from the server but not the other way around. The client is also not routing out to the internet. Afaik I have the firewall rules figured out yet the logs show DNS requests are being blocked by the default rule. I'd love a quick road warrior guide vs the S2S config.
-
Do you host WireGuard on your OPNsense and want to route your Android in your LAN, but not VPN as default gateway, right?
-
Do you host WireGuard on your OPNsense and want to route your Android in your LAN, but not VPN as default gateway, right?
I think so. My OPNsense box is 192.168.1.1 with all local machines on this same subnet, the tunnel address is 192.168.100.1 listening on 51820, and my phone is 192.168.100.2. I want to be able to access everything on the 192.168.1.0 network as well as get out to the internet through my home internet connection to bypass my mobile ISP (don't want split tunneling). I'm not sure what other addresses I should have added to the settings to enable this routing so I put 192.168.100.1/24 in the WireGuard tunnel address. In the endpoints I have my phone's public key and 192.168.100.2/24,192.168.1.0/24 as the addresses. On the phone's interface settings I have 192.168.100.2/24, 192.168.1.0/24. In the peer I have allowed IPs 0.0.0.0/0, ::/0. In my OPNsense NAT port forwarding I allowed any source to WAN Address on port 51820 to forward to 192.168.100.1. In my firewall rules on the WireGuard interface I put a rule to allow everything (necessary?). Do I need a rule on the LAN interface?
Right now I can't ping to or from the phone when connected but my firewall logs show everything on wg0 being blocked (ports 53, 443, etc) by the default deny rule. From the OPNsense shell I ran tcpdump -i wg0 and could see activity from my phone's 192.168.100.2 address so I'm thinking I just screwed up or omitted something from my firewall rules since it's showing up in the log as blocked. Would my WAN interface having "block private networks" enabled affect anything?
-
Best is to way until tomorrow, then you'll get 0.3 with 18.7.2.
In principle it's the same setup as https://www.routerperformance.net/opnsense-wireguard-plugin-azirevpn/ but you have to use your own keys.
-
Best is to way until tomorrow, then you'll get 0.3 with 18.7.2.
In principle it's the same setup as https://www.routerperformance.net/opnsense-wireguard-plugin-azirevpn/ but you have to use your own keys.
In that link it says to create an interface bound to wg0 but disable it and lock it. Should I do that?
-
No .. this is experimental .. a NAT on WireGuard group interface and translated address the tunnel address should be fine too
-
No .. this is experimental .. a NAT on WireGuard group interface and translated address the tunnel address should be fine too
Ok I'll wait until 0.3 if my settings look good to you I'll rule user-error out. Thanks for the help and work you are doing!
-
OPNsense as central breakout for Wireguard:
https://www.routerperformance.net/opnsense/opnsense-and-wireguard/
-
I tried to set up azire VPN using 0.3 of the wireguard plugin. the service starts and the tunnel address is assigned (not a single IP address) so I have nothing to ping and no traffic to monitor. What would you advise for next steps?
Thanks
-
Also, while the wireguard service was running the server tried to send all traffic through the wireguard tunnel (which did not have valid IP addresses set up). This forced me to stop the service while I conduct more research.
-
Can you try via console:
/usr/local/etc/rc.d/opnsense-wireguard restart
And post the output?
-
stopping wireguard
wg-quick: `wg0' is not a WireGuard interface
ifconfig: interface wg0 does not exist
starting wireguard
WARNING WARNING WARNING WARNING WARNING WARNING WARNING
W G
W This is alpha software. It will very likely not G
W do what it is supposed to do, and things may go G
W horribly wrong. You have been warned. Proceed G
W at your own risk. G
W G
WARNING WARNING WARNING WARNING WARNING WARNING WARNING
INFO: (wg0) 2018/09/09 14:03:29 Starting wireguard-go version 0.0.20180613
- wg setconf wg0 /tmp/tmp.AOoRwC3Z/sh-np.17Is8r
- ifconfig wg0 inet 10.10.16.138/19 10.10.16.138 alias
- ifconfig wg0 mtu 1420
- ifconfig wg0 up
- route -q -n add -inet 0.0.0.0/1 -interface wg0
- route -q -n add -inet 128.0.0.0/1 -interface wg0
- route -q -n add -inet 193.180.164.58 -gateway 192.168.1.1
- Backgrounding route monitor
and ifconfig output:
wg0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1420
options=80000<LINKSTATE>
inet 10.10.16.138 --> 10.10.16.138 netmask 0xffffe000
inet6 fe80::a00:27ff:fe75:c4f1%wg0 prefixlen 64 scopeid 0x6
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: tun wg
Opened by PID 59450
-
Are you sure you've manually imported the private key? With AzireVPN you have to use the private key they sent you.
-
I did a copy/paste from the configuration file they sent me yes.
-
I found and reviewed the wg0.conf file on my opnsense box with the azire conf file I downloaded. The only differences are:
No DNS field on OPNSense (not in the plugin)
Server listening port configured.
I suspect that the issue is that when I start the wireguard service locally because of the listening port opnsense is listening for an incoming connection from Azire. When I tried to remove the listening port, the plugin gave me an error. I can send you a copy of my wg0.conf and downloaded conf from azire (with keys removed) if you feel that would be useful.
Thanks
-
There were my settings:
https://www.routerperformance.net/opnsense-wireguard-plugin-azirevpn/
The only thing which could break things is when you have another PIA or OpenVPN based service also pushing you Default gateway.
When you insert the private key they sent you and the Tunnel Address there can't be something wrong.
-
Thank you. My next step is to turn on packet capturing on my test opnsense box and its gateway to see what is happening. I will keep you posted.
-
I just tried my AzireVPN tunnel from last week and it didn't work.
After some tests I switched to a different server (from SW to ES) and now it works.
Perhaps you just have to switch the server to a different location?
-
Updated to 18.7.3 and had a new go at getting Wireguard up 'n running with Mullvad VPN and I am glad to report that now it's working :)
To my knowledge I didn't do anything differently, so probably just a typo or something I made initially (deleted config, fw rules, gateway etc. before giving it a new go).
Anyway, works like a charm so many thanks for all the hard work.
-
Thanks for reporting back. Guys at Mullad gave me a test account .. I'll add a guide to the official documentation soon when other things are pulled.
-
i give it a try too, will do roadwarrior c2s-config for Windows, Linux and Android, if this is still needed.
-
You can try, but WireGuard port itself is a bit broken, when restarting the service the interface hangs. So ATM it only works after a reboot and you dont have to touch the config.
Still waiting for a fix ...
-
ouch....service restart is not enough? I got it somehow working on android, but usually a roadwarrior should get an ip from the server. With the actual config, it means, that each client has to have his unique combo Key/IP placed in Wireguard?
In some documentation i found, that you should not enter a public ip on the peer side, you only need the tunnel-adress (which means the client-IP in that case?
-
These are my writeups:
https://www.routerperformance.net/opnsense/opnsense-and-wireguard/
And:
https://github.com/opnsense/docs/pull/49/files
https://github.com/opnsense/docs/blob/master/source/manual/how-tos/wireguard-client.rst
https://github.com/opnsense/docs/blob/master/source/manual/how-tos/wireguard-s2s
-
Hi,
I was using the manual from you :)
You mentionned the outgoing NAT-Rule, which is correct. What i mean is missing is an incoming rule in your example on the WAN for Port 51820/UDP
It's been working fine with that, got it running on Android using the Wireguard-Client from Play Store. What if find a little bit painful:
1) is it really necessary to create an endpoint-entry for each connecting client?
--> not necessary!
2) i was trying to set no ip on the client-endpoint side of the opnsense, but you need to have one on the android-side, otherwise i got rejected.
--> If just setting tunnel ips on server and endpoint, you can use any ip in the ip-range of the tunnel-network
it seems, that wireguard is still under heavy development. What i feel is missing (or i even did not see it):
1) using DHCP for the internal network, so you don't have to issue an ip for each client and set one endpoint on the opnsense for all clients
2) an option to connect via user-credentials e.g. using radius or ldap in combination with the keys.
otherwise, it would be a relative "easy" setup. What i also saw, the Android-Client show connected, even if its not connected. The handshake-Tab showing the actual connections would be very helpful.
--> they are shown by tunnel, but not by connected client.
btw. i got back to production, letting the plugin on it. But this crashed my Firewall-Alias-Table *shudder*. My kids haven't been glad about that :)
-
1) is it really necessary to create an endpoint-entry for each connecting client?
--> not necessary!
Necessary, otherwise all would have same keys ..
1) using DHCP for the internal network, so you don't have to issue an ip for each client and set one endpoint on the opnsense for all clients
That's not the way it works ..
2) an option to connect via user-credentials e.g. using radius or ldap in combination with the keys.
Nope, will not come .. then it would just be a clone of OpenVPN :)
otherwise, it would be a relative "easy" setup. What i also saw, the Android-Client show connected, even if its not connected. The handshake-Tab showing the actual connections would be very helpful.
--> they are shown by tunnel, but not by connected client.
Most problematic with setup is exchanging keys, esp. on Android.
-
Necessary, otherwise all would have same keys ..
...which would make a per client-endpoint on the opnsense useless, as you could use the same for all?
1) using DHCP for the internal network, so you don't have to issue an ip for each client and set one endpoint on the opnsense for all clients
That's not the way it works ..
This would mean, it's not favourable for roadwarrior-setup in bigger environments, isn't it?
2) an option to connect via user-credentials e.g. using radius or ldap in combination with the keys.
Nope, will not come .. then it would just be a clone of OpenVPN :)
Good issue :)
the main goal of wireguard is i think s2s-vpn?
-
One good thing to add in the wireguard package would be adding a outbound-nat-rule in the firewall, when adding wireguard. Now you have to switch to hybrid and add it manually. openvpn adds this automatically.
-
Does this still work? I have updated to OPNsense 19.1.b_167 and don't have any luck adding an endpoint and connecting. Via CLI 'wg' shows nothing. Any help appreciated.
-
Sure it works, but the port itself crashes when restarting too often.
You can try to configure it without "Enable" ticked and after finishing enable, hoping it doesn't crash and never touch it :)
It takes some time to fix this upstream.
-
The WireGuard plugin is working great in on 18.7.9, thanks for this.
Would you consider adding an option to download a .conf file for each client/endpoint? Even more impressive would be to create a QR code as described here:
https://wiki.debian.org/Wireguard#A3
Any thoughts to add a widget to the dashboard, similar to the one for OpenVPN?
-
No, there are currently no plans for any of these, sorry. We'll have to wait until we can move the plugin to stable
-
Would you consider adding an option to download a .conf file for each client/endpoint? Even more impressive would be to create a QR code as described here:
https://wiki.debian.org/Wireguard#A3
If you have any Android devices, you can try setting up endpoint configs on the Wireguard app and then export the tunnel config to a zip to then pass to any other Android users you want to have them. I have no idea if those exported configs can be imported into other systems, but worth a go.
-
mimugmail, I hope you can help please. I have a fresh OPNsense install using 18.7.9 and am trying to setup Wireguard to connect to Mullvad and push all traffic through the tunnel. I have followed your Azire guide, substituting where needed for Mullvad's config, but I just cannot get it to work as expected. It seems that the system treats the Mullvad gateway as perpetually down, instead pushing all traffic to my WAN, and I cannot work out why. If I tick to skip rules when the gateway is down, I see only a wall of blocking in the firewall logs. If I leave it unticked, all traffic goes out via my raw WAN connection instead. I have tried various other guides too and none of them work.
Is it that something has changed or broken in 0.8_1 please, or am I doing something wrong? I have successfully setup WG connections from my Android devices back to my LAN with no issue, so I assumed this wouldn't be much harder, but it has me stumped so far. My final goal is to be able to have my external devices able to connect to my LAN and all traffic from my LAN and any connecting devices to go back out via Mullvad.
-
You tried this?
https://docs.opnsense.org/manual/how-tos/wireguard-client-mullvad.html
-
You tried this?
https://docs.opnsense.org/manual/how-tos/wireguard-client-mullvad.html
I have. It kind of works but not fully. I get a WG tunnel established, can see the handshake, and using Mullvad's tools as well as some third parties, I see a secure connection established to Mullvad with an IP I expect via them, no DNS leaks, no WebRTC leaks and IP not blacklisted. Everything appears secure and as desired. Firewall logs show lots of traffic passing outbound through wg2 rather than WAN, with a small amount of inbound traffic attempts via WAN and wg2 being denied. Mostly green and seems nothing out of the ordinary.
The issue I am having with this setup though is that while some websites and connections work perfectly, others are utterly inoperable or intermittent. Gmail is barely operable, locking up and if loaded various services such as Hangouts etc don't work as expected. They seem to allow outbound traffic as others receive my messages I post but I don't see anything from them. BBC News is completely inaccessible, as are a bunch of other sites, while others including this this forum respond perfectly (EDIT: Not perfectly, can login and read but unable to post till I disabled WG and returned to my WAN). Steam collapses as well, lets me startup and login but the store keeps failing and the friends service cannot connect.
I can ping sites that I cannot connect to, from my various network client devices on wired and wireless. I can also ping and resolve addresses within OPNsense but that I assume is down to the NAT rule for keeping localhost traffic out via WAN. However, I have found that even though I can ping the failing sites from my client devices, a traceroute fails to them as it hits Mullvad's WG exit node. I have tried GB1, 2 and 3, as well as one of their Swedish nodes. So, is this all working perfectly my end and actually some kind of Mullvad issue with their WG exits/DNS that only affects certain IPs?
-
I think I've worked it out. Have been scouring for info where others may be affected and found some comments by other Wireguard users regarding similar behaviour i.e. some sites working fine, others being intermittent, others inaccessible. It is the MTU and MSS settings, seems the packets flowing through WG are not happy at all about the default sizes and something is preventing the communication to resolve this. I have forced them manually to 1200 MTU and 1000 MSS, and suddenly everything went back to working, with all traffic flowing to Mullvad and out from there. I'll have to tinker to find where the cutoff point is.
I'm not sure if this is caused by something I've missed in the config somewhere. I've gone back to default setup and followed multiple guides, all of which have resulted in the same, so I assume either this just affects all WG, or all WG via Mullvad, or I'm setting/failing to set something which affects the MTU/MSS auto-discovery. If that's the case, please advise.
The only other issue I need to deal with now is that any changes to the firewall or interface settings drops the WG connection and it doesn't reconnect automatically, so all traffic starts going back through the WAN. Have to disable and re-enable WG to get it working again. I'm hoping that this fix may mean the system considers a gateway through my WG interface to be up now, so I can stick some stricter controls in.
EDIT: Further testing, and a setting of 1400 MTU/1360 MSS seems optimal. Anything higher causes my connection to start falling apart, with around a 50% reduction in download speeds, and intermittent behaviour by sites. Above 1440/1400 it becomes worse and 1460/1420 or higher is back to mostly unusable.
EDIT AGAIN: Steam remained unstable at 1400/1360. Dropping to 1380/1340 has resolved that as well.
-
Decided to try and sort the gateway tonight as well, and I have no idea what is going on with this.
Used your guide for reference, as well as the one on the OPNsense How To. Setup the gateway using the Wireguard interface. Amended my firewall rule to pass LAN traffic through the gateway only. Set a NAT for the Wireguard interface to the Mullvad IP assigned to me.
It all worked as expected. I thought I'd see what happened if I took the WG gateway offline, so I marked it as down. Traffic continued to pass through. I disabled the WG gateway, traffic continued to pass through. Check with Mullvad shows I am still secure through WG, as do third party sites, which confused me a little. Disabling WG itself finally causes traffic to shunt back through the WAN gateway, I assume as the auto rules kicked in to pass back to the default gateway. Setting this to skip the auto rules finally cuts off all traffic via the WAN as the firewall rules I have set still define to go via the WG gateway.
Re-enabling everything, traffic is still blocked from the WG gateway if the skip rules box is ticked. It seems that, with this enabled, the WG gateway is always considered down by the system even if I have ticked for that gateway to always be considered up. I don't think I've made any errors here, but please advise if I've missed something, or if this is known to currently not work. To confirm, I did try restarts and flushing states as well, but no effect on this.
-
Can you rephrase in one sentence what you want to achieve and then give some facts (IP's) etc. and screenshot of rules, outbound nat, wireguard config, assigned interface and gateway
-
Can you rephrase in one sentence what you want to achieve and then give some facts (IP's) etc. and screenshot of rules, outbound nat, wireguard config, assigned interface and gateway
Sorry, looking back at my posts, it is a lot of waffle. The result of coming off a long shift, dealing with kids then deciding it's a great idea to bash your tired head against a system into the early hours. I'll tidy up when I get home.
-
Can you rephrase in one sentence what you want to achieve and then give some facts (IP's) etc. and screenshot of rules, outbound nat, wireguard config, assigned interface and gateway
Desired setup: Wireguard connection between OPNsense and Mullvad through which all network traffic is transferred. Additionally, separate Wireguard connections between OPNsense and some roaming external devices i.e. Android phones, laptops etc, which should be able to connect to my internal LAN devices and to the internet via my Mullvad Wireguard connection.
I possess a static IPv4 address with my ISP, which simplifies my personal WG connection between external devices and my home network as no need to mess with dynamic IP services.
Following guides including those at https://www.routerperformance.net/ (https://www.routerperformance.net/) and https://wiki.opnsense.org/manual/howtos.html (https://wiki.opnsense.org/manual/howtos.html) I can get either my connection to Mullvad, or my personal connections from devices to my LAN, but I just can't seem to get both working at the same time. At this time, I have deleted all Rules and NAT relating to my personal WG->LAN connections as it had become a mess of testing and wasn't really helping
Additionally, with my Mullvad connection, my traffic seems to correctly go via the gateway I have set up for the interface, but if I go to Firewall->Advanced and tick "Skip rules when gateway is down" then all traffic is blocked. I'm not sure whether the gateway is working in the first place or if it is incorrectly believing the gateway is down.
Also, any changes to my interfaces result in my Mullvad WG connection dropping and not automatically re-establishing. I have to manually disable and enable WG to force a reconnection. Is this a known issue, or have I configured something incorrectly?
If you could advise me, I would really appreciate it. I'm probably going to wonder why I was such an idiot once you point out what I should have done.
LAN: 10.17.42.0
OPNSense: 10.17.42.1
WG personal inbound tunnel network: 10.17.50.1
WG personal inbound client: 10.17.50.2
Gateways
(https://i.ibb.co/wwSrPYd/1546798042.png) (https://ibb.co/WPkpMsH)
Interface Assignments
(https://i.ibb.co/YtjhMbr/1546798136.png) (https://ibb.co/dQKDq7h)
Firewall Rules: Categories (Any not displayed in detail are due to no rules set in the category)
(https://i.ibb.co/jgXg412/1546798289.png) (https://imgbb.com/)
Firewall Rules: Floating
(https://i.ibb.co/HTpv25j/1546798229.png) (https://ibb.co/9H3XvQ7)
Firewall Rules: WAN (IDNET)
(https://i.ibb.co/bv9pzzk/1546798248.png) (https://ibb.co/945Rss7)
Firewall Rules: LAN
(https://i.ibb.co/mzWCL8T/1546798259.png) (https://ibb.co/RHwpxyb)
NAT: Outbound
(https://i.ibb.co/q9R25Hk/1546798303.png) (https://ibb.co/S0KZrkR)
WG - Mullvad Local
(https://i.ibb.co/wRDx9Jz/1546798329.png) (https://ibb.co/37tLDfC)
WG - Mullvad Endpoint
(https://i.ibb.co/7SbbzJ2/1546798368.png) (https://ibb.co/hgCCMRD)
WG - Personal Inbound Local
(https://i.ibb.co/sbzMkQR/1546798341.png) (https://ibb.co/YPwqY8Q)
WG - Personal Inbound Endpoint
(https://i.ibb.co/NLpcVwV/1546798358.png) (https://ibb.co/Xzpc2m2)
-
Ok, I haven't tested such a setup, it might be possible.
At first, you need to add your tunnel network from wginbound to the outbound nat rule source network, as it includes only LAN and this doesn't match your wginbound.
Second, you should have a WGINBOUND rules tab, there you need a rules for allowing wginbound net to LAN (without gateway) and then a second rules with source wginbound and destination any, accept, gateway the mullvad gateway.
This should be enough.
-
Thank you for replying. It confuses me further though, as I believe I had those rules previously, without it working as expected. I've run a similar OpenVPN setup for years with many clients connecting and going out via a gateway to a VPN provider in the same way, and no issues.
I still have no connectivity from my external devices, including my mobile Android device, via WGINBOUND to my LAN or to the internet via MULLVAD. However, I have noticed that there is no handshake occurring between my mobile and WG on OPNsense.
If I deactivate my Mullvad WG and revert to my WAN then I can connect my mobile via WGINBOUND and I see a handshake, and can access my LAN and the internet through my WAN, with effectively the same rules used, just going back out via my raw WAN rather than Mullvad.
With the Mullvad rules active, if I disable the open port rule in IDNET then in my firewall logs there is a block event for an IP linked to my mobile provider with a destination of the port. If I enable the rule again, I see that traffic now passing and I would expect to see WG report a handshake but there is nothing. If I activate my wifi and connect locally, I immediately see a handshake and I can access LAN and Mullvad.
Here are my amended areas as you advised, please tell me if I have entered anything incorrectly here, or if I am missing something. Thank you again.
Firewall: NAT
(https://i.ibb.co/48M6F06/1546894015.png) (https://ibb.co/QPn2Jx2)
Firewall: WGINBOUND
(https://i.ibb.co/JmCNw72/1546894035.png) (https://ibb.co/Bcwm5Zj)
Firewall: IDNET (WAN)
(https://i.ibb.co/cJh8FKY/1546894050.png) (https://ibb.co/PxGWhsD)
-
Perhaps we can check with teamviewer when we hit a good timezone .. just come to irc and ping me
-
Perhaps we can check with teamviewer when we hit a good timezone .. just come to irc and ping me
Thank you, though no idea when that would be due to my shifts and delightful children .
I have been digging online and testing further though, and I think I may have a glimpse as to what it could be, though I'm still really unsure.
The Mullvad WG peer settings include 0.0.0.0/0, which I believe tells the system to push all packets through this WG tunnel. And I think this may be what is affecting the system, as it is forcing all other WG traffic down this tunnel regardless of my other firewall rules set in OPNsense. I'm seeing a lot of others having the same issue when running multiple interfaces with differing traffic routes. It seems that when one of the interfaces has 0.0.0.0/0 set, it pulls all the traffic into it. The solutions seem to usually be to exempt specific networks going into that WG tunnel, but I am struggling to understand the details for this. And I may have completely misunderstood it anyway.
Does this sound as if it could be a possible reason for the issue? I did test by setting my Mullvad peer address to something other than 0.0.0.0/0 and my Mullvad connection dropped, but my inbound connection immediately connected.
-
Ah, ok. That was the reason why I added a "Don't pull routes" checkbox :)
But then adding a gateway is much more tricky .. have to search the snipped I wrote.
Just try this feature and come back, until then I'll have certainly found the guide.
-
Ah, ok. That was the reason why I added a "Don't pull routes" checkbox :)
But then adding a gateway is much more tricky .. have to search the snipped I wrote.
Just try this feature and come back, until then I'll have certainly found the guide.
I've ticked the "Disable Routes" box in the WG Local setting for WGINBOUND and MULLVAD, which has resulted in a handshake for WGINBOUND and no handshake for MULLVAD but also no LAN or WAN connectivity for my mobile devices connecting via WGINBOUND. I have tried stripping my rules out entirely now and going back to a basic, as default setup, then building from scratch my WGINBOUND setup with the "Disable Routes" box ticked, and I still achieve a handshake but still no connectivity to LAN to WAN.
If you do have a guide that could help, I would really appreciate it. Though I'm beginning to think that I lack the capability to understand this at this time. I've had numerous and more complex OpenVPN connections similar to this running successfully for years, but for WG I'm at a bit of a loss, feel like a chimp poking around till something clicks.
-
Only Dont pull routes for mullvad. And then you need to add a Gateway for mullvad, then in LAN Tab an Accept Rule with Destination whatever to mullvad VPN, then perhaps a Rule on wginbound Rule Tab with wginbound net to LAN Just Accept and a second Rule wginbound to any and again Gateway mullvad.
For debug you have to tcpdump on all Interfaces to check ifcpacket leaves (correct Routing) and/or gets natted
-
Thanks for replying again. I've certainly got further. Everything is tweaked as per your comments and I have a WGINBOUND connection again. However no WG handshake with Mullvad. At least the rules are correctly stopping outbound traffic escaping via my raw WAN now, as that was an issue before too.
There must be some rule or option I'm missing which is needed for the WG handshake and which is automatically added by WG if I don't tick "disable routes". That seems to be the last piece I need and I'm hoping you know what it is please.
After all this, I think maybe I should write this up to help others doing the same, unless that's something you're already doing?
-
Still working at this, and I believe my issues have been due to a lack of knowledge about some fundamental networking. In the past, my mashed together setups seem to have worked due to luck and some auto rules from pfSense/OPNsense. However, in this setup, the auto rules for the routes set by the Wireguard config do not allow them to work in conjunction. I can have one running but not the other. And disabling auto rules for both stops both working.
I was struggling a bit to work out what the auto rules it sets are. It would be great if auto-defined rules could show up in the appropriate GUI window and list where they were set from. Anyway, I realised that my NAT outbound rules likely needed to be set to allow each of the parts to be able to talk i.e. LAN, WGINBOUND, MULLVAD and WAN. So I have tweaked my NAT outbound as below, and disabled the autorules in both WGINBOUND and MULLVAD WG configs. This immediately saw handshakes for both, which is the first time that has happened, though still no connectivity from my mobile to my LAN or MULLVAD, and my LAN also lost MULLVAD connectivity. I cannot ping either, so not just DNS.
Are these NAT rules correct for what I want? Is there more NAT needed? Do I need port forwards for any of this? And do my firewall rules need changing, or should they still be fine as posted earlier? Any further advice would be very appreciated, I think I'm close to sorting this.
(https://i.ibb.co/6XH9FNL/1547210679.png) (https://ibb.co/hYBQVCw)
-
I'm going through my routing tables to compare how they look when auto routes set to not set. At least I'm slowly learning some new concepts, probably should have done this a while ago. Still not sure what I need to set though, but I'm assuming it'll be one of those moments where I finally work it out and realise it's stupidly simple, if you know what it is in the first place.
EDIT: These are the additional routes I see if I have the Mullvad WG active and able to set routes itself. I assume these are what I need to add to make this work manually, but I am not sure how I go about doing that or if and how they need to be tweaked to work alongside my WGINBOUND setup.
The third one's destination is the public exit IP for Mullvad's GB3 WG exit, and the gateway is my ISP's.
Proto Destination Gateway Flags Use MTU Netif Netif (name)
ipv4 0.0.0.0/1 wg1 US 150 1412 wg1 MULLVADWG
ipv4 128.0.0.0/1 wg1 US 181 1412 wg1 MULLVADWG
ipv4 185.16.85.130 212.69.63.36 UGHS 141299 1492 pppoe0 IDNET
-
Actually, I think this is more a routing/rules issue than with WG. Is there a way to split my posts out into a new topic? Or can only an admin do that?
-
I finally managed it, but it is a Frankenstein's monster of a solution so far.
From my frantic reading and attempting to learn some more networking, I was under the impression that with static routes a packet would be sent to the one that most appropriately matches i.e. a packet for 8.8.8.8 would go through a route set to that IP, even if a route for 0.0.0.0/0 was before it. I've seen people confirming this with their own setups. But this has been confusing me, as my NAT and firewall rules appear correct and they work for both my outbound VPN provider and inbound remote client VPN just fine, I just can't get both tunnels up at the same time. If I change my outbound VPN to something other than 0.0.0.0/0 then my inbound VPN immediately establishes, but I lose my outbound VPN. I tried running without WG at all, then with each independently, then with both together, and examining the defined routes each time, especially the static routes WG established (they get set automatically in OPNsense). They seemed correct and, as each worked independently, I assumed should still work together. So I disabled OPNsense's auto-static route option and tried defining them manually myself. This still didn't work. I'm not sure if there's a difference in how WG interacts with static routes which is causing this.
So I went to an extreme solution. I copied every assigned /8 IPv4 address block from Wikipedia at https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks (https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks) into a spreadsheet. I first removed private address blocks 10.0.0.0/8, 172.0.0.0/8, 192.0.0.0/8, and my VPN provider endpoint which falls under 185.0.0.0/8, and added 127.0.0.0/8. I sorted them in order then wrote a formula to concatenate them all and separate with a comma. I copied this into the OPNsense config field so that they were recognised as individual address blocks. Saved and started up both WG tunnels. And both immediately established, with my LAN having internet access through the VPN provider as well as my mobile able to access my LAN and then from there the internet through the VPN provider.
It's a hell of a bodge. My states table looks like a crumbling ruin with 240 separate entries to cover nearly every /8 address block and it's not the quickest of systems, as I assume it's now having to parse all of that before each packet is routed, but it works. I don't know why the earlier attempts didn't. Perhaps it is an issue with OPNsense or its WG implementation in how the static routes and associated packets operate, or there's still some config nuance I haven't grasped, or something else entirely. I'm going to continue testing and try to work out what exactly is going on, as I don't feel this is a viable long-term solution and I'm hoping that at least knowing it can work will help something click in my head to get a proper config together. I've seen mention of fwmark and I think that may be what I am missing so far: a means to exclude certain packets from going into a WG tunnel, as that seems a cleaner way to do this rather than have to strictly define most of the internet to go through the tunnel. There's no exclusion option in the OPNsense GUI, so I'll have to try and see if this can be made to work manually on the CLI.
If I get it working without it being the abomination above, I'll let you know and get some screengrabs along with a clearer description.
-
Is there any more help you need in testing the WireGuard plugin to move it out of development?
I've just converted over my Mac to use Wireguard since the app was launched just recently.
I installed the plugin and basically setup the RoadWarrior setup and it's working well.
The directions for the "road warrior" setup seemed a little confusing but if I can get some time, I can do a PR to help clean that up.
Great work!
-
As long as this is not fixed, no chance:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233955
-
Hmm, that's an odd bug. I haven't noticed it yet on my setup as I've been running it, but I really don't play around with it too much other than letting it run at this point.
-
When you hit save on all tabs a couple of times you will also have spurious reboots ;) it's a bug in FreeBSD kernel
-
Hi everyone !
I'm having an issue with my Wireguard setup on Opnsense. I don't know if my setup is wrong or if there's a bug with the plugin...
I'm in 2 WANs configuration and i want two Wireguard sessions, one on each WAN interface. The problem is : packets received on WAN2 interfarce are redirected to the good WG interface, but return packet is sent from WAN1 interface.
This configuration works great with OpenVPN : one server listenning on Localhost, NAT forwarding from WAN1 and WAN2 to 127.0.0.1 on the OpenVPN port. If session is initiated from a peer on WAN2 interface, reply is sent from WAN2 interface.
But with Wireguard it does not work : with one WG instance, and NAT redirection to 127.0.0.1 on each WAN on the same port, the answer is ALWAYS sent from WAN1 interface. Witch two instance of WG, and a different port for each, it's the same. I also try to add floating rule, with no interface choice, and source port of my second WG instance, and tell to pass and use the WAN2 gateway, but it seems to have no effect on it.
I don't know if my explanation is clear, but I can add screenshots or packet captures if needed.
Thank you for your help :).
-
Post your entire configuration file, for each peer please! We'll get you sorted out.
-
Do you know why the docs say to switch to development?
https://wiki.opnsense.org/manual/how-tos/wireguard-client.html?highlight=wireguard
I just simply installed it via the cmd line and it seems to be working quite fine as I have Production selected.
-
At the time of writing it was a dependency.
-
Do you know why the docs say to switch to development?
https://wiki.opnsense.org/manual/how-tos/wireguard-client.html?highlight=wireguard
I just simply installed it via the cmd line and it seems to be working quite fine as I have Production selected.
The wiki refers to the GUI guided installation. The GUI guided plugin install is only implemented on the development branch as the plugin is under development (as stated in the wiki). This does not limit you from installing this plugin manually from CLI on production (under the assumption that you know what you know what you are doing), but may result in unwanted side-effects. I guess you can see it as a disclaimer of sorts I and a safeguard to prevent a layman to mess up his production install through GUI.
-
I think switching over to the development branch would produce a bit more unwanted things rather testing the plugin :)
-
Is it possible to use OSPF with Wireguard?
-
Haven't tested yet but, BGP should be OK, Multicast via OSPF could be tricky.
-
When you hit save on all tabs a couple of times you will also have spurious reboots ;) it's a bug in FreeBSD kernel
Do you (or someone) know what the roadmap is to get this fixed on freebsd side so we have some idea when wireguard on OPNsense will be stable?
thanks!
-
No roadmap, noone working on this actively
-
I've noticed one odd thing that seems to pop up. I have wireguard setup and in my local endpoint, I have DNS configured on OPT interface for my clients to hit 10.0.0.1 which is the proper interface I have setup.
I can see resolvconf overwrites my OPN /etc/resolv.conf with:
# Generated by resolvconf
nameserver 10.0.0.1
Am I doing something wrong or missing something obvious as that is what I thought that DNS config was for.
-
Where exactly is the problem?
-
My /etc/resolv.conf on my system gets overwritten:
root@phoenix:~ # cat /etc/resolv.conf
domain animosity.us
nameserver 127.0.0.1
by
# Generated by resolvconf
nameserver 10.0.0.1
So I'm trying to get why WireGuard is triggering resolvconf to update my local system as that's not the intent as I want my clients to use that IP for DNS and not my OPN box.
-
This happens when you set a DNS for Wireguard .. just leave it blank
-
So there isn’t a setting like in OpenVPN to push a DNS server? The way I read that as it was for that but your reply makes it seem like not the case. I didn’t infer from the description it would overwrite my system DNS but be interface specific like the OpenVPN client setting.
So I flipped that out of my config and just left the DNS in the client side config and everything is working perfectly at this point. Appreciate that as it was just causing some goofiness in terms of updating plugins and such as my DNS was pointing to that IP instead.
-
Wireguard works on system Level, it adds real IPs to Interfaces and changes also system DNS. Thats why the Code ist so small :) (with it's downsides)
-
Hi. I didn't read the whole thread ... so don't know if it's already listed here.
I tried to create two wireguard endpoints. The first one with 100.64.0.10/24 works but the second one with 100.64.0.11/24 only works when I choose the pub/priv keys of the first endpoint.
Moreover: When I clicked the "Save" button in the webUI the whole OPNSense VM crashed and rebooted. The warning "alpha software" is clear ... but is this already a known issue?
Thanks.
-
You should read more of the thread for your answer. :)
-
19.1.7 scheduled for tomorrow will include a fix which will Stop crashing the system ...
-
A workaround in the wireguard code anyway. ;)
-
Hey guys,
thanks for bringing wireguard to opnsense! Maybe my question will become obsolete since a fix that should stop crashing is apparently on its way:
Is the crashing only related to configuration tasks while setting up the tunnels / config or is the whole setup unstable while in use?
regards,
Darky
-
Hi Darky,
The bugs relate to two classes of FreeBSD kernel bugs that are prone to race conditions during interface reconfiguration which will throw a system panic.
Once the interfaces are successfully configured the tunnel is stable as far as I know.
Cheers,
Franco
-
Hello,
First, thanks for the work and effort of providing a wireguard plugin for OPNsense.
While testing it I stumbled upon a scenario which caused the vpn tunnel not to work. It may be a rare case, I don't know.
----------------- -------------------
| OPNsense Home | --------- | OPNsense Remote |
|---------------| |-----------------|
| - dynamic IP | | - fixed IP |
| - dual stack | | - dual stack |
----------------- -------------------
- OPNsense Home has dynamic dns domain with both A and AAAA records
- Remote Endpoint in OPNsense Remote is set to that above domain
- Both senses prefer IPv6 in general
- The transfer network and the networks to route are IPv4 networks
OPNsense Remote will query the domain, get the AAAA record and connect via IPv6.
But what, if I want to connect via IPv4 only, although IPv6 is available?
A checkbox that asks which protocol to use for the outer connection would be great.
-
On OPN with static IP I wouldn't configure an endpoint IP (0.0.0.0) and on OPN home use the v4 address as endpoint.
-
But that would mean, after some reconnect, the dynamic site must send some initial packages before connection is working on both sides.
-
And what exactly would you do?
-
Well, after thinking about it, everything is fine as it is.
I just thought about what would solve my "issue" the easiest way without taking into consideration if it is a reasonable solution.
As it turned out, I was also missing an allow rule for my wireguard port on OPNsense Home for IPv6. There is no real problem having the outer hosts connected via v6 and tunneling v4.
-
Good to hear, less work for me :)
-
I keep reading that wireguard is "so much easier to setup than openvpn"...yet I honestly don't think I've spent more time trying to get something working in opnsense longer than I've spent with this. Still not working! ::)
-
Everyone saying it's easier never did it on it's own ;)
-
Everyone saying it's easier never did it on it's own ;)
i finally got it working but was disappointed to find it was half the speed of openvpn via mullvad. i'll have to circle back to it later after further development.
-
Do you have correct MTU values? Perhaps you lower the MSS of LAN?
In my tests it was 5-10x faster, nearly IPSEC speed.
-
Do you have correct MTU values? Perhaps you lower the MSS of LAN?
In my tests it was 5-10x faster, nearly IPSEC speed.
No dice, unfortunately. I just tried scaling back MSS 1450, 1400, 1350 and it only had negative impact. Tried both the LAN and WG interfaces.
For tuning purposes I was using "ping -D -s 1450 -S <local wg ip> <mullvad wg endpoint>" from opnsense shell to find ballpark MSS. Let me know if you know of a better approach or know of a good MTU/MSS guide around these parts.
-
Whats your speed and Hardware?
-
Whats your speed and Hardware?
ISP is gigabit.
HW is Qotom-Q575G6-S05 (i7 7500U).
Direct connection (routed through OPN without VPN) yields ~700mb/s before OPN services kick in then it scales back to ~450mb/s.
OPN route through OpenVPN: 280 mb/s
OPN route through WG: 230 mb/s
-
Just wanted to say that I managed to get things working with Mullvad without any trouble.
Ran
pkg install os-wireguard-devel
and then followed the guide at https://wiki.opnsense.org/manual/how-tos/wireguard-client-mullvad.html.
My only comment on the guide is that the Mullvad Wireguard IP/port is not obvious from the server list at https://www.mullvad.net/en/servers/#wireguard. You can ping an host (e.g. au1-wireguard.mullvad.net) to get an IP. To get the port you can download a configuration file at https://mullvad.net/en/download/wireguard-config/ and in one of the files in the zip archive the host and port are listed for the server you chose.
Also, remember that Mullvad has discontinued free trial periods on new accounts.
-
Just wanted to say that I managed to get things working with Mullvad without any trouble.
What kind of speeds are you achieving relative to OVPN? I tested all endpoints in NAM and they all came up short of OVPN throughput.
-
i have now 2 roadwarriors connecting to my opnsense. On it, it looks like this:
interface: wg0
public key: wg0key=
private key: (hidden)
listening port: 51820
peer: client1key=
endpoint: ip:13595
allowed ips: 192.168.11.0/24
latest handshake: 25 seconds ago
transfer: 1011.63 KiB received, 4.03 MiB sent
peer: client2key=
endpoint: otherip:63680
allowed ips: (none)
latest handshake: 1 minute, 9 seconds ago
transfer: 0 B received, 3.03 KiB sent
why to heck do i get allowed ips (none)?
Client1 is working well, i copied the config from client2 and changed key and ip-adress, thats all.
wg0.conf on the sense looks like this:
[Interface]
Address = 192.168.11.1/24
ListenPort = 51820
PrivateKey = privatekey=
[Peer]
PublicKey = key=
AllowedIPs = 192.168.11.10/24
[Peer]
PublicKey = key=
AllowedIPs = 192.168.11.20/24
And a client-config looks like this:
[Interface]
PrivateKey = key=
Address = 192.168.11.20/24
DNS = 192.168.1.1
[Peer]
PublicKey = key=
AllowedIPs = 0.0.0.0/0
Endpoint = vpn.mydomain.com:51820
...i don't get it, why i can connect just with one client... :(
What WAS wrong:
in opnsense GUI use the allowed IP's with Netmask 32, not 24, as it should not overleap. I changed to 192.168.11.10/32 and 192.168.11.20/32 - works.
Devil is in detail...
-
Before i forget:
it would be great, to create an autorule in NAT for outbound connections. For the moment, i have it in hybrid mode, which would be unnecessary, if it would be there, when the services were activated.
-
I dont like auto rules as they tend to break complex setups, sorry.
-
That might be. I wouldn't do that also not by default, but as it is in Proxy, giving the option to let it be done. So it's the decision of the user.
In each case, it would it make much easier for SOHO-Users, which are not that experienced.
-
Congrats to today's golive as 1.0 in 19.7.
Roger
-
Is there a migration from the package to the plugin? Don't want to just pull the trigger and break it...
-
Nope, sorry
-
I've not been able to keep this stable. Sometimes works sometimes doesn't. If I apply in Nat Rules that will break it and I have to go back and load an older config again.
Does everyone using it have two wireguard entries in the firewall rules. I think this might be what is doing it and can find no way to remove the auto added one.
-
If you enable WireGuard you will automatically have WireGuard in Rules. If you assign an Interface to it and name it WireGuard you will have two. If you assign, only use the assigned one and name it "WG" or something.
-
I did try that but could never re-establish a link once I had named the interface. I even tried going back to a before config and working my way back, and that failed at the same point. It has been getting just a little frustrating ;-)
I will go again and try to keep it all straight and see if I can get it working. When it DID work it was really good. It was just also really fleeting :-(
-
Sadly WireGuard has Bad logging, No fun to troubleshoot
-
@tre4bax: i use only the default interface, which is made by the service itself. On it, have a rule, allowing all traffic.
Important: In NAT, you will have to change on hybrid, as you will have to nat also outgoing traffic, if using nat. You will have to enter a manual rule for your wireguard network there.
If you assigned wireguard to a separate network-interface, i am not sure, if this works properly.
-
Holla!
A workaround is to use a server inside your network wich NATs incoming traffic to gateway then out to internet.
i got a wireguard-server on my LAN wich runs dietpiVM (80mb ram usage) i have forwarded the listening-port to the router wich routes all traffic thru mullvad (wich means that i have to portforward again in mullvads webinterface).
So i connect to the mullvad public ip + port to access my wireguardserver wich then routes it to the internet (via same mullvad tunnel).
result: I can access my home network + internet thru a secure tunnel + bonus using a piholeVM to block ads over tunnel aswell.
its not perfect but it works and its stable, i havent done any speedtests but havent noticed any latencies in real day to day using.
Hope this helps
-
I wonder if this is going to get easier now that Linus announced it's going to be included in the kernel.
-
No, since the protocol itself didnt change.
-
BTW the devices from GL-iNet (such as the GL-AR750s) have a very nice GUI to wireguard server and to manage clients :).