Messages

1

21.7 Legacy Series / Restarting UI after certificate update

« on: January 18, 2022, 08:31:53 am »

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]

$ 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

2

20.7 Legacy Series / Huawei modem in NCM mode

« on: November 11, 2020, 02:52:09 pm »

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.

3

General Discussion / Re: Wireguard status

« on: June 20, 2020, 05:12:39 pm »

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...

4

General Discussion / Re: Wireguard status

« on: June 15, 2020, 10:37:31 pm »

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...

5

General Discussion / Wireguard status

« on: June 08, 2020, 11:01:30 pm »

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.

6

Hardware and Performance / Re: Speed test plugin

« on: October 16, 2019, 06:07:18 pm »

... 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

7

Hardware and Performance / Re: Speed test plugin

« on: October 16, 2019, 06:02:18 pm »

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...

8

19.7 Legacy Series / Re: Default deny rule question

« on: August 30, 2019, 04:37:34 pm »

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.

9

19.7 Legacy Series / Re: Default deny rule question

« on: August 30, 2019, 04:28:36 pm »

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...

10

19.7 Legacy Series / Re: Default deny rule question

« on: August 30, 2019, 04:15:49 pm »

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.

11

19.7 Legacy Series / Re: Default deny rule question

« on: August 30, 2019, 12:09:08 pm »

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

12

19.7 Legacy Series / Re: Default deny rule question

« on: August 29, 2019, 11:26:43 am »

TCP flags on LAN net rules are all deselected.

I do not know how to get the one from the generated rules, as there is no "edit" button... :-(

13

19.7 Legacy Series / Default deny rule question

« on: August 29, 2019, 11:07:22 am »

Hi,

I was looking at the firewall logs, and there are not deny packets I fail to understand, e.g.:


    LAN      Aug 29 10:48:09   192.168.83.173:50928   17.252.76.99:5223   tcp   Default deny rule


192.168.83.0/24 is my LAN, the WAN net is 192.168.29.0/24
If I get it right, the deny comes from the floating, automatically generated rules, that applies if no other rule match.


    IPv4+6 *   *   *   *   *   *   *   Default deny rule  (last match)


However, one of the (default) LAN rules is:


    IPv4 *   LAN net   *   *   *   *   *   Default allow LAN to any rule  (first match)


Devices on LAN seems to be able to access the Internet (through the WAN). I'm posting this very message from this configuration.

Why could cause the "Default deny rule" to apply on these packets and how to troubleshoot this issue?
I do not get why these packets seem to be blocked and I'm still able to access the Internet... Do I misinterpret these log entries?

Thanks.

14

General Discussion / Re: Did 19.1.7 break NUT support?

« on: May 10, 2019, 11:10:22 pm »

I'd guess not every APC UPS supports the apcsmart driver. The whole nut-tools software is quite a mess, so I'd rather be happy if it just works

You were right. For some reason, both the USBHID and the APCSMART drivers got enabled.
Disabling the APCSMART driver and reloading the service just made it.

Thanks!

15

General Discussion / Re: Did 19.1.7 break NUT support?

« on: May 09, 2019, 11:20:39 am »

I don't think anything changed there for a while so it could be a local issue entirely. Do a health check from the firmware page to make sure that no files are damaged that would cause this.

I'm not actually sure how to do that. Is it the "System/Firmware/Reporter" page? It shows

   Luckily we have not detected a programming bug.

but if I click on "Report an issue", it shows

   Unfortunately we have detected at least one programming bug.

   Would you like to submit this crash report to the developers?

I'm not sure if it is a template message for reporting a bug, or if there is an actual issue here. I never been to this page before.