Container Traffic Support for Linux
Learn how Prisma Agent enforces Forwarding Profile policies on
container traffic on Linux endpoints.
| Where Can I Use This? | What Do I Need? |
- Prisma Access (Managed by Strata Cloud Manager)
- Prisma Access (Managed by Panorama)
- NGFW (Managed by Panorama)
|
- Check the prerequisites for the deployment you're using
- Linux endpoints
- Contact your Palo Alto Networks account representative to activate the Prisma Agent feature
|
Container Traffic in Release 26.3 and Later
Starting with release 26.3, Prisma® Agent enforces Forwarding Profile policies on
Docker container traffic on Linux hosts using eBPF (extended Berkeley Packet Filter) kernel
hooks. This requires Linux kernel 5.11 or later. eBPF enforcement covers every
process, container, and network namespace on the host without requiring per-container
configuration.
Container traffic follows the same Forwarding Profile rules as host traffic. The
agent evaluates each container connection and assigns one of the following verdicts:
Tunnel, Direct,
Block, or Best Available - Fail
Safe. Docker container networks don't need to exist before the agent
starts.
Considerations
Forwarding Profile rules that match by application name don't apply to DNS
queries that containers route through systemd-resolved or Docker's internal
resolver. Domain-based DNS rules work as expected.
Blocked DNS queries time out rather than returning an immediate error.
IPv6 traffic from containers can be blocked or allowed direct, but isn't
steered through the tunnel.
Explicit proxy is not enforced on Linux.
Container Traffic in Release 26.2 and Earlier
Prisma Agent for Linux provides support for Docker container traffic,
so developers and DevOps engineers can maintain containerized workflows without
losing tunnel connectivity. When the agent is connected, it automatically detects
Docker bridge network subnets and routes all outbound container traffic through the
tunnel, where Prisma Access security policy controls access.
How It Works
Prisma Agent supports Docker traffic in the following ways:
Dynamic Subnet Detection
The agent automatically identifies the subnets associated with Docker bridge
networks (for example, 172.17.0.0/16) and injects the
appropriate routes when the tunnel is established.
Bridge Network Enumeration
Support extends beyond the default docker0 interface to all
user-defined bridge networks, which are typically prefixed with
br-.
Policy-Driven Routing
All outbound container traffic is intercepted and routed through the Prisma Agent tunnel. The Prisma Access security policy then
controls access using Allow or Block rules.
DNS Integration
Containers use the host's DNS settings, which are managed by the agent's
forwarding profiles, ensuring internal resources are resolvable.
Considerations
Keep the following in mind when using Docker container traffic support on Linux
endpoints:
Custom Docker Networks Must Exist Before Connecting to the Tunnel
The agent injects routes at tunnel startup based on the bridge networks that
exist at that time. Networks created after the tunnel is established will not
have their routes injected automatically.
Docker Traffic Is Restricted to the Tunnel
Routing Docker container traffic through physical interfaces is not supported.
Configure a forwarding rule with a Block connectivity
option if you need to prevent Docker traffic from reaching the tunnel.
Block Rules for the Default Bridge Network Apply Only When the Tunnel Is
Active
If the tunnel is not connected, Block rules for the default Docker bridge
network (docker0) are not enforced.
Use tcpdump for Network Diagnostics
For troubleshooting Docker container network traffic, use
tcpdump for packet analysis rather than
pacli commands.