Messages

UPDATE: I've no idea what happened again. Today I build another new AES-GCM-256 Roadwarrior Instance (on just another port) and everything worked fine / as it should. So - please forget everything after good morning. SOLVED

Greetings,
Udo

-------------------------------------------------------------------------------
Hi Folks,

I'm using a Roadwarrior Setup with OPNSense as OpenVPN Server since v 23.7 and never had a real issue - until today.
I connected as usual from Laptop to OPNSense via OpenVPN GUI (v 2.6.13) [connection establishment without any problems] but when using my RDP connection (Win 11 24H2 to Win 11 24H2) i was only possible to use for 10 seconds - then broke.

After shouting to Windows I get into the logfiles of OPNsense and saw, that "AEAD" decryption has trouble. Some research later I switched to ChaCha2o-Poly1305 on serverside, adapted this on client file and everything works fine again.

Maybe anybody "fixed" anything in OpenVPN / OpenSSL to "death"?

Best regards,
Udo

Yesterday I kicked "UBlock Origin" out of my Firefox Extension after reading about an issue another user had with UBlock Origin lite.
Today I updated to latest Version - 24.7.11 and everything is working fine now - at least it seems after some minutes of extensive testing.

Thx to Franco and Team - you did a great job and for me you delivered an early x-mas surprise.

@all: Pls try new Version and post your experience under this.

Greetings,
Udo

[usr/local/www/interfaces.php]

In my case the patch is a big step forward.
Just to tell everybody what this patch actually is:

In usr/local/www/interfaces.php ...

--> line 586 should be commented out

Code Select Expand

/*plugins_configure('early');*/
--> line 587 should be inserted

Code Select Expand

configd_run('webgui restart 3', true);

After a reboot I got no issues after switching anything in Menu Section "INTERFACES" and "APPLY" anymore - WebGUI came back as expected.

I just had one time the issue that "Widgets failed to load" in dashboard came up; but after rebooting and trying again some weird things in GUI everything looked okay.

I recommend to have this changed "patched" Version in further Versions of OPNSENSE.

I want to say biggest "thank you" to Franco for his engagement. And I will have a look if my used "ESET INTERNET SECURITY" might have an impact due to "false driven" HTTP/HTTPS traffic inspection.

I'll test next days and keep you informed.

Cheers,
Udo

Thx for Glenn and Franco talking about the problem. Only by accepting a problem hope to fix it can be assumed.

@Franco:: If you wanna reproduce it - I'd like to send you my Fujitsu (you can keep it afterwards) so you can see I'm not telling a fairy tale. The fact I got this issue on 2 pieces of hardware (and being not alone in the world) tells one simple truth: There must be a problem somewhere in Code.

If Glenn is able to help - pls let him help.

Hi Franco,

I have no clue how to insert this code line cause I don't see any /src directory when using shell.
I help myself right now by killing lighttpd and reloading all services again.

For other who may have same issue and needs a step by step manual:

1. Open a ssh session
2. Insert "su" as first line and authorize with ROOT Password
3. Change to menu item 8) SHELL

Code Select Expand

0) Logout                              7) Ping host
  1) Assign interfaces                   8) Shell
  2) Set interface IP address            9) pfTop
  3) Reset the root password            10) Firewall log
  4) Reset to factory defaults          11) Reload all services
  5) Power off system                   12) Update from console
  6) Reboot system                      13) Restore a backup

Enter an option: 8

root@obelix:/home/udo #

Now find out how many lighttpd tasks your system has

Code Select Expand

root@obelix:/home/udo # ps aux | grep lighttpd
root    17036   0.0  0.1  22784  10068  -  S    18:05     0:00.35 /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd_w
root    31424   0.0  0.0  14448   4084  -  S    18:04     0:00.02 /usr/local/sbin/lighttpd -f /var/etc/lighttpd-acme-ch
root    48669   0.0  0.0  12716   2396  0  S+   18:18     0:00.00 grep lighttpd
root@obelix:/home/udo #

In this example I got 2 running services. When System stalls, it is is NOT the acme service, so have a look at the PID of the other one --> 17036

So - when system stalls after "Applying", just kill this "locked" task and everything is fine again.

Code Select Expand

root@obelix:/home/udo # kill 17036


Th variant for lazy Guys is more like a HAMMER Method, but same effective.
I know via PS-AUX that I have 2 lighttpd tasks. So what, if we kill all lighttpd tasks and reload all services again?

Code Select Expand

root@obelix:/home/udo # ps aux | grep lighttpd
root    95866   2.8  0.1  20220   9564  -  S    18:24     0:00.02 /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd_w
root    26470   1.3  0.0  14448   4088  -  S    18:24     0:00.00 /usr/local/sbin/lighttpd -f /var/etc/lighttpd-acme-ch
root    12748   0.0  0.0  12716   2392  0  S+   18:24     0:00.00 grep lighttpd
root@obelix:/home/udo # pkill lighttpd -f
root@obelix:/home/udo # pkill lighttpd -f
root@obelix:/home/udo # configctl service reload all
OK
root@obelix:/home/udo #

Sorry, but I am not a professional coder and getting the things work "somehow" is my intention.

But nevertheless - thanks tho all Folks working directly and indirectly on codebase and keeps IT a little safer for all of us.

cheers,
Udo

Okay - so in your case - the browser has an impact and everything else worked fine for you. That's weird but okay.

As I mentioned in the thread, my both Systems! I gave a try [with 24.7.x] behave the same: After Applying any switch action in INTERFACE SECTION you can see that save is done, but instead of "coming back after doing his things" the WebGui Server hangs up for 3-4 minutes.

In this state of lighttpd task being "locked" you can't even reset this task. I have two choices then: Wait for 3-4 minutes; somehow the task is then being killed automatically and comes back or killing the "stalled" lighttpd manually.

The Browser could not be an impact for me in this time.

as posted previously.  I am running a DEC 670 running the latest business release.
if I open a interface >  choose 1400 as MTU.   click save then APPLY>.  this immediately happens each time.

What happens immediately each time?
A System "Stall" for 3-4 minutes describes as in this thread?

I just tried this in Firefox ESR and it acts differently.    if I make the change and click save then Apply.   nothing happens.. I have to click Apply Twice for it to save.

What means "nothing happens"?
The system saves not? The system hangs? The system react like it should?

Could you give an information which describes your experiences clearly?

Last post from me on this topic, cause it seems that only very few hardware items got this "weird" behaviour.

So I have to live with it, that after "Applying" on any INTERFACE made GUI action the System's GUI hang up for a several time.

This leads to my question: Is it okay, when I make x-Switch Actions on several Interfaces and click only ONE TIME the "APPLY" Button at the end? 
Or is it better to klick on APPLY each time before leaving any Interface?

I can live with one time waiting 4 minutes before re-entering GUI; but x-time Waiting for 4 minutes is really not good for my heart due too much coffee pauses  ::)

Okay... I see.
Thx for your try.

cheers,
Udo

Hello Cedrik,

I tried already and - bad news - When disconnect WAN - nothing happens regarding this issse.
Second - directly plugin of LAN had no impact, too.

It keeps on being "weird".

Btw: Patched up to today's latest version (24.7.9_1) and (as expected) nothing changes - issue is same.

Ich möchte noch ergänzen: Mit Hilfe eines Drittdienstes - IPV64.net - kann man sehr einfach eine DynDNS v6 Domäne einrichten, über die dann im Zusammenspiel DG / AVM das Heimnetz quasi immer per Domäneingabe erreichbar ist. Voraussetzung ist dabei immer, dass der Roadwarrior im Einwahlnetz ebenfalls ein IPv6 Netz zur Verfügung stehen hat.

Ich selbst nutze zu 99% mein Mobiltelefon als Hotspot (D1 Netz (Telekom)) und habe keine Probleme, so mit meinem Laptop vie Aufruf der IPV64 Domäne aufs Heimnetz zu kommen.

Der Betreiber hat exakte Anleitungen für diverse Router (u.a. auch AVM und OPNsense) bereitgestellt.

Ich persönlich komme so problemlos per UDP auf meine OPNsense / interne LAN via OpenVPN; könnte so aber jeden beliebigen Serverdienst anbieten.

Falls da näheres Interesse herrscht über das genaue "doing" - kann ich gerne helfen.

Cheers,
Udo

Okay - got the point.
I'll give report on thursday. Thx in advance for your support.

cheers,
udo

I hardly can use a Firewall with WAN disconnected and an unbroken, unmanaged Layer 2 Switch can't be a factor.

As I said - when the lighttpd task is killed manually the WebGui pop ups directly again of the former struggled system.

But I can find out on thursday what you proposed.
Do you have a "special idea" by asking this for?
How does your System behaves?

Hello Cedrik,

at first thanks for your reply and intention to look this up.

My setup is really simple basic: WAN put in em1; LAN in em0. LAN connected to a layer 2 switch - pc directly connected to this switch.

Installation of fresh 24.7 --> then update via console to 24.7.8.
After reboot login as root (WEB GUI)--> run initial setup.

Then act as you want to do anything on WAN interface - like OPT IN "Prevent Interface Removal" --> Save --> APPLY

This "Apply" leads on my 2 Systems (HUNSN / FUJITSU) to the above mentioned system stall.
Its very interesting how your system react and if it the same, what might be the problem.

Cheers,
Udo

Regarding bug-hunting: Isn't it helpful when developers know now that "killing" the lighttpd task manually (while system is in status "locked") brings the Web Gui instantly back to live ?

Pls have a look @ my posting from 18th Nov 03:28pm.

Is this problem taken seriously?
I hope so.

However - thank's in advance @Franco and Team!!!