Messages

Hi,

Same here: upgraded OpnSense this afternoon, Wireguard stopped working. The remote peer and the local instance agree on handshake time, TX and RX traffic count (which stay low, i.e. no actual data traffic).

Wireguard is configured to use "wg0" which is assigned "OPT4". It does not seem wrong, does it?

Looking at the Firewall live view, it seems that all traffic is now blocked by the "Block all WireGuard" rule which is part of Rules "WireGuard (Group)".

I do not remember seeing these Rules group name before, has it been renamed from another Wireguard rule? It has been far too long since I configured WG on this firewall. There is "WgVPN" rule group that I remember configuring to enable specific rules for specific device.

However, I do not remember modifying the previous rule group which is now named "WireGuard (Group)". What should be the rules here?


Thanks.

Ok, I reinstalled it from scratch, using the backed up configuration file (very nice feature).

Thanks.
I guess I missing a step, since I get "Mirror Read Failed", likely no IP address?

Very same issue here, while upgrading from 24.7 to 25.1

Hi,

I'm using Let's Encrypt to install a certificate for the HTTPS connection to the OpnSense webui.
From what I understand, the "Restart OPNsense Web UI" (enabled) automation is supposed to restart the web server once the new certificate is successfully installed, so that the HTTPS resumes with the new certificate.

It does not happen on my opnsense firewall. The Web UI keeps using the old, now expired, certificate. Forcing a manual execution of this automation does not help. Is there a way to restart the web UI w/o rebooting the whole system? How can I troubleshoot this issue?

I logged in with an ssh session on the firewall and run:

Code Select Expand


$ sudo /usr/local/etc/rc.restart_webgui
Password:
Starting web GUI...done.
Generating RRD graphs...done.


but again, the web UI did not restart, and the expired certificate is still used.

Thanks

Hi,

Is there any guide to set up an LTE fallback gateway using a cheap Huawei USB modem key (12d1:1f01 Huawei Technologies Co., Ltd. E353/E3131)?

I've successfully switched it to NCM mode (12d1:155e) or ECM mode (12d1:14db), but I do not know what to do to move forward:

* in NCM mode, ue0 interface is successfully detected:
   
   ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
   ether 00:1e:10:1f:00:00
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   
   however I do not know how to configure such an interface with opnsense;

* in ECM mode, the network interface does not show up in opnsense UI (nor via CLI/SSH).

In this later mode, Linux automatically assigned a local IP to the interface from the integrated DHCP server on the USB modem key (192.168.8.0/24), but I did not find how to do something akin to Linux with opnsense/freebsd.

Thanks.

It seems the culprit was an invalid peer key entry.
Lack of log file is definitely an issue to solve this kind of error.


$ /usr/local/etc/rc.d/wireguard restart
wg-quick: `wg0' is not a WireGuard interface

• wireguard-go wg0
  INFO: (wg0) 2020/06/20 17:06:50 Starting wireguard-go version 0.0.20200320
  
• wg setconf wg0 /tmp/tmp.Hxs5bS6X/sh-np.sMewul
  Key is not the correct length or format: `6QxSgFJGyaSNT1deq0jM48bthCz0Vz04CdlWuGgwxgI'
  Configuration parsing error
  
• rm -f /var/run/wireguard/wg0.sock
  [/tt]
  
  I also discovered that at start up - I ended up plugging in a screen which I had not done for years - BSD or OpnSense gets mad about a corrupted tar file, and dumps thousands of the very same error line ("corrupted archive") before resuming the boot sequence. It does not seem to self heal, all boots show this madness. Maybe I should reinstall opnsense from scratch...

Sorry for some reason I did not get notified about your reply.

Everything is enabled - as it used to be before the update, that is:

https://<server>/ui/wireguard/general/index
  * General tab: Enable Wireguard is selected
  * Local tab: One configuration defined, also enabled (with all 4 defined peers selected)
  * Endpoints tab: 4 peers defined and enabled
  * List configuration: empty
  * Handshakes: always empty, it used to contain real handshake before the last update, when the peers were active

However, now that I have installed the new wireguard-go package, I can see on the dashboard page that this server cannot start - and I cannot get any log to know what's the problem.

If I log in the system using ssh and force run wireguard-go:


$ sudo ./usr/local/bin/wireguard-go -f wg0
INFO: (wg0) 2020/06/15 22:29:38 Starting wireguard-go version 0.0.20200320
INFO: (wg0) 2020/06/15 22:29:38 Device started
INFO: (wg0) 2020/06/15 22:29:38 UAPI listener started


the wireguard-go icon on the dashboard gets green light, and interface: wg0 appears in the list configuration tab. However, it does seem to make the WG VPN to work: no comm from client, no handshake reported in the dedicated tab.

I would have like uninstalling everything and reinstall Wireguard from scratch, but it seems it is not possible from the UI...

Hi,

What is the wireguard status with latest OpnSense release?
I'm using OPNsense 20.1.7-amd64

I've been using wireguard for a while (opnsense w/ macOS and iOS endpoints), and for some reason it seems it does not work anymore, although I cannot trace back when it actually stopped working, but I do not remember changing anything related to Wireguard or the FW rules.

I'm a bit lost about the packages for Wireguard. There are:

* os-wireguard   1.1
* wireguard   1.0.20200513
* wireguard-go   0.0.20200320

which one(s) is/are required ?

I think when I've initially setup wireguard and when it used to work, there was a < 1.0 release.
Maybe the config format has changed and I need to reinstall it from scratch?

Another question: where are the logs associated with Wireguard support?

The list configuration and handshake panes are empty. They were reporting some info when the setup used to work.
It seems Wireguard is more or less idle, but I really do not know where to look to get logs or debug info.

Thanks.

... seeems to be a serious glitch with the web interface, as once logged w/ ssh on the firewall:


$ sudo ps ax | grep iperf
5166  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 47228
6810  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 21620
10044  -  Is        0:00.01 daemon: /usr/local/opnsense/scripts/iperf/ruby_iperf.rb[31907] (daemon)
13766  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 49993
18040  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 56380
24861  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 18637
29671  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 46277
31907  -  I         0:16.21 /usr/local/bin/ruby /usr/local/opnsense/scripts/iperf/ruby_iperf.rb (ruby25)
34005  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 45323
41878  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 21219
42206  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 60840
49153  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 50122
55355  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 8534
56201  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 50059
57661  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 13506
67526  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 60716
70999  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 18412
73970  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 7686
74117  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 17445
79278  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 19337
85331  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 57130
89359  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 50095
91130  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 29445
91260  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 22068
93542  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 17365
96449  -  I         0:00.01 iperf3 -J -f M -V -s -1 -p 57864

I'm not sure to understand how it works.

"Create instance" did work once, I ran one single test from a remote client.
Since then, "Create instance" does nothing, and no error is reported, not even in the logs...

I'm also interested, as I'm having the same problem, and I would bet that never seen this before the last update.

I'm not sure how it was before the last update, but I'm sure there is something new (and worse): every time I apply (edit, add, delete, ...) a FW rule, the changes are actually committed, but my browser never recover: I have to stop the current request, and reload manually... I never noticed this issue before, but I'm not sure it is tied to a peculiar OpnSense release.

I just observed this one:


lo0      Aug 30 16:25:40   127.0.0.1:3493   127.0.0.1:9388   tcp   Default deny rule


lo0 is not a physical device, why would the localhost denied to talk to itself?

and looking back in history, there are much more similar issues on localhost...

Look for network loops or bad switches, sometimes a simple power cycle is enough.

There's only a single switch and one access point (with an embedded switch) on the LAN side.  I will try to remove each of them one after another thanks.

Am I right to assume that if a LAN packet is dropped and logged, the issue comes from the LAN and not another nework (WAN here)?

If not use sloppy pass rules in your LAN to avoid drops / logs associated with bad state packets.

I'm not sure to understand how to do that...?

Basically this is not a firewall problem [...]

Ok. Is there a way in the firewall to add more debug info about the reason for the rejection/drop?

Thanks,
Emmanuel.

I do not think it is related to IPv6, as log shows only IPv4 addresses. This is still a mystery for me...