Docker Networking, VLANs and Unraid Access


Recommended Posts

I have two VLANs on my network and one NIC on my unraid box.

On Unraid I have configured the network card (eth0) to allow bridging and enabled VLANs adding eth0.10 with no IP4 assignment.

Then in Docker I have added a subnet on br0.10 matching my VLAN 10 network.

 

I have then been able to set some containers to run with a network of custom: br0.10 and they appear on my VLAN.

 

This is all OK but I want to be a bit more selective and run these containers in bridge mode rather than macvlan.

 

AIUI the ability to add custom bridge networks was added in 6.5.1  ...

which I guess need to be added manually via docker CLI and then will appear in the dropdown?

 

Running in bridge mode would mean giving the Unraid box an IP on VLAN 10 but I don't want anything other than dockers to be accessible from that VLAN.   If I assign an address for eth0.10 in the network settings then the Unraid GUI and SSH both become available from that network.

 

Is there anyway to achieve this so that I can run my container on a bridge network, accessible via a VLAN 10 address but not make Unraid itself accessible on VLAN 10?

Edited by jameson_uk
readability
Link to comment
16 minutes ago, ken-ji said:

Odd. so if you do not have an IP address assigned to eth0.10, Unraid can still be reached via that VLAN? How exactly? are you just not confusing accessing it over your router?

client (VLAN 10) -> router (VLAN 10) -> router (VLAN1) -> unraid(VLAN1/br0)

 

No, with no address assigned I cannot access Unraid from VLAN10 but if I setup a container to run in bridge mode it is only accessible via the Unraid IP on VLAN 1.

 

I want to have docker containers accessible on VLAN 10 (but running in bridge mode) but not Unraid.

 

(I have reworded original post a little as it didn't quite make senes....)

 

Link to comment

Hmm... containers in bridge networks are by default accessible by all the assigned IP of all the interfaces of the host. This is the default docker behavior and Unraid did not support the advanced mode here.

However, think about it a bit. If you assign an ip on VLAN10 to Unraid, the containers can now be accessed on this IP in VLAN 10, but Unraid services become accessible as well.

If there is no IP as you have it now, all containers on bridge networks, will only be accessible via the VLAN1 ip address

So the best answer for a container to be accessible only from VLAN10, you would need to do custom docker networks and assign the desired IP (or dynamically via Docker) to the container. I think you already have this setup.

 

Is there any reason you must run with a bridge network rather than a macvlan?

Edited by ken-ji
Link to comment
9 minutes ago, ken-ji said:

However, think about it a bit. If you assign an ip on VLAN10 to Unraid, the containers can now be accessed on this IP in VLAN 10, but Unraid services become accessible as well.

I guess the question was whether it is possible to to have an IP allocated on VLAN 10 but force Web UI, Samba, SSH....   to only listen on VLAN 1

Link to comment

It is...

image.thumb.png.7049d12e148edcb9cfcf53e1e1ea746b.png

this is a snippet of my nginx reverse proxy running on VLAN3 with its own IP.

Unraid cannot be accessed from VLAN3, only nginx and any related containers on that same interface.

It's up to my router to restrict access to/from other VLANs

Edited by ken-ji
  • Like 1
Link to comment
1 minute ago, ken-ji said:

But that's the same as running the containers using macvlan netowrk on br0.10 so I don't see why switching to custom bridge network is going to work differently

My understanding is that I could create a custom docker network (outside of VLAN1 or 10) and have both containers in this network.   Only one would have any ports accessible but being on the same network it would be able to access to other container.

 

The difference to running this on Macvlan is that currently everything on VLAN 10 can see and access this container that I essentially want to hide.

 

Or at least that is what I think I can do.....

Link to comment

I recommend sticking all your containers that are grouped together in their own VLAN, and have your router restrict access to the VLAN

This is probably the easiest way to achieve what you want since macvlan networking is like running a virtual switch on the br0.10 interface so everybody on VLAN10 would be able to see the traffic

 

Link to comment
  • 2 years later...

So coming back to this now (and it appears this might be a cleaner in 6.12).

First part is adding Unraid onto VLAN and preventing access to the admin stuff (SSH, web GUI etc.).   This was a little pain previously and involved some hacks but seems you can do this relatively easily in 6.12.

 

So adding Unraid onto VLAN was just a case of defining the VLAN on the network settings and assigning an IP.

Now there is an Interface Extra section in the config where I set the listening interface to br0 and excluded br0.10

This means I can only access admin services on the main (br0) IP (and annoyance like the ftp server refusing to stay stopped, SAMBA needing hacks to config files etc appears to all be in the past).

 

I then created my own docker network

docker network create --subnet x.x.x.x/24 iot-bridge

then I went through each of the containers I wanted to link and set their network to iot-bridge.

On most I removed the exposed ports so they are only accessible by other containers running on the same network.

 

Final step was to set the exposed ports on the containers I did want accessible to include the IP.    So one thing I have done is put at least one service behind a Nginx reverse proxy (so I could enable TLS).    So on the nginx container I changed the port from 443 to x.x.x.x:443 (x.x.x.x being the IP of the Unraid box on eth0.10).

 

Now the nginx proxy is only accessible on VLAN 10 and the the container behind it is not directly accessible at all.   I have a few other things like an MQTT server that are purely accessible on the docker network which makes me a lot happier than where I was previously

  • Like 1
  • Thanks 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.