Messages

Thanks, Franco!

It is now working with this patch applied :)

https://github.com/opnsense/core/commit/897d3cce3

# opnsense-patch 897d3cce3


Cheers,
Franco

Hi team,

The Backup API is still returning an error in the final 24.7 release.  The script posted above returns "Result of the HTTP request is HTTP/2 500"

and the script below returns "{"errorMessage":"Unexpected error, check log for details"}%" but I do not see any logs in the UI when viewing System>Log Files. Happy to keep on digging around if someone can assist in how to trouble shoot.

Code Select Expand

#!/bin/bash

KEY="partiallyredacted6Raif/mEENSbm8"
SECRET="partiallyredacted6RaifsInpBlickOeUCZcf"
HOST="opnsense.redacted.com"
PATHCONFIG="/Downloads/opnsense"
DATE=$(date +%Y%m%d)

curl -u "${KEY}":"${SECRET}" https://"${HOST}"/api/core/backup/download/this --create-dirs -o "$PATHCONFIG"/opnsense-config-"${DATE}".xml


Code Select Expand

❯ cat opnsense-config-20240726.xml
{"errorMessage":"Unexpected error, check log for details"}%

and here the is the verbose output

Code Select Expand

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*
Host opnsense.redacted.com:443 was resolved.
* IPv6: (none)
* IPv4: [myIP]
*   Trying [myIP]:443...
* Connected to opnsense.redacted.com (myIP) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [327 bytes data]
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [19 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [2829 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [520 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.redacted.com
*  start date: Jul 10 13:02:21 2024 GMT
*  expire date: Oct  8 13:02:20 2024 GMT
*  subjectAltName: host "opnsense.redacted.com" matched cert's "*.redacted.com"
*  issuer: C=US; O=Let's Encrypt; CN=R10
*  SSL certificate verify ok.
* using HTTP/2
* Server auth using Basic with user 'partiallyredacted6Raif/mEENSbm8'
* [HTTP/2] [1] OPENED stream for https://opnsense.redacted.com/api/core/backup/download/this
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: opnsense.redacted.com]
* [HTTP/2] [1] [:path: /api/core/backup/download/this]
* [HTTP/2] [1] [authorization: Basic K3FpcmNSOUZ2YXlKOWUrOTJTNVJaZUZucW1ETY2Y=]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /api/core/backup/download/this HTTP/2
> Host: opnsense.redacted.com
> Authorization: Basic K3FpcmNSOUZ2YXlKOWUrOTJTNVJaZUZucW1ET0UNaY2Y=
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/2 500
< set-cookie: PHPSESSID=3b69be9b49af90e42a7a16b3713f9546; path=/; secure; HttpOnly
< expires: Thu, 19 Nov 1981 08:52:00 GMT
< cache-control: no-store, no-cache, must-revalidate
< pragma: no-cache
< content-type: application/json;charset=utf-8
< strict-transport-security: max-age=31536000
< date: Fri, 26 Jul 2024 10:49:06 GMT
< server: OPNsense
<
{ [58 bytes data]
100    58    0    58    0     0    865      0 --:--:-- --:--:-- --:--:--   878
* Connection #0 to host opnsense.redacted.com left intact

I had the UDB Broadcast Relay Package working well on the 24.1 release, and from the summary screen it seemed that the process was running OK under 27.1, but my devices failed to work. When I go into the UDP screen, there is a red banner error (I cannot see anything in the general logs) and the previous config errors are removed, even though they are in the config.xml. Reading the config confirms this also as it complains there are duplicate/existing entries.

The below script was working on 24.1.x to retrieve opnsense backup via the api but now fails with HTTP/2 500 error. The user has GUI Diagnostics: Configuration History and GUI Firewall: Aliases privileges.

Code Select Expand

#!/usr/bin/bash

# Change API key and secret, number of days to keep backups, the path to your backups and the hostname for your firewall

key="redacted"
secret="redacted"
daystokeep=90
destination="backup/path"
fwhost="opnsense.hostnameredacted.com"

date=$(date +%Y-%m-%d)

result=$(/usr/bin/curl -I -s -k -u "$key":"$secret" https://$fwhost/api/core/backup/download/this | head -1)

if [[ $result != *"200"* ]]; then
   echo "Result of the HTTP request is $result"
      exit 1
      fi

      /usr/bin/curl -s -k -u "$key":"$secret" https://$fwhost/api/core/backup/download/this > $fwhost-config-$date.xml

      error=$?

Code Select Expand

./opnsense_backup_v2API.sh
Result of the HTTP request is HTTP/2 500

Edit: Seems I had wrong permissions on the user account; all god now!

Thanks franco.  So yes, ping6 with a packet size of 1500 is not working. 

Is there something that I need to fix on my end or do I just let it go?

I'm trying to figure out why the Firmware Connectivity Check fails the IPV6 ping:

Code Select Expand


All repositories are up to date.
Checking connectivity for host: pkg.opnsense.org -> 2001:1af8:4f00:a005:5::
PING6(1548=40+8+1500 bytes) [MY-IPV6_IP] --> 2001:1af8:4f00:a005:5::

--- 2001:1af8:4f00:a005:5:: ping6 statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
Checking connectivity for repository (IPv6): https://pkg.opnsense.org/FreeBSD:13:amd64/22.1
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 792 packages processed.
All repositories are up to date.
***DONE***

However from the OPNSense terminal:

Code Select Expand

root@opnsense:~ # ping6 2001:1af8:4f00:a005:5::
PING6(56=40+8+8 bytes) [MY_IPV6_IP] --> 2001:1af8:4f00:a005:5::
16 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=0 hlim=52 time=280.033 ms
16 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=1 hlim=52 time=278.851 ms
16 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=2 hlim=52 time=278.849 ms
16 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=3 hlim=52 time=279.302 ms
16 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=4 hlim=52 time=279.415 ms
16 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=5 hlim=52 time=278.946 ms
^C
--- 2001:1af8:4f00:a005:5:: ping6 statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 278.849/279.233/280.033/0.419 ms
root@opnsense:~ #

Has anyone figured out how to get ddclient to work with Digital Ocean?

I've tried using the api.digitalocean.com but it doesn't update the record.

I have been using DNS over TLS with Cloudflare IPv4 and IPv6 servers successfully for sometime.

I recently noticed that the Spot Apple TV and iOS apps reported 'Connecting' or 'No internet connection'.  I validated that none of the Unbound blocklists were blocking the Spotify servers and the moment I switched to an external DNS, Spotify would work.

Narrowing it down, I then removed all the DNS over TLS servers and only enabled 8.8.8.8 port 853.  This allowed Spotify to connect with no issues but the moment I re-added the Cloudflare IPs (both IPv4 and IPv6) Spotify wasn't happy. 

Not sure if the server list is used in a round robin fashion.  Does anyone know why Spotify is only playing nicely with Google's DNS when using DNS over TLS?

Not entirely strange, but what is strange was that it took up to 20min for the firewall to realise there was a IPv6 gateway and to add a route.

I do understand the issue with the ISP losing IPv6 connectivity and my firewall not knowing any different, but glad it is working now.

Unfortunately that has not worked for me.

Just to recap what I'm seeing:

• My ISP does not provide an IPv6 address, only a /56 delegated prefix.
• Because I do not have an IPv6 address, dpinger does not start (address is invalid).  I am using Cloudflare's IPv6 address as the monitor address
• My IPv6 gateway is showing as down, but I have full IPv6 functionality as shown by the ping6 and netstat -r | grep default commands above. A gateway IP is not shown on the gateway screen although visible from the command line
• If I disable gateway monitoring, the gateway shows as Online however IPv6 routing stops and it is no longer a default route even though the gateway screen shows it as 'active'

Should I raise a bug for this?

Edit: I've put the gateway monitor address to the ISP link local. 20 minutes later, IPv6 functionality began to work and the Gateway is showing as Online.  Strange!

With IPv6 working (and the IPv6 gateway showing Offline)

Code Select Expand

root@opnsense:~ # ping6 www.google.com
PING6(56=40+8+8 bytes) 2001:8003:2810:****:**:***:***:2a11 --> 2404:6800:4006:810::2004
16 bytes from 2404:6800:4006:810::2004, icmp_seq=0 hlim=118 time=12.587 ms
16 bytes from 2404:6800:4006:810::2004, icmp_seq=1 hlim=118 time=12.412 ms
16 bytes from 2404:6800:4006:810::2004, icmp_seq=2 hlim=118 time=12.173 ms

Code Select Expand

root@opnsense:~ # netstat -r | grep default
default            cpe-121-209-127-25 UGS        igb0
default            fe80::3e94:d5ff:fe UG         igb0

My IPv6 setup with my ISP is by prefix only.  I have all my VLANs correctly setup and clients are receiving a IPv6 address.  Gateway monitoring is enabled on the IPv6 Gateway and despite it showing as Offline, I have full IPv6 connectivity, confirmed with IPv6 test websites and ping6 to google.

As my ISP is not providing a IPv6 address, dpinger does not start:

Code Select Expand

/system_gateways.php: The WAN_DHCP6 IPv6 gateway address is invalid, skipping.

If I disable Gateway monitoring, my IPv6 connection stops working, until I re-enable Gateway monitoring.  Can anyone explain what is happening here?

If I put a local DNS server against a gateway group I get:

You can not assign a gateway to DNS server "192.168.1.1" which is on a directly connected network.

I have followed the instructions of setting up Multi WAN, including the steps of adding DNS Servers to each Gateway group.

How does this work when using Unbound?  Does all traffic that is destined for a Gateway Group use the gateway DNS?  Is there anyway to use Unbound instead of external DNS Servers when using Multi WAN?