tofubl @ tofubl @discuss.tchncs.de

Posts

5

Comments

188

Joined

2 yr. ago

You know your stuff, man! It's exactly as you say. 🙏

My config was more or less identical to yours, and that removed some doubt and let me focus on the right part: Without a network config on br0, the host isn't bringing it up on boot. I thought it had something to do with the interface having an IP, but turns out the following works as well:

 `

    
user@edge:/etc/systemd/network$ cat wan0.network
[Match]
Name=br0

[Network]
DHCP=no
LinkLocalAddressing=ipv4

[Link]
RequiredForOnline=no
`
  

Thank you once again!

No worries. It has a stripe integration, too, so it's easy to handle payments without having to hold customers' credit card info.

You can easily host the community edition in Docker or otherwise. Odoo has a steep learning curve but it's very versatile. It can definitely do what you describe.

I have another question, if you don't mind: I have a debian/incus+opnsense setup now, created bridges for my NICs with systemd-networkd and attached the bridges to the VM like you described. I have the host configured with DHCP on the LAN bridge and ideally (correct me if I'm wrong, please), I'd like the host to not touch the WAN bridge at all (other than creating it and hooking it up to the NIC).

Here's the problem: if I don't configure the bridge on the host with either dhcp or a static IP, the opnsense VM also doesn't receive an IP on that interface. I have a br0.netdev to set up the bridge, a br0.network to connect the bridge to the NIC, and a wan.network to assign a static IP on br0, otherwise nothing works. (While I'm working on this, I have the WAN port connected to my old LAN, if it makes a difference.)

My question is: Is my expectation wrong or my setup? Am I mistaken that the host shouldn't be configured on the WAN interface? Can I solve this by passing the pci device to the VM, and what's the best practice here?

Thank you for taking a look! 😊

Thanks for your patience. I appreciate it and I'm learning a lot. 🙏

There's a chance yet!

edit: That actually seems simple enough and should integrate nicely with the rest of my network. Cool!

That sounds reasonable. I would do the same.

Okay, I think I found a bit of a catch with Incus or LXD. I want a solution with a web UI, and while Incus has one, it seems to have access control either browser certificate based or with a central auth server. Neither are a good solution for me - I would much prefer regular user auth with the option to use an auth server at some point (but I don't want to take all of this on all at once.)

I hope it's okay that I keep coming back to you with these questions. You seem to be a strong Incus-evangelist. :)

I guess I could only expose the web UI on localhost and create an SSH tunnel in order to use it...? Not so good on mobile though, which is the strongest reason for a webui.

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.

Absolutely. Great intel; thank you!

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?

OPNsense running in the Incus live demo. Fun!

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?

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 wrote it in reply to another comment, but the traffic reaches the service on 10.0.0.22:8888. The problem seems to be with the return path, i.e. Hairpin NAT, but I don't know what it is.

edit: scratch that, it's not hairpinning.

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.