Messages

Human error, it happens.
Who hasn't spend hours debugging an issue, only for someone else suddenly pointing out that you missed a coma somewhere.
Still, better a typo once in a while than just blindly copy pasting AI output. :)

Tested and confirmed working.

Thanks!

Thanks! I saw you closed the github issue.

Anyway to get this installed already?
Or is there an update to Opnsense that includes this imminent anyway?

Done.

https://github.com/opnsense/plugins/issues/4914

There you go.
And thanks already.

I just changed my Log HTTP Access in JSON Format setting from enabled to disabled as I wanted to access requests to show up in my normal logs in the Opnsense GUI as I do need the json logs anymore.

However, it seems none of my access requests show up in the Caddy logs.

Under log settings log level is set to: DEBUG and Log HTTP Access in JSON Format is deselected.
Under the Domain in question HTTP Access Log is enabled.
If it matters, this is a wildcard domain with DNS validation. Protocol is HTTPS.

The sites I reach work just fine. It is just that my access does not show in the logs at all.

I restarted the service already, disabled and enabled it and ever rebooted OPNSense totally. Yet no success.

Anybody any idea?

Patch seems to have worked.
It did require a reboot of the system though, a simple stop and start of Caddy was not enough.

Thanks for the quick support!

That was fast. Thanks. Looking forward to seeing this implemented.

Since the last update to 24.7.10 it seems my redirects no longer work.

It seems it does pick up the request properly but then redirects to a URL that looks something like this:

http://bazarr/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/10.67.0.52:6767/.......
This address goes on like this until finally the request is aborted with: ERR_RESPONSE_HEADERS_TOO_BIG

My Caddy file is attached.

Looking at it I do not see any reason why the redirects should behave the way they do. There does not seem to be anything different in the Caddy file itself than before the update, as far as I can see.

Thanks for the reply. I also tried a lot of different configuration yet I can't get ti to work.
The annoying thing is that it works fine when using OpenVPN. But not with Wireguard.

You ever got this working?

In the old days you could get this working giving the interface a static IP, but this stopped working a while back.
Since then I have had no luck getting this to work again.

I tried to assigning a different IP to the reservation but the problem just moves with the new IP.
The device does seem to get the new IP fine though.
I really do not understand what is going wrong here.

Ok, it seems I was mistaken in that the device got the other IP.
It seems that the device is indeed keeping the correct IP from the reservation.
What confused my was the Unifi dashboard that does show the device as having the wrong IP.

That still makes things confusing as KEA seems to be complaining that the can not assign the reserved address to the client because it is already assigned to that same client?

Hi All,

I migrated to KEA yesterday hoping to try it out and for the most part things seem to work.
However I am running into a weird issue with one of my devices for which I created a reservation.

I created the reservation without errors and initially the device even takes the address I assigned. However after a few minutes I see the following in the logs:

2024-02-12T10:38:18   Informational   kea-dhcp4    INFO  [kea-dhcp4.leases.0x834ee2f00] DHCP4_LEASE_ADVERT [hwtype=1 xx:xx:xx:xx:a9:93], cid=[01:00:00:00:00:00:00], tid=0x2bf8807b: lease 10.0.0.103 will be advertised
None   None      Remote ID:     (none)
None   None      Relay ID:      (none)
None   None      State:         default
None   None      Pool ID:       0
None   None      Subnet ID:     3
None   None      Client id:     01:xx:xx:xx:xx:a9:93
None   None      Hardware addr: xx:xx:xx:xx:a9:93
None   None      Cltt:          1707730161
None   None      Valid life:    3600
2024-02-12T10:38:18   Warning   kea-dhcp4    WARN  [kea-dhcp4.alloc-engine.0x834ee2f00] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 xx:xx:xx:xx:a9:93], cid=[01:00:00:00:00:00:00], tid=0x2bf8807b: conflicting reservation for address 10.0.0.26 with existing lease Address:       10.0.0.26

After which the device promptly changes IP to 10.0.0.103.
This comes back in the log every 5 minutes and every time it getś a new IP. But it never stays on the IP I reserved for it (this would be 10.0.0.26 as shown in the error).

I have several other reservations setup in the same range and these all work fine.

I tried recreating the reservation several times already. Rebooted the OPNsense box. Rebooted the device several times. But I keep getting this error and the device moving IP every 5 minutes.

Any idea what is going on here? Any help is appreciated.

Anybody else have an idea?