I'm new to Docker and looking for a way to reduce the amount of physical hardware needed for industrial clients. We currently use ThinManager to deliver containers to dedicated users, including both users who can write to a web application and users who only monitor it.
The application relies on client IP addresses for access control. When several Firefox containers run on the same Docker host, the application sees all sessions as coming from the host's IP because of Docker's default NAT behavior.
Would an ipvlan or macvlan network be the best approach for assigning each container a unique address visible on the physical network? For example, if the host uses 1.2.3.4, could the containers use addresses such as 1.2.3.5, 1.2.3.6, and so on? Users would connect to the hosted Firefox sessions through a browser or VNC from devices already connected to the 1.2.3.x network.
3 Answers
A browser-session platform such as Kasm could be worth evaluating. It is designed to provide isolated browser or desktop sessions to users and may be more maintainable than managing a large collection of Firefox containers, individual LAN addresses, and VNC connections yourself.
Before changing the network design, verify whether the application truly requires unique source IPs. Most web applications can handle many simultaneous sessions from one address. If this is based on IP allowlisting or similar access control, consider whether user authentication, per-session authorization, or a reverse proxy would be safer and easier to maintain.
The requirement is effectively IP allowlisting, so the application currently distinguishes clients by their source address. I’ll also investigate whether the access-control design can be changed instead of depending entirely on separate container IPs.
An ipvlan or macvlan network can provide this setup. Docker normally NATs container traffic through the host, so the application sees every Firefox session as coming from the same address. With ipvlan or macvlan, each container can receive its own address on the LAN, such as the host at 1.2.3.4 and containers at 1.2.3.5 and 1.2.3.6. For a larger industrial deployment, ipvlan may be preferable because it avoids assigning a separate MAC address to every container and can be easier on the network.
That looks promising. I hadn’t considered a platform built specifically for delivering isolated browser sessions, so I’ll compare it with the ipvlan approach.