TurnKey LXC

Please note that after I downloaded and installed minimal debian stretch, and after following installation and network instructions in https://wiki.debian.org/LXC#Installation, containers DO get an ip address:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:8e:b9:62 brd ff:ff:ff:ff:ff:ff
    inet 192.168.9.76/24 brd 192.168.9.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe8e:b962/64 scope link
       valid_lft forever preferred_lft forever
 

Altough, this is not ideal for me, since I was trying to take advantage of the preconfigured turnkey appliances, and not having to make all from scratch... So if you can find what I should do differently, I'll test it inmediately.

Hey Sergio,  try my solution again but Substitute  "br0" with "enp0s3"?

I looked at some diffrences and noticed you dont have a:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
    link/ether 00:0c:29:c4:18:6b brd ff:ff:ff:ff:ff:ff

Dont know if thats a problem. Just curios Is the host on the network with a static IP? I assigned my TK LXC host a static IP.

When I execute the "ip a" command, in addition to the eth0: lines, part of the results contain these lines in there:

3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:0c:29:c4:18:6b brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.240/24 brd 192.168.2.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fec4:186b/64 scope link
       valid_lft forever preferred_lft forever

I am wondering if a variable needs to change.

In my case it was "br0:"  and in your case perhaps its "enp0s3:" that may need to change.

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:8e:b9:62 brd ff:ff:ff:ff:ff:ff
    inet 192.168.9.76/24 brd 192.168.9.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe8e:b962/64 scope link
       valid_lft forever preferred_lft forever

Ben

I assume that all the network info you've posted is from guests? I suggest that your should be 100% sure that networking is working fine on the host first. Considering the different things that you've tried, I'm guessing that it probably is, but just in case something else is going on here, please double check the network connectivity of the host system. If you haven't already, I suggest setting a static IP.

Assuming that the network info from both posts are guest container info, then are you sure that the "vanilla" Debian is working how you think it is? Obviously, it's working, but looking at that the info you've posted, assuming that is an LXC guest, that IP address (192.168.9.76) looks to me like a NAT IP address, rather than a Bridged one. Unless of course your LAN uses 192.168.9.x IP addresses (possible but seems unlikely)?!

If I'm right, then you're comparing apples to oranges, as NAT networking will provide a separate internal interface, but you won't be able to connect directly to that IP from elsewhere on your LAN. Instead you'll need to configure port forwarding and use the host's IP address. That's a totally valid way of doing things, but it isn't what you were doing before on TurnKey. FYI, the config that you've been trying to use on TurnKey is also described on the Debian wiki.

FWIW you can use NAT (instead of Bridged) networking on the TurnKey LXC appliance too. If you are happy with that, perhaps that will "just work"?

Regarding what we do to our appliance, as I noted before, all our build code is on GitHub. You can see the LXC specific packages we install in the plan. The additional (and/or tweaked) config files are within the overlay. Note the contents of the overlay is relative to '/'. So 'overlay/etc/some/config/file' should be found at '/etc/some/config/file' on your server. The other tweaks done are contained within the conf script. From a glance, it looks like it mostly tweaks kernel config/parameters relating to the host firewall.

I haven't worked extensively on it. In the last few years it has been further developed and maintained by a community member. Unfortunately, he hasn't been around for a while, but I'm sure that he would have some good ideas. As he isn't about, I suspect that I'll ge a much more intimate knowledge of it when I do the v16.0 update that will need to be done at some point.

Regardless, I don't understand why it's causing so much pain?! The example code from the docs was definitely working fine when it was released (as I tested it myself). I wonder if there's been a security upgrade that has broken something? That's the only thing that occurs to me... Although it still wouldn't explain how Ben managed to get it going but it won't work for you?!

I've never come across that!?! It definitely sounds like we should add that to the LXC appliance docs somewhere!

Whilst I've never come across it, in fairness, I've never run the LXC host appliance in VMware or VirtualBox either - I use KVM/QEMU. I can only assume that KVM set it like that by default or is somehow smart enough to know when it's needed?

Regardless, great detective work and fantastic to hear that you've worked it out!

BTW, I'm not 100% sure where to put it, but to ensure that it doesn't get forgotten, I've opened an issue so it at least gets documented somewhere.

Re your OpenVPN workaround that you aren't happy with, I'm more than happy to add my 2c, but I'm no expert when it comes to OpenVPN. So no promises there, but sure please tell me about it when you get a chance.

Thank you both for the help, but after 3 more days of banging my head against the wall, I found the answer 23 pages deep in an old discussion in another forum, and after searching the web so much and seeing how often this happens, I want to suggest a footnote perhaps for the LXC page here, something like:

*Be sure to enable promiscuous mode in the network settiongs if you´re going to install it on a VM.

Because otherwise you won´t get the bridge to work correctly (or at all) like it was my case, maybe this is obvious for some with some knowledge of networks, but sure it wasn´t for me and as I've learned, so many others that like me test everything first on a VM before touching hardware.

So that was it! everything was working as expected, and I have it up and running with 5 containers while I do my testing and set things the way I need it.

Jeremy, yes, my network is 192.168.9.x because I use a lot of openvpn and I need a segment that nobody uses.

With that solved everything I've tried has worked so far, so the learning curve has flattened a lot for me, since now I can test things as I'm reading them and everything works the first time (that I don´t make a typo, which happens a lot).

Thank you all and Jeremy, soon I'll post a problem I'm having with the openvpn appliance, which I fixed but it is a terrible fix and I'd like to fix it properly. Thanks again! 

Ill look for and use this solution!

I bet this was it in my case as well!

Really great!!