this post was submitted on 19 Oct 2023
2 points (100.0% liked)

Self-Hosted Main

515 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
communick@selfhosted.forum
2
Can't access NPM when assigning a macvlan IP to it (alien.top)
submitted 1 year ago by Illuminated_Humanoid@alien.top to c/main@selfhosted.forum
23 comments fedilink hide all child comments
 

Hi

Stock nginx built into Synology DSM won't cut it, so I decided to install Nginx Proxy Manager. Before doing so, I created a macvlan and assigned the NPM container to use the assigned IP. Once install is finished, and I try to launch NPM, it fails to load. I tried the same install without macvlan, and it works and loads just fine. I have installed many other containers on macvlan, so I know what I am doing and have the knowledge and experience, but I have never run into this before where there seems to be a conflict I am not aware of.

Help? Anyone?

you are viewing a single comment's thread
view the rest of the comments
[–] Illuminated_Humanoid@alien.top 1 points 1 year ago (1 children)

I think I am about 99% of the way there. Seems like I got it mostly figured out, but I do have a couple questions for you. And thanks again for your time, you have no idea how much I appreciate you and your assistance in this.

#1. After creating the docker network, you suggest creating the macvlan and the command for creating the macvlan involes 'macvlan0'. I cannot use macvlan0 and instead am forced to use macvlan1 because macvlan0 is taken by the docker network we created just before creating the macvlan. Seems to be a conflict. I checked and there's nothing else conflicting other than the already created macvlan0 from the step before.

#2. After completing the steps, I can access my NAS as usual, the Nginx proxy manager is accessible via it's macvlan IP, but I can also connect to the NAS and the Nginx from the auxillary host IP. What's the deal with that?

#3. Once all is said and done. Should my Nginx be connected to both the bridge network and the new macvlan or just the macvlan? It's always connected to the bridge by default, but when I add the container to the new macvlan, am I supposed to disconnect it from the bridge?

[–] isleepbad@alien.top 1 points 1 year ago (1 children)

I think I am about 99% of the way there. Seems like I got it mostly figured out, but I do have a couple questions for you. And thanks again for your time, you have no idea how much I appreciate you and your assistance in this.

  1. After completing the steps, I can access my NAS as usual, the Nginx proxy manager is accessible via it's macvlan IP, but I can also connect to the NAS and all it's services including the Nginx container from the auxillary host IP. What's the deal with that?

Yes, the auxiliary host IP is basically a new virtual IP that sits on your LAN. So basically when you connect your synology to your home network, it gets assigned an IP (with its own MAC address included). With the MACVLAN network, you've basically created a new virtual network on your NAS with its on device (MAC) address. It is in essence a virtual copy of your NAS host that your router sees it as a new device on your network.

  1. Once all is said and done. Should my Nginx be connected to both the default bridge network and the new macvlan or just the macvlan? It's always connected to the default bridge when installing any new container, but when I add the container to the new macvlan, am I supposed to disconnect it from the default bridge at the same time?

This is up to you how you want your network architecture to look like, but when you spin up a new container that you want available accessible by your ngnix, you have to:

  1. Specify your docker's macvlan network as your container's network (and remove it from the default bridge) OR

  2. Connect your ngnix container to your application's docker network (basically isolate all containers in their own network)

Up to you. Personally I do #2.

  1. Your fourth command for adding routing. How do I know what to use? My IP range for example is 192.168.87.96/30 with an auxiliary IP of 192.168.87.99. How do I decide the routing CIDR notation? I tried to look at yours and wasn't sure how you decided on yours. I just went with 192.168.87.96/30 which is the same as my IP range, but I'm not exactly sure what that is doing or not doing and if I should've chosen a different Ip for that. My CIDR notation for IP range is just 4 IPs, as you can probably tell by now. I notice this one is very important and if not configured properly can make or break the connection. At first, I selected 192.168.87.98, but that didn't work. When I chose by IP range for routing, it worked. I blindly did this, so I have no idea why one is working over the other and how to decide this part.

I presume you're talking about this one ? sudo ip addr add 192.168.2.201/32 dev macvlan0 I guess I didn't explain properly but that is your auxiliary host's IP. If you look at command 2 you'll see --aux-address="host=192.168.2.201". Basically the CIDR notation /32 is the same as the subnet mask 255.255.255.255, only one IP address can be served in macvlan0.

  1. Your final command, which you say is optional for communication between the macvlan and the NAS. I'm not sure if I need to be using this? My entire reason for doing all this is to use NPM for accessing my FQDN on my LAN with SSL certs only on my LAN and nothing exposed to outside internet. I just want all the DNS rewrites from Adguard Home to point to the Nginx macvlan IP so that Nginx can proxy it to the correct NAS service and also SSL it at the same time. Adguard home cannot use port numbers in the DNS rewrites and only can use IP, which is why I am doing all this in the first place. I had to give Nginx its own IP, or Adguard home DNS rewrites couldn't communicate with it.

Yea its optional. For my purposes it was nice to have because I have gitea and wanted to use GIT on the Synology locally. You don't have to.

Overall, I am able to execute all you've described with just these concerns I've listed above. Again, thanks a ton, brother. I learned a lot in this experience.

Yea it's not straightforward and I spent a ton of time researching it. Glad to help.

[–] Illuminated_Humanoid@alien.top 1 points 1 year ago (1 children)

I presume you're talking about this one ?

sudo ip addr add 192.168.2.201/32 dev macvlan0

I guess I didn't explain properly but that is your auxiliary host's IP. If you look at command 2 you'll see

--aux-address="host=192.168.2.201"

. Basically the CIDR notation

/32

is the same as the subnet mask

255.255.255.255

, only one IP address can be served in macvlan0.

I was actually referring to 'sudo ip route add 192.168.2.200/29 dev macvlan0' for #3

This one has me stumped. I hope you're not one of those who deletes his Reddit posts because I may need to come back to this post one day 😁

[–] isleepbad@alien.top 1 points 1 year ago (1 children)

I was actually referring to 'sudo ip route add 192.168.2.200/29 dev macvlan0' for #3

That is the MACVLANs subnet. That's basically carving a small subnet out of your LAN that your virtual LAN will sit on. See the preparation section of the original post.

And yes, all proxying goes to the aux IP.

[–] Illuminated_Humanoid@alien.top 1 points 1 year ago (1 children)

Looking at your example. Your original settings are:

docker network create -d macvlan \
-o parent=eth0 \
--subnet=192.168.2.0/24 \
--gateway=192.168.2.1 \
--ip-range 192.168.2.200/27 \
--aux-address="host=192.168.2.201" \
dockervlan

Why did you use 192.168.2.200/29 for your route? This is the last part I dont quite understand. How does it play into the settings you chose above?

My setup is ip range 192.168.87.96/30 which is ip range 192.168.87.96 to 192.168.87.99 . I chose 192.168.87.99 as my auxillary and my Nginx was automatically given IP 192.168.87.96 . Now my question is how do I go about knowing what to use for route? I blindly first tried 192.168.87.98 from some bad info ChatGPT gave me and then I changed the route to the exact same CIDR notation I use for my IP range which is 192.168.87.96/30 and that seemed to work. Im asking because although it works I have zero clue why it works. My brain doesnt understand this final part.

🙏🏼

[–] isleepbad@alien.top 1 points 1 year ago (1 children)

Why did you use 192.168.2.200/29 for your route? This is the last part I dont quite understand. How does it play into the settings you chose above?

I made a typo here and it should be --ip-range 192.168.2.200/29

As I mentioned above you are creating a virtual LAN and as such you need to carve out your own subnet.

My setup is ip range 192.168.87.96/30 which is ip range 192.168.87.96 to 192.168.87.99 . I chose 192.168.87.99 as my auxillary and my Nginx was automatically given IP 192.168.87.96 . Now my question is how do I go about knowing what to use for route?

What do you mean what to use for route? Given what you said your command should look like:

docker network create -d macvlan \
-o parent=eth0 \
--subnet=192.168.87.0/24 \
--gateway=192.168.87.1 \ #this is your router's address
--ip-range 192.168.87.96/30 \
--aux-address="host=192.168.87.99" \
dockervlan

So that command is saying: I have an entire LAN that lives on the subnet 192.168.87.0/24. My router (i.e. gateway) has the IP address 192.168.87.1. I have a virtual network (macvlan) that has its own subnet that has the range 192.168.87.96/30.

So now you need to create the virtual subnet (macvlan) using the command

sudo ip route add 192.168.87.96/30 dev macvlan0

If you use any other subnet it wouldn't make any sense. How else would you get the same address space you described in the ip-range option?

[–] Illuminated_Humanoid@alien.top 1 points 1 year ago

So essentially the last step where you create a virtual subnet is going to be the same CIDR notation as the IP range. Well, I'll be damned, it seems like I lucked out on that one and got it right.

Thanks again. Your method worked great and for some weird reason the other methods out there such as this one and also this one did not work for me. One of the guide creators was also trying to help me, and it just wouldn't work.

God bless 🙏🏼