T-Pot Deployment on VLAN: Containers Running but Host Becomes Inaccessible

[Fujimaru-Kun]

Hi Team,

I'm looking for guidance regarding a T-Pot deployment issue in a VLAN-segmented environment.

Our initial Proof of Concept (POC) deployment was successful when the T-Pot server was connected directly to a standard network without any VLAN configuration. All services, including the T-Pot Web UI and SSH access, worked as expected.

However, during production deployment, the server was assigned to a dedicated VLAN (e.g., VLAN 222) with a private /24 subnet. The installation completed successfully, and all Docker containers started normally after running the T-Pot customizer script. Despite the containers running, the server itself became inaccessible:

• T-Pot Web UI is unreachable
• SSH access is unavailable
• Even the ports modified during the installation process are no longer accessible

Interestingly, once all T-Pot containers are stopped, normal access to the server is immediately restored, including SSH and web management access.

Our target design is to eventually monitor multiple internal VLANs. However, we are currently testing with only a single VLAN before expanding to additional VLANs. This deployment is intended for an internal environment only and will not be exposed directly to the public Internet.

A few questions:

1. Does T-Pot automatically modify routing tables, iptables/nftables rules, Docker bridge networks, or other networking settings that could interfere with a VLAN-assigned interface?
2. Are there any known issues or special considerations when deploying T-Pot in a dedicated VLAN environment?
3. Is there a recommended method for defining custom Docker bridge networks, subnets, or interface bindings when the host is connected to a VLAN?
4. Would any modifications to the generated Docker Compose files or Docker network configuration be required for this type of deployment?
5. Based on the documentation screenshot below, the available customization options appear to be focused on selecting honeypots and services. I could not find any documentation related to customizing Docker network ranges, bridge networks, VLAN-related settings, interface bindings, or host subnet assignments. Is networking customization supported, and if so, where is it intended to be configured?

Since the deployment works correctly without VLAN configuration but becomes inaccessible once T-Pot is deployed on a VLAN, we are trying to determine whether additional T-Pot, Docker, or host networking configuration is required.

Any insights, recommendations, or similar experiences would be greatly appreciated.

Thank you.

[Fujimaru-Kun]

Hi any update on this. Thank You.

[t3chn0m4g3]

@Fujimaru-Kun There is way too many possibilities depending on your setup and config to provide any other recommendations as I already provided. As a quick resolve you can adjust the ~/tpotce/docker-compose.yml and remove the honeytrap service. tpotinit will notice this and omit the NFQ based firewall rule setup - in turn your VLAN setup should work.

[Fujimaru-Kun]

Hi @t3chn0m4g3 ,

Thank you for your response.
We would like to clarify the Docker networking configuration used by T-Pot.

Based on the current configuration, multiple Docker networks are defined for the honeypot services. Could you please confirm whether the subnets for these Docker networks are automatically assigned by Docker, or if specific subnets are manually configured?

If they are manually configured, could you kindly provide the subnet details being used? We would like to verify whether there are any subnet overlaps or routing conflicts that may be contributing to the issue we are currently investigating.

Thank you for your assistance.

[t3chn0m4g3]

@Fujimaru-Kun By default everything is automatically assigned with docker defaults which may still collide with your network config. More info on that topic can be found here.

[Fujimaru-Kun]

Hi @t3chn0m4g3 ,

We have completed the troubleshooting and would like to share the latest results:

1. The Honeytrap service has been successfully removed.
2. However, the T-Pot Web UI remains inaccessible, and the issue has not yet been resolved.
3. The server is now accessible via SSH, although the connection is experiencing some noticeable lag.
4. Server resource utilization appears to be normal, with no abnormal CPU, memory, or system load observed at this time.

At this point, removing Honeytrap restored SSH access to the server, but it did not resolve the Web UI accessibility issue.

We would appreciate any recommendations on what component or logs we should investigate next to determine why the Web UI remains unavailable.

Thank You.

[t3chn0m4g3]

Thanks for the additional details and screenshots.

From what we can see, this does not look like a generic T-Pot issue, but rather like an interaction between the local Docker networking setup, the VLAN design, and the T-Pot compose stack.

T-Pot creates a larger number of Docker networks for the individual honeypot and management components. In such an environment, Docker bridge subnet allocation can run into conflicts with already existing routes, VLANs, VPN networks, or previously created/stale Docker networks. The error message all predefined address pools have been fully subnetted points in that direction and should be investigated first by checking docker network ls, docker network inspect, ip route, and the configured Docker default-address-pools.

The fact that SSH became reachable again after removing Honeytrap also indicates that Honeytrap/NFQUEUE may have contributed to the original management access problem. However, if the WebUI is still not reachable and tpot.service fails during Docker network creation, then the remaining issue is most likely not the WebUI itself, but the Docker network/IPAM setup underneath it.

In a VLAN-based deployment it may also be worth reviewing whether Docker’s default bridge networking is the right fit for this environment. Docker’s IPvlan driver is specifically designed for integrating container networks with existing physical/VLAN networks, including 802.1Q trunk scenarios and explicit parent interfaces, and may therefore be relevant for this type of setup:

https://docs.docker.com/engine/network/drivers/ipvlan/

At this point, this appears to be a setup-specific networking/IPAM issue in the local environment. Unfortunately we have no means to reproduce the reported behavior with our limited test environments. For the typical T-Pot installation we currently have no indication of a general T-Pot issue.

[Ganesh-403]

@Fujimaru-Kun
From the additional information you've shared, I think the maintainer's assessment is pointing in the right direction.

The key observations are:

• Removing Honeytrap restored SSH access, which suggests the original management connectivity issue was at least partly related to Honeytrap's NFQUEUE-based firewall rules intercepting traffic.
• However, the Web UI is still unreachable, so the remaining problem is likely separate from Honeytrap itself.
• You also mentioned seeing Docker errors such as "all predefined address pools have been fully subnetted", which is a strong indicator that Docker's networking/IPAM configuration deserves attention before investigating the Web UI. Docker automatically allocates bridge network subnets from its default address pools, and those pools can conflict with existing VLANs, VPNs, or previously created Docker networks if not configured appropriately. :contentReference[oaicite:0]{index=0}

At this point, I'd recommend checking the Docker networking state rather than the T-Pot services themselves.

Some useful commands would be:

docker network ls
docker network inspect <network_name>
docker info | grep -A5 "Default Address Pools"
ip route
ip addr
docker ps
journalctl -u docker
journalctl -u tpot

In particular, look for:

• overlapping subnets between Docker bridge networks and your VLAN(s)
• stale Docker networks that may be consuming address pools
• failures while creating Docker networks during tpot.service startup
• routing entries that unexpectedly point traffic toward Docker bridges

If the Docker address pools are exhausted or overlap with your infrastructure, configuring Docker's default-address-pools in /etc/docker/daemon.json is the usual way to avoid those conflicts. Docker documents both the default behavior and how to customize these pools. :contentReference[oaicite:1]{index=1}

Since your deployment is intentionally VLAN-based, it's also worth considering whether Docker's default bridge networking is the best fit. Docker provides an IPvlan network driver specifically for integrating containers with existing Layer 2/VLAN networks, including 802.1Q tagged interfaces via -o parent=<interface>.<vlan>. Whether T-Pot can easily be adapted to use IPvlan depends on its compose stack, but it is the Docker networking model designed for this type of environment. :contentReference[oaicite:2]{index=2}

One question that would help narrow this down:

• Does docker ps show the Web UI container (NGINX) as healthy/running, and if so, can you access it locally from the host (for example using curl https://localhost) even though it isn't reachable over the VLAN?

That would help determine whether this is:

1. a Docker/IPAM routing issue,
2. a host firewall/NAT issue, or
3. the Web UI service itself failing to bind correctly.

If this solves your problem, feel free to mark it as the accepted answer so others can find it easily.

[goodingr]

Just wanted to add a confirmed root cause + fix for this exact symptom (containers running → host completely inaccessible via SSH/WebUI/all forwarded ports → stopping containers immediately restores access), since I hit it myself on a fresh VLAN-segmented deployment (TP-Link Omada router, dedicated /24 VLAN for the honeypot).

Root cause: check ip route on the host and look closely at the subnets assigned to T-Pot's Docker bridge networks. In my case:

192.168.0.0/20 dev br-35d6a265edc5 proto kernel scope link src 192.168.0.1

That 192.168.0.0/20 Docker bridge subnet fully contained my actual main LAN's subnet (192.168.0.0/24). T-Pot creates ~25 separate Docker networks (one per honeypot/component), which is more than Docker's default address pool of 15 blocks (172.17.0.0/16–172.31.0.0/16) can cover. Once that default pool is exhausted, Docker silently falls back to carving subnets out of 192.168.0.0/16 — and if your real network happens to live anywhere in that range (extremely common for home/SMB routers), Docker can allocate a bridge subnet that directly overlaps it.

Why this breaks all connectivity, not just to specific containers: on Linux, a directly-connected route (like a local Docker bridge) always takes priority over sending traffic out through the default gateway for anything matching its subnet. So once that overlap exists, the host's kernel routes any reply destined for an address in that range (including your actual router, your actual management PC, everything on your real LAN) into the fake local Docker bridge instead of out through the real network interface. Packets look like they're received fine (inbound routing isn't affected), but the replies vanish into the wrong bridge — which matches the "containers running = host unreachable" symptom precisely.

The fix: give Docker a custom address pool that can't overlap with your actual network(s), sized generously enough that it'll never need to fall back into 192.168.0.0/16 again:

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<'EOF'
{
  "default-address-pools": [
    {"base": "10.10.0.0/16", "size": 24}
  ]
}
EOF
sudo systemctl restart docker

Then do a full clean reinstall of T-Pot (uninstall.sh if available, or manually stop/remove all containers + docker network prune + docker system prune -a --volumes -f, then re-clone and run install.sh again) so all its networks get recreated fresh under the new pool.

After that, ip route showed all T-Pot's bridges on 10.10.x.x addresses with zero overlap with either of my VLANs, and connectivity has been rock-solid since — no more cyclical drops, no more host lockout with containers running.

Might be worth calling out in the docs that anyone deploying on a non-default LAN range (especially 192.168.0.0/16-based ones, which is most home/SMB gear) should proactively check ip route for Docker bridge overlaps and configure default-address-pools before running install.sh, rather than discovering it after the fact.