Messages

Any new info from the develpment team?  Or should I open an issue in  Github?

Still present on 18.1.8

Have solved this one.   With some more testing, I was able to isolate the problem to having my OpenVPN client active.  It would seem to be some sort of timing problem in resetting the interfaces while reloading the firewall rules.

The problem was eliminated by setting 'Disable State Killing on Gateway Failure' under Firewall>Settings>Advanced

Release 18.1.6 and 18.1.7

When trying to Apply firewall updates , the gui times out and fails with the following message

Secure Connection Failed

The connection to the server was reset while the page was loading.

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

That's using Firefox on Win7, but also receive a similar message from Chrome on Linux.,
If I reload the dashboard, then check the firewall rules, the update had actually been applied correctly.

Any ideas how to resolve?

EDIT: Solved....see last post.

Just a bump to add that I am also seeing the same or similar behavior.  No VLANs, running on WAN interface.
Originally posted in
https://forum.opnsense.org/index.php?topic=8527.0

Thanks for the pointer....my google-foo failed me (I do try and search before starting a new thread).

I'll follow the other thread.   Thanks again.

I had been running Suricata in IDS mode on the wan interface for several days without problems and things looked reasonable for the rules I had selected, so today I tried to enable IPS mode.   This killed my IPv6 connectivity.    It looks like IPS mode causes a restart of the wan interface.  From the syslog,

Apr 25 19:45:31   kernel: igb0: link state changed to DOWN
Apr 25 19:45:31   opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Apr 25 19:45:32   opnsense: /usr/local/etc/rc.newwanipv6: IP renewal is starting on 'igb0'
Apr 25 19:45:32   opnsense: /usr/local/etc/rc.newwanipv6: On (IP address: ) (interface: WAN[wan]) (real interface: igb0).
Apr 25 19:45:32   opnsense: /usr/local/etc/rc.newwanipv6: Failed to detect IP for WAN[wan]
Apr 25 19:45:32   opnsense: /usr/local/etc/rc.linkup: Clearing states to old gateway 68.xxx.xxx.xxx.
Apr 25 19:45:35   kernel: igb0: link state changed to UP

Not a lot of chance of a renew when the link is down.   In rc.newwanipv6 it defers the renew if booting.  Should similar logic be applied if the interface is down?

Just a wild guess, but I recently solved a VPN performance problem that was being caused by power saving options.   I was running with PowerD disabled, and it apparently limited the processor.   Changing to PowerD enabled with either Hiadaptive or Maximum mode fixed the problem.

Thanks for the clarification. Could be, but unsure where to look for further clues. AES-NI is quite elusive and questions tend to come in in waves.


Cheers,
Franco

Well, you are not going to believe this one.   After checking everything I could think of (the code was handling all the options correctly, the makefiles looked correct, etc), I thought could something be limiting the processor.   I was running with PowerD disabled.....I enabled HiAdaptive mode and miraculously the speed came up right in line with my pfSense measurements!  Not sure I understand, but I'll take it  :)

Agreed, always a bit of black magic involved.

I'm trying to sort through things as well.   It would seem that the aesni module doesn't need to be loaded unless the old-crypto option is selected, and that's what I'm seeing.  I haven't had the opportunity yet to trace what the RDRAND option is setting in the code.

Using AES-128-CBC, SHA1 for OpenVPN

Just to make sure we understand, the RDRAND option is making no difference in the results.   Same with turning off AES-NI in system settings.   Something is definitely broke.

BTW, pfSense shows the CPU crypto options in the dashboard, along with their state (active or inactive).   Would be a good addition to OPNSense.

Two options...None and RDRAND.   Tried both ways with no difference.   pfSense measures taken with it set to RDRAND.

Is there possibly something similar going on with OpenSSL.    I have a 100Mbps connection which benchmarks at about 120Mbps without OpenVPN active.

Turning on OpenVPN I get the following results with the same settings
- System HW crypto set to AES-NI
- OpenVPN HW crypto set to Intel RDRAND

pfSense (2.4.3): 100-110Mbps
OPNSense (18.1.6): 75-80Mbps

I see in the logs that my processor (N3700) is recognized as AES-NI capable.   Turning off the crypto options makes no difference on OPNSense, so it appears that the aesni acceleration isn't being used.

Are you all guys using aliases for local hostnames? Why? Why?

I prefer to use static IPs only for my network components (switches, APs, etc) and have all my clients get addresses via DHCP.

Then I add the appropriate local hostnames to an alias 'MEDIA_PLAYERS' for example, and write rules that restrict their access to only certain LAN clients (also an alias of local hostnames called 'MEDIA_SERVERS')

I may have something similar.  18.1.4 and possibly all of 18.1.x (didn't run too much on the earlier releases).

Have several alias's defined which reference local hostnames (have tried with and without domain)
These local clients are assigned addresses by DHCP (not static)
dnsmasq and unbound are configured to to register DCHP leases (I use both for various clients)

After rebooting, all the alias's defined with the local hostnames are not populated with ip's.   Pinging a client by hostname may cause the alias to be populated (haven't confirmed this is consistent yet).

Does anybody have the same behavior ? Or can i create a cron job for reset the unbound service again ?
Thanks for any hints  :)

Not sure if it's carried over to WIN10, but in previous versions windows nslookup was broken if the request came in via IPv6 (would work as you saw if you forced it to IPv4).   Do you have a linux box attached to try?