Asymmetric Routing Failure When Combining Traefik and Cloudflare WARP, and Packet Trajectory Correction via PBR

Wed, 21 Oct 2026 10:10:07 +0900

In infrastructure running multi-homed configurations or tunneling clients on the same host, discrepancies between inbound and outbound communication paths (asymmetric routing) represent failure factors that are difficult to detect. In particular, in designs that expose services externally via containerized reverse proxies while encapsulating outbound traffic from the same host in private tunnels or VPNs, kernel routing decisions typically overwrite the default gateway, resulting in lost SYN-ACK responses to clients.

This document traces a packet delivery failure caused by routing policy conflicts between a Traefik proxy deployed on a Docker bridge network and a Cloudflare WARP client, and records the verification process of enforcing localized routing tables using Policy-Based Routing (PBR).

Failure Overview and Inbound Path Verification

An issue occurred where external HTTPS requests to a Telegram-integrated clipboard web service (copy.ds2qgd.dedyn.io) suddenly timed out (ERR_CONNECTION_TIMED_OUT). To isolate container process downtime and upstream application anomalies, each layer of the inbound pipeline was inspected individually.

DNS Resolution: Verified that the FQDN properly pointed to the public WAN IP address of the host environment.
Container Application Layer: Confirmed that the backend web service container was running and returning HTTP 200 responses via local sockets.
Reverse Proxy Layer (Traefik): Verified that the container runtime, dynamic routing definitions, Let’s Encrypt TLS certificate store, and port bindings were operating normally.
Netfilter / Firewall Layer: Verified that iptables DNAT rules generated by the Docker engine and FORWARD ACCEPT configurations within the DOCKER chain were normal. Port TCP 443 was also explicitly allowed in host-side UFW.
Physical Interface Verification: Packet capture performed on the host physical NIC (enp4s0) confirmed that incoming TCP SYN packets from external clients reached the edge router and host NIC.

[Client] ---&gt; (TCP 443 SYN) ---&gt; [enp4s0 (Host)] ---&gt; [iptables DNAT] ---&gt; [br-77da1b8f5618] ---&gt; [Traefik 172.20.0.11]

At this stage, inbound traffic was confirmed to reach the proxy container normally, identifying that packet drops or routing loss were occurring on the reverse path (egress) side.

Root Cause: Egress Asymmetric Routing via Cloudflare WARP

An investigation of the routing policy table of Cloudflare WARP running on the host revealed that the kernel’s default return path was being intercepted by the WARP virtual tunnel interface (CloudflareWARP).

Failure Mechanism

Expected Normal Path: Traefik container (172.20.0.11) $\rightarrow$ Docker bridge (br-77da1b8f5618) $\rightarrow$ Host network stack $\rightarrow$ Physical NIC (enp4s0) $\rightarrow$ Local gateway (192.168.1.1) $\rightarrow$ Client
Actual Deflected Path: Traefik container (172.20.0.11) $\rightarrow$ Host network stack $\rightarrow$ Cloudflare WARP Virtual Interface $\rightarrow$ WAN

For TCP sessions arriving from external clients via the physical NIC (enp4s0), server SYN-ACK responses were dispatched externally via the WARP tunnel. Consequently, packets were dropped on the client side and intermediate paths due to source IP address mismatches (NAT inconsistency) or stateful firewall classification as invalid packets, leading to connection timeouts.

Workaround Verification and Policy-Based Routing (PBR) Implementation

Evaluation and Rejection of CONNMARK Alternative

As an initial test, a configuration was evaluated that applied a Netfilter connection mark (CONNMARK 0x80000) to incoming packets on TCP port 443 and bypassed WARP rules using policy routing based on fwmark. However, due to priority conflicts with the high-priority routing rules registered by WARP, return packets for established sessions could not be deterministically routed to the physical interface. To prevent configuration drift, this Netfilter rule was promptly rolled back.

Surgical Route Enforcement via PBR (Policy-Based Routing)

Precise routing rules were applied to force only HTTPS return traffic from Traefik to the physical gateway (the main table), while keeping all other host and container traffic routed via WARP.

Target Parameters

Source IP address: 172.20.0.11 (Traefik internal container IP)
Ingress bridge interface: br-77da1b8f5618
Protocol and source port: TCP, sport 443
Referenced routing table: main (Standard table with physical gateway 192.168.1.1)

sudo ip rule add from 172.20.0.11 iif br-77da1b8f5618 ipproto tcp sport 443 table main priority 1000

```yaml

Troubleshooting

本構成を本番運用に組み込む際、以下の摩擦点（Friction Points）に対する対処が必要です。

1. 動的評価スクリプトによる判定の偽陰性（False-Negative）

ルーティング適用確認時、ip route getの出力文字列を単純な正規表現でパースしていた検証スクリプトにおいて、出力順序の微細な変化を検知できず異常終了（FAIL）と判定される事象が発生しました。検証機構を自動化する際は、テキストマッチングに過度に依存せず、カーネルの戻り値判定および実際のパケットキャプチャを併用する必要があります。

2. ホスト再起動時のルール揮発対策

ip ruleコマンドで動的に追加したポリシーはカーネルランタイムメモリにのみ保持されるため、ホスト再起動やネットワークデーモンのリロードで消失します。永続化のためには、Netplanまたはsystemd-networkdの設定ファイル、あるいはコンテナ起動前のネットワークフックスクリプトに組み込む必要があります。

検証結果とプロトコルログ

ルーティングルールの適用後、ルーティングサブシステムに対するクエリおよび外部セルラー回線経由でのエンドツーエンド通信テストを実施しました。

ルーティング照合ログ

パケットキャプチャおよびハンドシェイク検証

外部モバイルネットワーク（WAN）からhttps://copy.ds2qgd.dedyn.ioへアクセスし、ホスト物理NIC（enp4s0）上でtcpdumpを実行しました。

外部クライアントとの間で3ウェイハンドシェイク（SYN $ ightarrow$ SYN-ACK $ ightarrow$ ACK）、TLSデータ転送、および正常なセッション終了（FIN-ACK）が物理NIC（enp4s0）上で完結し、パケットドロップが0件であることが実証されました。

Operational Notes

オーバーレイネットワークや常時稼働型トンネルクライアント（WARP、Tailscale、WireGuard等）がホスト上で動作している場合、ルーティングの決定権がトンネル側に偏向するリスクを常に考慮する必要があります。接続タイムアウトが発生した際は、アプリケーションログの調査やプロキシの再起動を無作為に繰り返すのではなく、tcpdumpを用いて物理インターフェースにおける往復パケットの到達状況を切り分け、戻り経路の非対称性を診断することが迅速な復旧につながります。

Policy-Based-Routing on K-Life Hack | Systems Architecture & DevOps