Website Redirects not working when containerizing Docker

Hello everyone,
I’m currently in the middle of moving some infrastructure to containers from a ton of VM’s running simple things.

I’m trying to move our pihole DNS server to a container. All was working well, until I was alerted that one of our website redirects was not working correctly. One of our providers has a requirement to redirect all external traffic to a login page, and anyone who is on our subnet can go straight to the desired webpage. Our staff and public access pc’s that are on our subnet are being redirected to the login page when they should not. Turning the container off, and the VM back on, the redirect starts working again. So, I am assuming the issue is with how Docker handles networking.
Some context, I am running the container on macvlan, so that pihole is on our physical network, and not using the docker host IP. Not my choice … More of a requirement by my organization :roll_eyes:
Piholes settings on both the VM and container are exactly the same. I have triple checked this and had someone look over it.
Lets say the physical lan is 10.0.0.0/24
my docker network:

sudo docker network create --config-only --subnet 10.0.0.0/24 --gateway 10.0.0.1 -o parent=eth0 --ip-range 10.0.0.0/26 --aux-address 'host=10.0.0.10' my_macvlan_config
sudo docker network create -d macvlan --config-from my_macvlan_config --attachable my_macvlan_network
sudo ip link add macvlan_shim link eth0 type macvlan mode bridge
sudo ip addr add 10.0.0.10/32 dev macvlan_shim
sudo ip link set macvlan_shim up
sudo ip route add 10.0.0.0/26 dev macvlan_shim

docker host is 10.0.0.7
pihole(container) is 10.0.0.3
Our apache2 server’s redirect looks like this, incase it helps:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^10\.0\.
RewriteCond %{REMOTE_ADDR} !^[REDACTED]
RewriteCond %{REMOTE_ADDR} !^[REDACTED]
RewriteCond %{REMOTE_ADDR} !^[REDACTED]
RewriteRule [REDACTED]\.html$ https://[REDACTED]

Everything seems to be working fine, DNS resolution, adblocking, etc. Only the website redirect is failing when using the container instead of the VM. Is there something with docker networking that could be causing issues?
Thank you in advance!

1 Like

What does “failing” means here? Not doing anything or trying to redirect and shows an error message?

I don’t think “networking” has anything to do with HTTP redirection. Unless of course you an show an error message which confirms it.

My guess would be that your configuration in the Apache container is wrong and AllowOverride is not set to All or mod_rewrite is not enabled at al.

Sorry! I forgot to explain the redirect… Ill edit my original post as well.

As a requirement from one of our providers, we have to redirect people who are physically on our lan to a login catalog page, anyone who is physically on our subnet can access it directly without needing to go through the log in page.
So by failing, I mean its causing a redirect to the login page from computers on our LAN. I’m lead to believe its something to do with docker or pihole? since when I turn off our pihole docker container, and turn back on our pihole VM, the redirect does not redirect machines that are on our subnet.

Try to check what remote IP the container can see. Unless your container is behind a reverse proxy, it should see the same remote IP as the VM. I never use macVLAN, but I don’t know why that would work differently.

If I remembr correctly, Apache HTTPD can show information about applied rewrite rules
https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html

Probably with “trace8”.

In test environment I used to test rewrite rules by including the variables in the destination URL’s query string.

1 Like

I can’t speak about the apache2 redirect behavior. but are you sure you configured the macvlan properly?

Did you add any already taken ips in the specified ip range 10.0.0.0/26 (=10.0.0.0 - 10.0.0.63) as --aux–address? For instance, the router seems to be within that range, and is not added as --aux-address.

You added a bridge for a macvlan shim, and specified it as --aux-address, which is good. Furthermore, you added a route for the ip-range through the bridge, which allows the host to workaround the kernel security restriction that prevents direct communication between macvlan parent ↔ child interface. I assume you know that containers in the macvlan network need to use the bridge ip to communicate with the host (communication to the macvlan parent interface is still forbidden!)

I have double checked that the aux-address is set is not currently being used by any of the machines on our subnet. We specifically set the DHCP for our DC to hand out addresses in the 10.0.0.64/26 range, everything else is statically set. I believe macvlan is configured correctly.

I am not sure whether the router ip needs be added as --aux-address as well, as I never had a macvlan that used a range in the beginning of the subnet.