fix: register TCPClientTunnel BindAddress as landlock.BindTCP, not ConnectTCP - #219
Merged
Merged
Conversation
…nnectTCP TCPClientTunnel listens on BindAddress (net.ListenTCP), but lockNetwork() registered it as a landlock.ConnectTCP rule instead of landlock.BindTCP. On kernels supporting Landlock network ABI v4 (Linux 6.7+), this makes wireproxy's own Landlock self-sandboxing deny its own bind() on BindAddress, regardless of host environment. Fixes windtf#218
CatDonIO
pushed a commit
to CatDonIO/wireproxy-awg
that referenced
this pull request
Aug 14, 2026
Brings in everything from the base project up to v1.1.3: - SNI (transparent TLS) proxy section (windtf#210) - bare WGConfig filenames are resolved relative to the parent config dir (windtf#204) - landlock: TCPClientTunnel BindAddress is now BindTCP, not ConnectTCP (windtf#219) - landlock: TLS cert/key files are added to the allowed read paths (windtf#213) - dependency bumps (x/net 0.55.0, x/crypto 0.52.0, x/sys 0.45.0) Conflicts resolved in favour of the fork: - go.mod/go.sum keep amneziawg-go and drop the direct golang.zx2c4.com/wireguard dependency; every shared dependency takes the newer of the two versions - cmd/wireproxy/main.go keeps the wireproxyawg import alias and takes the upstream landlock fix - README keeps the fork feature list and install path, and adds the SNI section The upstream sponsor blocks (IPCook affiliate banner, DigitalOcean credits) and assets/ipcook.png are not carried into the fork - they point at the base project's referral code and sponsorship, which do not apply here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
TCPClientTunnellistens onBindAddressvianet.ListenTCP(routine.go), butlockNetwork()incmd/wireproxy/main.goregistered its Landlock rule aslandlock.ConnectTCPinstead oflandlock.BindTCP— the only listening routine type that got the wrong rule (HTTPConfig,Socks5Config,SNIConfigall correctly useBindTCP).Why it matters
On kernels supporting Landlock network ABI v4 (Linux 6.7+, Jan 2024),
landlock.V4.BestEffort().RestrictNet(rules...)actually enforces these rules. SinceTCPClientTunnel's own bind was never allowlisted as a bind, the kernel denies wireproxy's ownnet.ListenTCPcall onBindAddress:This reproduces on any host/platform once the kernel is new enough — independent of Docker, cloud platform, or any external sandboxing. Full writeup with reproduction and control test in #218.
Fix
One-line: swap
ConnectTCPforBindTCPfor theTCPClientTunnelConfigcase, matching the pattern used by every other listening config type.Verified
go build ./...andgo vet ./...pass. Manually verifiedTCPClientTunnelbinds and accepts connections again after this change, on a host that previously reproduced the bug 100% of the time.Fixes #218