Messages

System: Settings: Logging -> "Log packets matched from the default * rules.."?

Hello and thanks for this answer which is a good suggestion. But in my case I would prefer to limit the size of
the /var/log/filter/ directory.
Is it possible?

Ooh I see! Thank you very much

So here is what I did:
- in Interfaces:WAN:
    - "Use VLAN priority" = "Internetwork Control (6)"
    - I removed "vlan-pcp 6" from the "Option Modifiers"

- in Interfaces:Other types:VLAN -> igb0_vlan832:
    - "VLAN priority" = "Best Effort (0, default)"

I'll report in ~24 hours

Hello, it's been a few days and I can report the above configuration works smoothly on 23.1.6! Thanks all for your great help!

Ooh I see! Thank you very much

So here is what I did:
- in Interfaces:WAN:
    - "Use VLAN priority" = "Internetwork Control (6)"
    - I removed "vlan-pcp 6" from the "Option Modifiers"

- in Interfaces:Other types:VLAN -> igb0_vlan832:
    - "VLAN priority" = "Best Effort (0, default)"

I'll report in ~24 hours

Hello Franco.

I upgraded to 23.1.6 but I am still facing the same problem unfortunately (it works for ~24H only)

- The release notes at https://forum.opnsense.org/index.php?topic=33643.0 mentions

Orange FR users be aware that your ISP now requires strict VLAN PCP on all DHCPv4 requests so please do set 'Use VLAN priority' interface setting for both DHCPv4 and DHCPv6.  The 'Option Modifiers' override for "vlan-pcp" in DHCPv4 can be removed and the documentation was updated accordingly.

- The documentation at https://docs.opnsense.org/manual/how-tos/orange_fr_fttp.html mentions

Some areas of France require that the DHCP and DHCP6 requests are made with a VLAN-PCP of 6. If you are in one of these regions then this can be done via 'Use VLAN priority' interface settings. Make sure to set this for both DHCP and DHCP6 at the same time.

I am a bit confused because the pictures in the documentation still show "vlan pcp 6" in the "Option Modifiers" and a pcp of "0" in VLAN priority

So where should I set the VLAN priority of 6 exactly? Note I use IPv4 only and I already tried to setup the VLAN priority as "Internetwork Control (6)" in "Interfaces:Other types:VLAN -> igb0_vlan832 -> VLAN priority" but the connection was much slower so I didn't let it run for ~24 hours

Hello,

I have the same problems and I have 2 routers so I can compare:
- everything works smoothly on OPNsense 22.7.11_1-amd64 with os-ddclient 1.9_2
- I get errors on OPNsense 23.1.6-amd64 with os-ddclient 1.12

Both are running the same config (only the hostnames change). The errors on the last version are:

Code Select Expand


FAILED:   updating mynamexxx.dnsalias.net: unexpected status (13)
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4122.
Use of uninitialized value $_[0] in sprintf at /usr/local/sbin/ddclient line 2179.
WARNING:  updating : nochg: No update required; unnecessary attempts to change to the current address are considered abusive
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4131.
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4132.
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4133.
Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 4122.
Use of uninitialized value $_[0] in sprintf at /usr/local/sbin/ddclient line 2179.
FAILED:   updating : unexpected status (0)
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
Use of uninitialized value in string ne at /usr/local/sbin/ddclient line 1172.
FAILED:    was not updated because protocol <undefined> is not supported.


The last version DOES UPDATE correctly on dyndns but it looks like it doesn't write the result correctly in /var/tmp/ddclient.cache so I imagine it's constantly updating... This is risky as dyndns could consider me as a spammer.

As a workaround, I disabled os-ddclient and I am using os-dyndns 1.27_3 [Dynamic DNS (legacy)]. I prefer dyndns anyway as I can also monitor a "WANGWGROUP" interface (multiwan), which is not possible with ddclient (see https://github.com/opnsense/plugins/issues/2899)

So if possible, please don't remove os-dyndns from future versions. I think it is especially important as the author of ddclient himself declared: "Lack of time and general interest in this project. I don't know the code anymore and can't really be a help in fixing this." (see https://github.com/ddclient/ddclient/issues/431#issuecomment-1424608301)

OK understood. I will update both my routers to 23.1.6 and I will report here

Hello Franco and thanks for your answer.

Do you mean 23.1.6 fixed this issue entirely? If not, I'd like to wait before upgrading because I have another opnsense router in another location and I will update both at the same time when I am ready (I like to keep both on same version)

So at the moment, I am still on 22.7.11_1 and I do have "vlan-pcp 6" in the "Option Modifiers" of the IPv4 WAN settings. All works flawlessly but only for ~24 hours (just like what skool described in his first post).

For a moment, I was wondering if you were talking about the setting in Interfaces -> Other types -> VLAN -> igb0_vlan832 -> VLAN priority. So I briefly set it to "Internetwork Control (6)" instead of "Best effort (0)" but the connection was much slower so I had to revert.

Regarding Skool's solution:

I confirm that adding a firewall rule to re-tag priority to 6 for DHCP packets (outgoing UDP packets to 67 and 546, ipv4 and ipv6) fix the issue.

It looks like an easy fix (in case 23.1.6 doesn't fix entirely) but I am not sure how to add this rule. Could you please explain how to add this firewall rule (via the GUI if possible, or via command line)?

Thanks for any help!

I confirm that adding a firewall rule to re-tag priority to 6 for DHCP packets (outgoing UDP packets to 67 and 546, ipv4 and ipv6) fix the issue.

As I read on other forum, it seems this problem is also present on Mikrotik equipment, that probably use the same dhclient app.

So the bug is that dhclient dont use vlan-pcp 6 when renewing a lease.
I dont know if someone is possible on opnsense side or if we need to check with dhclient team.

Hello all. I am on:
  OPNsense 22.7.11_1-amd64
  FreeBSD 13.1-RELEASE-p5
  OpenSSL 1.1.1s 1 Nov 2022

And I face the exact same issue: I need to reboot every day to get the Orange France connection to work again...
I am using IPv4 only (no IPv6). Could you please explain how to add this firewall rule (via the GUI if possible, or via command line)?
Thanks for any help!

Hello and thanks for your answers,

Show your Backup config please.

• Enable = ticked
• URL = https://192.168.8.13
• User Name = <username>
• Password = <app_generated_password_for_username>
• Encryption Password = blank
• Directory Name = opnsense_backup

Have you selected your NC IP address or FQND?

I have selected the IP (192.168.8.13) because my nextcloud is only accessible through LAN (not opened to the internet)

I was getting the same error and resolved it with following steps:
1. From profile icon (NextCloud account), under Security create an app specific password
2. In OPNSense add following items:
a. Enable backup under NextCloud
b. URL: https://nextcloud.willsisti.com  (mine is with linuxfabrik.io just in case you want to give it a try)
c. Username: your email for NC account
d. Password: generated in step 1)
e. Encryption: leave it blank for now but change it later
f. Directory name: leave blank for now to save at the root but you can change it later
3.Click on Setup/Test, and wait few seconds for backup to be created and uploaded to root directory of NC account

The above steps worked for me, hope it solves your problem.

I did exactly the same except I am using the IP of Nextcloud (it has no FQDN) and the Directory Name which can't be left blank (or it generates the error "The Backup Directory can only consist of alphanumeric characters, dash, underscores and slash. No leading or trailing slash.")

I am pretty sure this is a certificate issue. Again, my Nextcloud is not accessible from the internet so I am using self-signed certificate which was generated during installation of Nextcloud (not corresponding to a FQDN). I had no problem to import this certificate in Firefox or Thunderbird though...

Any clue?

Thanks for any help!

[with a self-signed certificate]

Hello,
I can't get the Nextcloud backup feature to work either :(

• version of Nextcloud = 20.0.1 (hanssonit appliance) with a self-signed certificate
• version of OPNsense = 21.1-amd64

The log is:

Code Select Expand

Mar 23 21:55:27 OPNsense config[93546]: {"url":"https:\/\/192.168.8.13\/ocs\/v1.php\/cloud\/user","content_type":null,"http_code":0,"header_size":0,"request_size":0,"filetime":-1,"ssl_verify_result":18,"redirect_count":0,"total_time":0.024741,"namelookup_time":6.6e-5,"connect_time":0.000522,"pretransfer_time":0,"size_upload":0,"size_download":0,"speed_download":0,"speed_upload":0,"download_content_length":-1,"upload_content_length":-1,"starttransfer_time":0,"redirect_time":0,"redirect_url":"","primary_ip":"192.168.8.13","certinfo":[],"primary_port":443,"local_ip":"192.168.8.1","local_port":62449,"http_version":0,"protocol":2,"ssl_verifyresult":0,"scheme":"HTTPS","appconnect_time_us":0,"connect_time_us":522,"namelookup_time_us":66,"pretransfer_time_us":0,"redirect_time_us":0,"starttransfer_time_us":0,"total_time_us":24741}

based on https://www.openssl.org/docs/man1.0.2/man1/verify.html "ssl_verify_result":18 means "X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: self signed certificate"

I did create an exception in Firefox to accept my Nextcloud self signed certificate so I just exported the .pem certificate from Firefox and imported it in OPNsense (in System: Trust: Authorities). Now the log is:

Code Select Expand

Mar 23 23:41:26 OPNsense config[60343]: {"url":"https:\/\/192.168.8.13\/ocs\/v1.php\/cloud\/user","content_type":null,"http_code":0,"header_size":0,"request_size":0,"filetime":-1,"ssl_verify_result":1,"redirect_count":0,"total_time":0.023768,"namelookup_time":4.4e-5,"connect_time":0.00064,"pretransfer_time":0,"size_upload":0,"size_download":0,"speed_download":0,"speed_upload":0,"download_content_length":-1,"upload_content_length":-1,"starttransfer_time":0,"redirect_time":0,"redirect_url":"","primary_ip":"192.168.8.13","certinfo":[],"primary_port":443,"local_ip":"192.168.8.1","local_port":34026,"http_version":0,"protocol":2,"ssl_verifyresult":0,"scheme":"HTTPS","appconnect_time_us":0,"connect_time_us":640,"namelookup_time_us":44,"pretransfer_time_us":0,"redirect_time_us":0,"starttransfer_time_us":0,"total_time_us":23768}
 
"ssl_verify_result":1 looks like a generic error so I don't know where else to search...

I read the documentation at https://docs.opnsense.org/manual/how-tos/self-signed-chain.html#a-chain-for-your-local-nextcloud-server but if I understand correctly, I don't need that as my Nextcloud server already has its own self-signed certificate.

Do you have any idea of what is happening?

I am doing port forwards with multiwan on 19.7. On my side, I didn't have to change "Reflection for port forwards" and "Automatic outbound NAT for Reflection" at rules level or global level (in Firewall -> Settings -> Advanced). I only unchecked "sticky connections" but this is mostly because I am using multiwan in a failover mode. The trick was to select all my WAN interfaces as "Interface" and "This Firewall" as "Destination" in all rules.

I understand reflection is necessary if you try to connect through your WAN public IP from your LAN, but it's not necessary if you connect from a different completely different network (from your cell phone on 4G for example). Also, I realized the "Automatic outbound NAT for Reflection" option breaks a multiwan failover configuration (if tier1 is off, it doesn't switch to tier2 automatically).