Absolutely. Great intel; thank you!
tofubl
joined 2 years ago
With Incus only officially supported in Debian 13, and LXD on the way out, should I get going with LXD and migrate to Incus later? Or use the Zabbly repo and switch over to official Debian repos when they become available? What's the recommended trajectory, would you say?
Very informative, thank you.
I am generally very comfortable with Linux, but somehow this seems intimidating.
Although I guess I'm not using proxmox for anything other than managing VMs, network bridges and backups. Well, and for the feeling of using something that was set up by people who know what they're doing and not hacked together by me until it worked...
Incus looks cool. Have you virtualised a firewall on it? Is it as flexible as proxmox in terms of hardware passthrough options?
I find zero mentions online of opnsense on incus. 🤔
OSMC on a rpi3 with a hifiberry+ has served me well for many years. Most things just work, even passthrough TV remote over i2c if the TV supports it (brand name for the implementation varies by TV manufacturer I think). My setup has been really slow in recent months, but I probably just need a new sd card... Streaming service integration in kodi isn't perfect but e.g. Netflix works well enough.
It's a bit of tinkering to get it just the way you want it, but not too much and then it's great with a lot of flexibility. I have slapped an IR LED onto a GPIO, for example, and I have a service running that checks for audio output and turns my old hifi system on and off accordingly.
Son of a gun!!! Thank you so much! I spent HOURS changing every setting except this one and actually came to the conclusion that it must be something to do with my ISP's modem or DNS or something.
The rule is the "associated filter rule" OPNsense automatically creates (interfaces are WAN and LAN) and it triggers as a "pass" just fine when I send a request. (I'm attaching another screenshot from the live log below.)
You don't happen to have a clue WHY this rule breaks everything?
Associated filter rule
Live log with associated filter rule active (leads to
curl: (56) Recv failure: Connection reset by peer)
Please take a look at my updated original post. I have added some information and a tcpdump.
And I'm happy to see what sticks!
Pointing DNS to 192.168.0.1 doesn't change anything, and I'm anyway able to talk out from behind the firewall to the 192.168 net, so that would mean that address resolution works in that direction, no?
I do agree, though, that it seems like the responses are not making their way back correctly, as I can see the requests coming in and replied to in the apache logs.
I appreciate you taking a look. It does indeed have standard rules to drop private networks (192.168, 10.0 and so on), but I have them disabled.
The forward specifies range 8888-8888 and translates it to 8888.
Further digging: The request reaches the docker container, which returns 200 OK.
my-apache-app | 2024-02-09T12:53:22.925676854Z 192.168.0.123 - - [09/Feb/2024:12:53:22 +0000] "GET / HTTP/1.1" 200 161
What is going on here? Do I need some rules in the other direction, on top of "Automatic outbound NAT rule generation"?
Nextcloud doesn't like changes on disk in its own file structure, but you can mount "external storage" where Nextcloud is okay with changes and happily scans the location when you access it (a network share, or a local file path also works; SMB share will probably get you around the permissions problem though.)
Don't know about immich as I haven't used it, but you will probably have to decide on one of the two services to be "in charge" of the files, I think.