I just updated opnsense from 20.1.9 to 20.7.1.
Wireguard is not starting anymore.
If I try to start it 'by hand' with
wireguard-go /usr/local/etc/wireguard/wg0.conf
I can see:
INFO: (/usr/local/etc/wireguard/wg0.conf) 2020/08/29 21:30:04 Starting wireguard-go version 0.0.20200320
ERROR: (/usr/local/etc/wireguard/wg0.conf) 2020/08/29 21:30:04 Failed to create TUN device: interface name too long
Isn't the interface name wg0 ???
There is no wg0 interface available.
I tested also
wg-quick up /usr/local/etc/wireguard/wg0.conf
It shows no errors, but wireguard is not running.
Any ideas?
I found some entries in the 'general' log:
2020-08-29T22:00:15 kernel wg0: link state changed to DOWN
2020-08-29T22:00:15 kernel wg0: deletion failed: 3
2020-08-29T22:00:15 kernel tun0: changing name to 'wg0'
2020-08-29T22:00:15 kernel tun0: link state changed to UP
But nothing else.
Do you have it configured through the web gui, or manual config file editing?
On my end, it's working fine since 20.1.x, interface name still being wg0, but I think on upgrading I had to restart the box once or twice for wg to continue working.
Also, make sure that you don't have the wg0, or whatever it is on your end, interface assigned and activated in the web gui.
This somehow breaks the auto config that wg does.
AFAIK you can have it assigned in the interface assignment, you can even give it a name, but you can't activate it.
At least that's how it is for me.
I did the whole configuration via the web GUI already with 20.1.7
And it was working fine since this moment.
Only the update to 20.7.1 resuts in a non starting wireguard.
There is no 'own' intergface wg0 in the GUI.
Maybe try restarting the FW once or twice more, something changed with the interfaces on 20.7 which caused problems for my wireguard too, but restarting fixed the problem. And make sure you don't accidentally have the wireguard interface enabled.
Can you still list the wireguard configuration from the plugin page? What does it say? Is the config still intact?
I started it already several times via the dashboard.
I also enabled and disabled wireguard several times.
The configuration is shown correctly. (like in 20.1.7 ... 9)
There is no interface wg0 or any other from wireguard in the interface section.
To be clear I meant restarting the firewall as a whole, which you can't do through the dashboard, just FYI if you misunderstood me.
If nothing works, it might be the easiest to delete the config and reinstall wireguard TBH, which should hopefully work if nothing is borked beyond repair.
I can not reboot the firewall, it is not my own, it is from a company.
Also I think it's the wrong way to find the fault.
Because if a working configuration does not worl anymoe after an upgrade, something with the upgrade is not correct. You can not tell every opnsense user delete all your configurations and set it up from scratch.
That's not an upgrade, that's a new installation with a new configuration.
The goal is to make the upgrade seamless.
If this is not working, the fault has to be fixed.
But for that the fault has to be found.
So I will try now to get more/better error messages.
Btw. the above command to start wireguard manually was wrong.
I found now the right way:
wg-quick up /usr/local/etc/wireguard/wg0.conf
[#] wireguard-go wg0
INFO: (wg0) 2020/08/31 10:00:50 Starting wireguard-go version 0.0.20200320
[#] wg setconf wg0 /tmp/tmp.5I1EPWFN/sh-np.VQ8fnM
[#] ifconfig wg0 inet 10.10.254.252/24 10.10.254.252 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] route -q -n add -inet 10.10.254.8/32 -interface wg0
[#] route -q -n add -inet 10.10.254.46/32 -interface wg0
[#] route -q -n add -inet 10.10.254.45/32 -interface wg0
[#] route -q -n add -inet 10.10.254.4/32 -interface wg0
[#] route -q -n add -inet 10.10.254.3/32 -interface wg0
[#] route -q -n add -inet 10.10.254.2/32 -interface wg0
[#] route -q -n add -inet 10.10.254.1/32 -interface wg0
[#] route -q -n add -inet 192.168.18.0/24 -interface wg0
[#] rm -f /var/run/wireguard/wg0.sock
But there appears no error.
But I can also not see to which real interface this should be 'bind'
Btw. it is very interesting that the mtu is set to 1420.
Even if I enable advanced at 'Edit local configuration' the mtu field stays empty and as hint it is written that the mtu of the main interface is used, which is 1500.
I suggested a reboot because it fixed the issue for me, not because it is some kind of fix for a bug in the upgrade process, which is probably there since multiple users are affected.
If there is no possibility to reboot the system, good luck with future upgrades because I for one have experienced issues like this multiple times in the past, sometimes even after config changes w/o software upgrade.
Also, people on the forums are usually looking for ways to work around issues present on current versions, because the fixed version isn't out yet. That is why I suggested it.
Looking for the root cause might take you days/weeks and possibly require you to inspect the source code (while your production system is down).
On top of that, maybe the issue is not the main upgrade, but simultaneous upgrade of wg, in which case the core team wouldn't even be of much help probably.
BTW, MTU 1420 isn't surprising since wg has a protocol overhead of nearly 80 bytes worst case, so most ppl would just configure 1420, especially considering DSL PPPoE MTU of 1492
- route -q -n add -inet 192.168.18.0/24 -interface wg0
Let me guess .. this is your LAN?
Yes, that the LAN interface.
But in the configuration of wireguard, this addresses are only available as allowed ip address at the endpoints.
Not all networks allewd networks are visible as route.
And there is nothing changed at the configuration.
But I'll try now to change the order of the addresses, that always the 10... is the first allowed address.
Maybe it helps.
The order in the wg0.conf file changes nothing.
I also see no web gui field where it is possible to set the real interface.
Btw. I just switched to the slave OPNsense and rebootet the master:
Still the same: wireguard is not starting.
If I disable all endpoints in OPNsense, wireguard starts.
If I enable one enpoint with only the 10. address allowed, it also works.
But as expected, I can not access our LAN.
If I add the LAN address as allowed IP address, wireguard does not start anymore.
Quote from: ednt on August 31, 2020, 06:03:42 PM
Yes, that the LAN interface.
But in the configuration of wireguard, this addresses are only available as allowed ip address at the endpoints.
Not all networks allewd networks are visible as route.
And there is nothing changed at the configuration.
But I'll try now to change the order of the addresses, that always the 10... is the first allowed address.
Maybe it helps.
Why should WireGuard set a Route to your local LAN via WireGuard Interface? In which documentation did you read to put your local networl in endpoint section?
If I configure wireguard, I have nothing todo with routes. This is done by wireguard (or OPNsense).
As I understood wireguard, you have to add all IPs which should go through the tunnel to 'Allowed IPs'
Else you have only a connection between the tunnel IPs.
This is also written in the help to 'Allowed IPs':
QuoteList of addresses allowed to pass trough the tunnel adapter.
And I tested this already in 20.1.7, if I don't add the LAN IPs to the 'Allowed IPs', I can not communicate between any home PC and the company LAN.
And since this was working for over half a year, I think and thought that this is correct.
The only thing I did manually was to set outbound NAT rules.
Btw.: I also never created an interface for wireguard. If this is really needed, the configuration of the wireguard plugin should do this.
No, on your phone or PC you set the remote IPs in AllowedIP, on the Server, you configure an endpoint and ONLY the IP/32
Ok, wireguard is back to life.
Thank you for the clarification.
But the help text of 'Allowed IPs' should be changed.
To reflect what is to put inside if the connection is as server or as client.
Multiple addresses should be only allowed if an 'Endpoint address' is given which is not allowed to be an address of the OPNsense itself.
And it should be possible to enter an IP address at 'local' where the stuff is bind to.
So it would be possible to run it on Master/Slave OPNsense with CARP, if you enter the VIP address.
Currently it's: List of addresses allowed to pass trough the tunnel adapter. Please use CIDR notation like 10.0.0.1/24.
Maybe it could be: List of destinations allowed to pass trough the tunnel adapter. Please use CIDR notation like 10.0.0.1/32.