Messages

opnsense-update -zkr 24.7.1-pf4 restores traceroute functionality.

Experiencing the same behaviour here.

Yes over IPv6!
Tried IPv4, also all records available.

Windows 10 22h2, OPNsense 24.1.1

All records are comming through here!

Code Select Expand

Non-authoritative answer:
dhl.com text =

        "google-site-verification=MKYejQl1Mh9fB5dwrsO9d6xADpVZellFYmDBs6uHvI4"
dhl.com text =

        "mongodb-site-verification=0Crz9iHBXaQyTii6NECBJXDlmyUup51q"
dhl.com text =

        "ms-domain-verification=5253e385-6b1f-4621-b0a0-090e374e40ea"
dhl.com text =

        "Dynatrace-site-verification=8a64ad24-3b3a-4665-b8ac-0975fa5be9f6__a5mepuk85f2o7egbq5cmmlp8tu"
dhl.com text =

        "google-site-verification=HUVzQJOJmKyha5LCFbvFwjCDh5JMkC-85K5C-s44Lt0"
dhl.com text =

        "v=spf1 include:dpdhl._spf.dhl.com include:3a._spf.dhl.com include:3b._spf.dhl.com include:3c._spf.dhl.com include:3d._spf.dhl.com include:3e._spf.dhl.com include:3f._spf.dhl.com include:mrsc._spf.dhl.com include:e2ma.net include:spf.mandrillapp.com ~all"
dhl.com text =

        "docusign=6d733f59-f916-4426-9028-c800fc5e2ba1"
dhl.com text =

        "adobe-idp-site-verification=00c0593e27f3b625df20796c2aea6a9d18005694df716a444a53ac7242f672a1"
dhl.com text =

        "atlassian-domain-verification=mmsERGyn2rlOT8eOe12PbNcvgZ4mxzeOq+e75gQbAYUO3cOhU4Fr7+UfTRKRzrfs"
dhl.com text =

        "facebook-domain-verification=8vnu10tvn6novixz0fkg8ybx26kz1f"
dhl.com text =

        "amazonses:gtMOfHHBB2nwFoX+iXEWovWkRf66WFugJgKxjzCN9Rg="
dhl.com text =

        "onetrust-domain-verification=86d6b6dd18a743d9a30cf4cb40017e84"
dhl.com text =

        "nintex.625eb685a1608f0070bca981"
dhl.com text =

        "atlassian-domain-verification=zCudhHQPIDjcXLKuYWm5QqU2aeaWx4Ccq7RcoJj1KtTXDqxaYKpdcqkH3PnT8C8f"
dhl.com text =

        "cisco-ci-domain-verification=6f8bf0505ee35b0a464c20a0520dd8fd2da5bbfaa26ad53d20d6dc33cd536ab1"
dhl.com text =

        "smartsheet-site-validation=BwFwvtcb2t5Uqeanz8SefQ_4lIZvRQLd"
dhl.com text =

        "Dynatrace-site-verification=f913d8c2-f6d5-4265-9c7f-aae8784c0652__4u08f5qon49tv8mngsmruso1b0"
dhl.com text =

        "pardot1024731=05ff64dc9fea2fd92da4238a7c431480cd48736d513a8dfdeebf552c939afcd0"
dhl.com text =

        "sending_domain1024731=7b1368b64c62a7e74ebee33ffba6d1f1ea1a51f29564c1195a486733b0bc813f"
dhl.com text =

        "hm5bpdz3w772wpzb4xbw649h5dd7f6xs"
dhl.com text =

        "google-site-verification=QsnKi52v6M1z-N3dtyxAopCglJmE4GiEipCLZJxna1Y"
>

Hi,

When i try to issue an certificate for *.example1.com and *.example2.com with DNS alias mode enabled the CN name could not be verified.

It looks like the ACME client is generating twice a txt to the DNS alias provider.
This should be one so the cname record on example1 and 2 is the same and could be verified.

Temp solution
When issuing a certificate without an alternate name set it works.
Right after that adding the alternate name again is works! (Because the first domain is already verified.)


After all it was DuckDNS which doesnt support multiple txt records!
Now using "desec.io" and everything is working fine!

Add an trailing dot!

nslookup
google.com.

Not tried an reboot yet but experiencing the same problems.

https://forum.opnsense.org/index.php?topic=37470.0

If i have some spare time left i will try to reboot.

Also unable to deploy certificate to a Synology with 2fa enabled.

When running
acme.sh --home /var/etc/acme-client/home --deploy --deploy-hook synology_dsm -d "*.domain.com"

I am unable to authenticate against my Synology nas.

Is there way to run the automation settings in the CLI ?

Digging further is see that the config file isnt changed at all after modifying the device ID in the gui.
I have 2 certificates, the domain.conf of 1 has a device_id and device_name but with a wrong id.
The other domain doesnt have the device_id and device_name set.

@annoniempjuh, had the same before 23.7.5 with a working 1500mtu. For testing i deleted those dommy interfaces and set MTU on WAN 1508. After the upgrade all parent interfaces adjusted automaticly to allow 1500 MTU on PPPoE.

Interfaces - point to point - devices edit the PPPoE tunnel under advanced no Mtu set?

My situation PPPoE over vlan6.

With 23.7.5 no additional devices configured to force an MTU of 1500 on the WAN interface.

Just updated to 23.7.5.

Deleted all dummy interfaces "Physical NIC" "VLAN", checked WAN PPPoE is set to 1508 calculated MTU is 1500.
Upgrade to 23.7.5 and voila! 1500 MTU on PPPoE

Nope completely empty.

Not able to reboot right now, will try later today.
But when is was trying to resolve the issue i rebooted several times and the MTU stays at 1500.

https://forum.opnsense.org/index.php?topic=35282.0

Experienced the same!