ProxyBridge 4.1.0-Beta Kernel Driver

[Anof-cyber]

ProxyBridge 4.1.0-Beta - Tester Release

This is an experimental tester build. It replaces the WinDivert packet-capture engine with a
custom Windows Filtering Platform (WFP) kernel driver (ProxyBridgeDrv.sys). We are releasing
it only to gather feedback and to evaluate whether ProxyBridge should move from WinDivert to its
own driver.

Download - ProxyBridge-4.1.0-Beta.zip

---

⚠️ Read this first - this build ships a kernel driver

This release includes a kernel-mode driver that is still under test. Please understand what
that means before you install it:

• A bug here is not an app crash - it is a system crash. Kernel code runs with full system
  privileges. A defect can bring down the entire machine with a BSOD (Blue Screen of Death),
  not just close ProxyBridge.
• Test on a VM or a dedicated test machine only. Do not run this on your production,
  work, or daily-driver system.
• If you are not comfortable with Test Mode or kernel-driver risks, do not test this build.
  Wait for a stable, signed release instead.

---

What's new in 4.1.0-Beta

• Custom WFP driver instead of WinDivert. The driver has been in planning and development for
  months. It is a test / proof-of-concept, not intended for production or real-world use yet.
• It intercepts connections at the WFP layer (redirect + monitor callouts) rather than mangling
  packets, and has been aligned with ProxyBridge: same features - IPv4 + IPv6, TCP + UDP,
  proxy / direct / block rules, domain rules, and full connection logging.
• Goal of this beta: find out how the custom driver behaves in the wild and decide whether it
  is a viable replacement for WinDivert.

---

How it works vs WinDivert

WinDivert works at the packet level: it pulls every network packet up into user mode, works out
which process and destination it belongs to, rewrites it, and re-injects it. The custom driver
works at the connection level using WFP: when a watched app opens a connection, the kernel
redirects that connection to ProxyBridge and hands over the process ID and the original destination
directly - no packets are copied or rewritten.

	WinDivert	ProxyBridgeDrv (WFP)
Works on	Every packet (network layer)	Each connection (ALE layer)
Finds the app (PID)	Scans the OS connection tables	Delivered by Windows with the connection
Original destination	Reconstructed from source port (can collide)	Handed over by Windows exactly
Per-packet work	Copy -> rewrite -> re-inject in user mode	None - the kernel routes it natively
Non-proxied traffic	Still passes through the user-mode loop	Untouched in the kernel (no overhead)
Blocking	Drops packets in the loop	Kernel refuses the connection
Net effect	Works, but heavier and more error-prone	Lighter, fewer moving parts - what we're testing

What stays the same for you: the behaviour you already know - proxy / direct / block rules,
IPv4 + IPv6, TCP + UDP, domain rules, and the full connection log. Only the capture mechanism
underneath changes; the WFP approach is closer to how tools like Proxifier work.

One difference you may notice: every connection now shows in the log - including apps talking to
localhost - so you can see and write rules for local traffic too. Only ProxyBridge's own
internal hops are hidden.

---

Driver signing status - why Test Mode is required

The driver is not EV code-signed. Windows requires an EV (Extended Validation) certificate
for kernel drivers, plus Microsoft attestation / WHQL submission and review, before a driver
will load normally.

Because this driver is still experimental and unverified, we have not EV-signed it or
submitted it for Microsoft verification. To load an unverified driver, Windows must be put into
Test Mode (test-signing).

---

Requirements

• A virtual machine or spare/test PC running Windows 10/11 x64 - never a production system.
• Administrator access.
• Secure Boot turned OFF (Test Mode is ignored while Secure Boot is on).

---

Steps to test

1. Enable Test Mode

On the test machine, in an elevated Command Prompt / PowerShell:

bcdedit /set testsigning on
shutdown /r /t 0

After the reboot you will see a "Test Mode" watermark in the bottom-right corner - that
confirms it is active.

2. Get the build

Copy the provided package to the test machine. It contains:
ProxyBridge.exe, ProxyBridgeCore.dll, ProxyBridge_CLI.exe, ProxyBridgeDrv.sys,
ProxyBridgeDrv-test.cer (the driver's test certificate), and the installer.

3. Trust the driver's test certificate

The driver is signed with a self-signed test certificate. Import it so Windows trusts it - in an
elevated PowerShell, from the folder with the files:

Import-Certificate -FilePath .\ProxyBridgeDrv-test.cer -CertStoreLocation Cert:\LocalMachine\Root
Import-Certificate -FilePath .\ProxyBridgeDrv-test.cer -CertStoreLocation Cert:\LocalMachine\TrustedPublisher

4. Install / run

Run ProxyBridge.exe as Administrator directly.
The app installs and starts the ProxyBridgeDrv kernel service on demand.

5. Verify the driver loaded

sc.exe query ProxyBridgeDrv

Expect STATE : 4 RUNNING.

6. Try it

Add a proxy, add a rule (e.g. a browser or curl.exe → Proxy), and confirm traffic routes
through the proxy and appears in the connection log.

---

Reverting after testing

sc stop ProxyBridgeDrv
sc delete ProxyBridgeDrv
bcdedit /set testsigning off

Then reboot. (The uninstaller also stops and removes the driver service.)

---

Feedback

Please report: whether the driver loaded, whether TCP / UDP / IPv6 proxying and logging worked,
and - most importantly - any instability, hangs, or BSODs, along with your Windows version and
what you were doing at the time.

This is a beta of experimental kernel code. Thank you for testing carefully, and only on a machine
you can afford to crash.

[dentatli]

ProxyBridge eBPF for Windows — Final Testing Summary

Executive summary

I completed the eBPF proof-of-concept investigation on Windows 10.

The PoC successfully demonstrated:

• process-aware policy selection;
• reliable eBPF load, attach, detach, and cleanup;
• DIRECT and BLOCK decisions;
• transparent TCP proxying through a user-mode relay;
• preservation and forwarding of WFP TCP redirect records;
• UDP request-side redirection and forwarding to the original destination.

The PoC did not provide transparent UDP response delivery.

The UDP relay successfully forwarded the request to the original server and received the response, but the client observed the relay endpoint as the response source:

Expected source: 127.0.0.1:20005
Actual source:   127.0.0.1:19090

This is not a test-harness error. It is an architectural limitation of the current design.

The user-mode relay returns the datagram through a socket bound to 127.0.0.1:19090, so Windows uses that socket's local endpoint as the UDP source. WFP redirect records do not automatically perform reverse-path NAT for the response. Restoring the original source IP and source port would require a kernel-mode WFP reverse-path packet modification and reinjection mechanism, together with per-flow state.

For that reason, I consider the eBPF investigation complete. Extending the PoC further would effectively require implementing a custom WFP driver path, which is already the architectural direction of ProxyBridge 4.1.0-Beta.

Test environment

• Windows 10 Pro 22H2, build 19045, x64
• VirtualBox VM
• Test Signing enabled
• eBPF for Windows pinned commit:
  390745d7b5825bf2d7262e17226eeae5522627ae
• eBPF for Windows product version: 1.5.0
• Windows SDK: 10.0.22621.0
• Visual Studio 2026 Developer PowerShell / MSBuild 18.8.2

Final tested TCP relay artifacts:

tcp_relay.cpp SHA-256:
CA2D192BAEE5DF7BFCC2FD5762BBEBE60C23F5F77E829D295BC2C1542C7606AF

probe_tcp_relay.exe SHA-256:
FFCBD1CFA0E8B9C79ED2FD6F1E2EF13C6B87105FCC24ADBF1078A404CD58D036

Confirmed results

Test area	Result
eBPF build, installation, and load	PASS
Program attach and detach	PASS
Safe cleanup	PASS
Run-state schema and race protection	PASS
Process identity and policy audit	PASS
DIRECT IPv4 TCP	PASS
BLOCK IPv4 TCP	PASS
TCP PROXY IPv4	PASS
TCP redirect-record query and forwarding	PASS
UDP request-side redirect and forwarding	PASS
UDP reverse source transparency	FAIL — architectural limitation
Connected UDP	NOT RUN
Final IPv6 smoke matrix	NOT RUN
Deterministic issue #209 test	NOT RUN
Deterministic issue #206 test	NOT RUN
Long stability repetitions	NOT RUN
Performance comparison	NOT VALID

TCP proxy result

The initial TCP relay implementation queried
SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS with a null output buffer.

On the tested Windows 10 provider this failed with:

WSAEFAULT 10014

The query was changed to use:

• an initial 1,024-byte buffer;
• ERROR_INSUFFICIENT_BUFFER as the normal resize condition;
• a 64 KiB upper bound;
• one bounded retry;
• SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS before the upstream connect().

The final runtime evidence confirmed:

redirect_records_size=782
query_result=0
set_result=0
upstream_connect_result=0
redirect_records_forwarded=true

The TCP payload test then passed.

UDP result

The final UDP test confirmed:

policy_id=1005
action=PROXY
original_destination=127.0.0.1:20005
redirect_records_present=true
redirect_records_size=782
WSASendMsg result=0
redirect_records_forwarded=true

The payload returned successfully, but the client saw:

response_source=127.0.0.1:19090
expected_response_source=127.0.0.1:20005

The reverse path in the current relay uses a normal sendto() call on the relay listener. Since that socket is bound to port 19090, the response source is necessarily the relay endpoint.

IP_PKTINFO can select a source address or interface, but it does not provide arbitrary per-packet UDP source-port replacement. The pinned eBPF receive-side hook also does not expose the packet modification and reinjection capability required to restore the original source tuple.

A complete transparent solution would require:

• kernel-mode WFP callouts;
• per-flow UDP state;
• source IP and source port rewriting;
• receive-path reinjection;
• loop prevention for self-injected packets;
• IPv4 and IPv6 handling;
• timeout, process-exit, and port-reuse cleanup.

Important limitations

The following conclusions must not be drawn from this test phase:

• issue [Bug]: [Windows] connection_hash_table identifies flows by source port only, causing TCP/UDP collisions and skipped rules #209 was not reproduced or ruled out in this eBPF runtime;
• issue [Windows] Proxy rules stop being applied after hours of uptime: stale port-decision cache leaks traffic direct #206 was not reproduced or ruled out;
• connected UDP was not validated;
• the full IPv6 proxy matrix was not completed;
• the PoC was not subjected to a 10-run or 100-run stability campaign;
• single-request smoke timings are not performance benchmarks;
• this does not prove that eBPF for Windows can never support transparent UDP.

The precise conclusion is narrower:

This specific PoC architecture, using the current pinned eBPF hooks and a user-mode UDP relay, does not provide transparent UDP reverse-path source restoration.

Harness and lifecycle defects fixed during testing

The investigation also found and fixed several test and lifecycle problems:

1. incomplete run-state schema;
2. race conditions while publishing run-state.json;
3. missing ownership and expected-run-ID checks;
4. non-atomic state initialization;
5. unreliable PowerShell child-process exit-code retrieval;
6. missing GetExitCodeProcess fallback;
7. process identity being queried after client termination;
8. $Pid conflicting with PowerShell's read-only automatic $PID;
9. UDP echo server protocol not being normalized correctly;
10. invalid TCP redirect-record sizing call;
11. stale source and binary artifacts being transferred or reused.

These issues are separate from the final UDP architectural limitation.

My assessment and decision

Based on the completed tests, my assessment is that the eBPF approach used in this PoC is not suitable for the required transparent UDP behavior. I therefore decided to conclude the eBPF investigation and move on to isolated testing of ProxyBridge 4.1.0-Beta and its custom WFP driver.

In my view, the WFP beta is best tested in a clean VM clone rather than on top of the installed eBPF runtime, so that the results are not affected by the existing eBPF drivers, services, callouts, or configuration.

The areas I consider most important for the beta test are:

1. install, start, stop, reboot, uninstall, and rollback safety;
2. DIRECT, BLOCK, and PROXY for TCP and UDP;
3. IPv4 and IPv6;
4. unconnected and connected UDP;
5. deterministic issue [Bug]: [Windows] connection_hash_table identifies flows by source port only, causing TCP/UDP collisions and skipped rules #209 test:
   simultaneous TCP and UDP flows using the same numeric local port;
6. deterministic issue [Windows] Proxy rules stop being applied after hours of uptime: stale port-decision cache leaks traffic direct #206 test:
   fresh TCP SYN reusing a previous source port must trigger a new rule lookup;
7. rapid port reuse and process lifecycle;
8. up to 10 repetitions of the key collision and lifecycle scenarios;
9. performance comparison only after correctness passes.

Final conclusion

The eBPF PoC proved that process-aware routing and transparent TCP proxying are viable.

It also identified the boundary of the current design:

• TCP: functional;
• UDP request forwarding: functional;
• transparent UDP reverse path: not available without kernel-mode WFP packet modification and reinjection.

In my view, extending the current user-mode UDP relay would duplicate work that belongs in a kernel-mode WFP implementation. I therefore consider testing the developer's WFP-based beta to be the appropriate next phase.

[Anof-cyber]

Hey can you help me with info for this.
I am not sure how ebpf works is it user mode or kernel mode? Where the packet are tracked and redirected. The WFP version handle all major works at kernel level not sure on ebpf

[dentatli]

Thanks — I should clarify the architecture, because the eBPF PoC was not purely user-mode.

It was a hybrid design.

The eBPF programs ran in kernel mode through eBPF for Windows kernel extensions. They were attached to socket-address hooks such as connect4/connect6 and performed the process-aware policy lookup and the initial destination redirection to a local relay.

The policy identity included information such as:

• PID;
• process start key;
• socket cookie;
• protocol;
• address family;
• original destination.

However, the PoC did not implement a complete kernel-side packet-tracking or NAT engine.

The user-mode part:

• populated the eBPF policy maps;
• registered the relay identities;
• ran separate TCP and UDP relays;
• forwarded the actual application payload to the original destination.

For TCP, this design worked. The user-mode TCP relay received the WFP redirect context, queried and forwarded the redirect records, and then connected to the original destination.

The final TCP runtime result was:

redirect_records_size=782
query_result=0
set_result=0
upstream_connect_result=0
redirect_records_forwarded=true

For UDP, the outbound request path also worked:

• the kernel-side eBPF hook redirected the request to the local UDP relay;
• the relay recovered the original destination;
• the relay forwarded the datagram successfully using the WFP redirect records.

The limitation was the reverse path.

The UDP relay returned the response using its ordinary listener socket, which was bound to 127.0.0.1:19090. Therefore, the client received the correct payload but saw the relay as the source:

Expected source: 127.0.0.1:20005
Actual source: 127.0.0.1:19090

There was no kernel-side reverse NAT or receive-path packet reinjection in this PoC to restore the original source IP and source port.

So the conclusion was not that eBPF itself runs in user mode. The policy decision and initial redirection were kernel-side. The limitation was that this particular PoC used a user-mode relay for payload forwarding and had no kernel reverse-path implementation.

Your WFP version appears architecturally different because the driver handles the main flow tracking and redirection work at kernel level. That is why I decided to stop extending the eBPF PoC and move to testing your WFP implementation.

For the tests, it would help to know:

1. Which WFP layers handle the initial TCP/UDP redirection?
2. Which layer handles the UDP reverse path and source restoration?
3. What fields are used to identify a tracked flow?
4. Does the flow identity include protocol, address family, local endpoint, remote endpoint, and process identity?
5. How are flow entries removed after process exit, TCP close, UDP timeout, or rapid source-port reuse?

This information will help me correctly design the tests for the source-port reuse issue and the TCP/UDP same-port collision.

I have attached a small source-only archive for architecture review.

It excludes the Git repository metadata, binaries, VM lifecycle scripts,
test evidence, and unrelated reports.

The most relevant files are:

• src/probe_ebpf.c — kernel-side policy lookup and initial redirection;
• include/probe_shared.h — shared map keys, actions, and redirect context;
• src/loader.cpp — eBPF loading, map population, and relay registration;
• src/tcp_relay.cpp — user-mode TCP relay and WFP redirect-record handling;
• src/udp_relay.cpp — UDP request forwarding and the reverse-path limitation;
• src/client.cpp — verification of the UDP response source endpoint.

The archive also contains README_FOR_REVIEW.md describing the role of each
component and SHA256SUMS.txt for file verification.

ProxyBridge_eBPF_Architecture_Review.zip
9188C4C517B0899ECDD207B6E5AADBFF8

[dentatli]

Interim WFP beta testing result: full-path application rules can silently fail open

This is an interim result, not the final evaluation of ProxyBridge 4.1.0-Beta. Testing is still in progress.

During the current testing, a confirmed application-path matching defect was found. It affects full-path BLOCK rules and is also likely to affect full-path PROXY rules. This does not prevent all remaining testing, but results must distinguish between the normal full-path configuration and a controlled basename workaround.

The full-path BLOCK/PROXY branch of the matrix was paused at the first security-relevant failure. Other correctness work may continue with a basename selector where appropriate, while the full-path cases remain NO-GO until fixed and retested.

Tested build and environment

ProxyBridge version:
4.1.0-Beta WFP

Windows:
Windows 10 Pro 22H2 x64
Build 19045
VirtualBox VM
Test Signing enabled

ProxyBridge.exe SHA-256:
8DEDB0E389860DFC451DA49B9F289D4C82FCA7A9B664B3D221CED136E615C881

ProxyBridgeCore.dll SHA-256:
B37DC4672788CB385266C370305DB15BB0DCA86BF1ACF2181E93AACB1161ADC9

ProxyBridgeDrv.sys SHA-256:
4FA8909C7887815F8FFE6E49C2D6ADC7CA6A4E85A0F0DD243FE63B9A5E70DEFF

Test topology:

VM client:
[redacted]

SOCKS5:
[redacted]

Deterministic endpoint:
[redacted]

TCP and UDP endpoint ports:
[redacted]

The deterministic client was a standalone Winsock x64 binary:

pb_net_client.exe SHA-256:
3A7DC486A7BE36E161C2AD8472FF9957AE74D957EF6BDC31E09A9175142E45F5

Its local loopback validation passed 11/11 tests, including TCP/UDP IPv4/IPv6, connected and unconnected UDP, same-port TCP/UDP cases, held-flow rechecks and source-port reuse.

Installation and lifecycle status

The following stages passed before policy testing:

Pre-install audit: PASS
Controlled driver installation: PASS
Non-reboot lifecycle: PASS
Reboot lifecycle: PASS
Harness validation: PASS
Endpoint and network preflight: PASS

The WFP snapshot showed the expected objects:

ProxyBridge provider and sublayer present
Four expected callouts registered
Callout IDs 290–293
Four custom WFP filters present
Filter IDs 68737–68740

The failure was therefore not caused by a missing provider, sublayer, filter or callout registration.

Proxy backend validation

The built-in Proxy Test passed:

SOCKS5 control connection: PASS
TCP connection through SOCKS5: PASS
HTTP response: 200 OK
SOCKS5 UDP ASSOCIATE: PASS

The UDP relay address was successfully returned by the proxy.

DIRECT controls

With ProxyBridge disabled, the deterministic direct controls passed:

TCP IPv4: PASS
UDP IPv4 connected: PASS
UDP IPv4 unconnected: PASS

With ProxyBridge running and an explicit DIRECT rule, the same three tests also passed.

The VPS received and echoed every expected payload, and ProxyBridge Activity Log reported via Direct.

This established a working direct-path reference before testing BLOCK.

---

Confirmed failure: full-path BLOCK rule leaks traffic

The rule was configured as:

Applications:
C:\PB-WFP-Audit\WFP-Harness-3.1C\bin\pb_net_client.exe

Target host:
[redacted]

Target ports:
[redacted]

Protocol:
BOTH

Action:
BLOCK

Enabled:
yes

ProxyBridge reported:

pb_net_client.exe (PID:3912)
→ [redacted]
via Blocked

However, the actual network result was:

TCP connect succeeded
WSA error: 0
Bytes sent: 111
Bytes received: 111
Timing: 140 ms

Payload SHA-256:

4c0613aecf72171583bfe3a599c183d6dbfebf506f91938e7859434433fe36e9

The response SHA-256 was identical.

The VPS recorded both:

MESSAGE_RECEIVED
ECHOED

for the same payload hash.

The observed source was the established direct-path public address, which has been redacted.

Therefore, although the Activity Log displayed via Blocked, the connection went directly to the endpoint and completed a full application-level echo.

This was not a timeout, logging ambiguity or harness classification issue.

---

Cold-start persistence test

The VM was later fully restarted.

After cold start:

The saved rule remained present
The rule remained enabled
The action remained BLOCK
The full application path remained unchanged

ProxyBridge startup reported:

driver: pushed 0 watched image(s)
No rules configured - all traffic will be direct
driver: pushed 1 watched image(s)
Added rule ID: 1 ... Action: 2
driver: pushed 1 watched image(s)
Enabled rule ID: 1

Thus the rule was persisted and one watched image was eventually sent to the driver.

The next single TCP BLOCK test still leaked:

Activity Log:
pb_net_client.exe (PID:6392)
→ [redacted]
via Blocked

WSA error:
0

Bytes sent:
122

Bytes received:
122

Timing:
156 ms

Actual result:
fail:unexpected_response

Payload SHA-256:

b263b095d1fb01ad70ac14f8de164d09f85fb5cf3b67d3eba6b01dedb9892ad4

The VPS again recorded:

MESSAGE_RECEIVED
ECHOED

for the exact payload.

This excluded:

rule persistence failure
a defect limited only to hot rule updates
an empty watched-image list as the sole cause
user-mode application selector failure

---

Source/control-flow analysis

The exact source corresponding to the tested 4.1.0-Beta binary was not available.

The public WFP source examined was:

Commit:
ea115fa676bac95710c8db847b5fb1e77ace15a3

Tree version:
4.0.13-Beta

The public implementation contains the following control flow:

ClassifyCore()
→ sets classifyOut->actionType to FWP_ACTION_PERMIT
→ reads ALE_APP_ID as a kernel device path
→ calls IsWatched()
→ IsWatched() performs a literal case-insensitive suffix comparison
→ watch miss returns without redirecting
→ the original connection continues with PERMIT

A WFP ALE_APP_ID may use a kernel device path such as:

\Device\HarddiskVolume...\pb_net_client.exe

The full selector pushed from the rule was:

C:\PB-WFP-Audit\WFP-Harness-3.1C\bin\pb_net_client.exe

A full DOS path beginning with a drive letter is not a suffix of a kernel device path beginning with \Device\HarddiskVolume....

The separate ALE_AUTH_CONNECT monitor path does not enforce BLOCK. It reports the connection to user mode, where ProxyBridge can resolve the process to a normal DOS path and evaluate the rule again.

This explains the apparently contradictory result:

kernel watch gate misses
→ original connection remains DIRECT

user-mode monitor resolves the process
→ user-mode rule evaluation returns BLOCK
→ Activity Log displays via Blocked

Actual BLOCK enforcement occurs later in the local relay, but only if the kernel connect-redirect gate first redirects the connection to that relay.

---

Runtime discriminator: basename selector

To test this hypothesis without modifying the product, only the Applications field was changed:

Before:
C:\PB-WFP-Audit\WFP-Harness-3.1C\bin\pb_net_client.exe

After:
pb_net_client.exe

All other rule fields remained unchanged:

Action: BLOCK
Host: [redacted]
Ports: [redacted]
Protocol: BOTH
Enabled: yes

ProxyBridge reported:

driver: pushed 1 watched image(s)
Updated rule ID: 1
driver: pushed 1 watched image(s)
Enabled rule ID: 1

During the single targeted TCP test:

pb_net_client.exe (PID:6452)
→ [redacted]
via Blocked

[RELAY] accepted redirect:
pid=6452
dest=[redacted]
action=2
cfg=0

This RELAY accepted redirect line was absent during both leaking full-path tests.

Client result:

WSA error:
10054

Bytes sent:
120

Bytes received:
0

Actual result:
pass:no_echo_observed

Exit code:
0

Payload SHA-256:

a29f3e92e39844451f0f250c752843ea7cd886129bb0090855a2777233644869

The VPS log contained zero matching records:

Matches:
0

The empty match file had the standard empty-file SHA-256:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

The payload did not reach the endpoint.

---

A/B result

Application selector	Watched image count	Relay accepted redirect	Client received echo	VPS received payload	Result
Full DOS path	1	No	Yes	Yes	BLOCK silently leaked
pb_net_client.exe	1	Yes	No	No	BLOCK correctly enforced

This isolates the failure to the kernel watchlist matching gate.

It is not caused by:

BLOCK handling in the relay
rule persistence
rule action evaluation
endpoint behavior
harness behavior
watched-image count construction
application selection in user mode

Current conclusion

The runtime A/B result confirms the following behavior in the tested 4.1.0-Beta binary:

a full DOS application path does not match the WFP ALE_APP_ID kernel device
path under the current watchlist comparison

→ the connect redirect is skipped
→ the default permit path remains active
→ BLOCK traffic silently leaks DIRECT

The public 4.0.13-Beta source provides a control flow that precisely explains the observed 4.1.0-Beta behavior.

Because the exact 4.1.0 source was unavailable, the exact source line in that binary is not independently proven, but the runtime cause and the full-path-versus-basename discriminator are confirmed.

Security impact

The BLOCK case is formally runtime-confirmed.

The same kernel watch gate is also used before PROXY handling. Therefore full-path PROXY rules may be vulnerable to the same silent direct bypass:

intended PROXY
→ kernel watch miss
→ original connection remains DIRECT

The PROXY case has not yet been separately demonstrated at runtime, so it should currently be described as a strongly supported impact, not as a second formally proven test result.

The Activity Log is not sufficient evidence of actual BLOCK or PROXY enforcement because it can show the result of the later user-mode rule evaluation even when the kernel redirect never occurred.

Suggested minimal fix

The smallest safe change appears to be:

1. Keep the original full application path for exact user-mode rule matching.

2. Derive a namespace-independent basename for the driver watchlist:
   C:\path\pb_net_client.exe
   → pb_net_client.exe

3. Redirect basename candidates to the local relay.

4. Let the relay resolve the real process path and re-evaluate the original
   full rule before applying DIRECT, BLOCK or PROXY.

5. Check the result of the watchlist DeviceIoControl operation.

6. Log "pushed N watched image(s)" only after the driver confirms success.

This may intentionally over-capture processes sharing the same basename, but the relay can then perform the exact full-path check. Over-capture followed by exact user-mode evaluation is safer than a silent fail-open.

An alternative is to normalize both paths into the same Windows namespace before comparison, but direct comparison between an unmodified DOS path and raw ALE_APP_ID should not remain.

Required targeted regression tests

Before resuming the broader matrix, a fix candidate should pass:

1 build

1 full-path TCP BLOCK test:
- relay redirect must occur
- no endpoint payload
- no echo

1 full-path TCP PROXY test:
- relay redirect must occur
- endpoint must observe the proxy path
- no DIRECT leak

1 basename BLOCK regression:
- existing working behavior must remain correct

The full-path BLOCK/PROXY branch should remain stopped until these targeted tests pass. Other TCP/UDP/IPv4/IPv6 tests may continue under an explicitly documented basename workaround, but such results must not be presented as proof that ordinary full-path rules are working.

Current project status

Installation and lifecycle:
PASS

Harness and endpoint:
PASS

DIRECT IPv4 TCP/UDP:
PASS

Full-path BLOCK:
FAIL / NO-GO

Cold-start full-path BLOCK:
FAIL / NO-GO

Source/control-flow audit:
PASS

Basename BLOCK discriminator:
PASS

Root cause:
CONFIRMED behaviorally

Product changes:
none yet

Overall WFP policy status:
NO-GO until fixed

This remains an interim result. Testing of PROXY, UDP, IPv6, issue #206, issue #209 and reconnect behavior can continue with a clearly documented basename workaround where the application selector is relevant. The ordinary full-path BLOCK and PROXY cases must be retested after the defect is fixed. Performance testing should still wait until the relevant correctness paths are stable.

[dentatli]

UDP source transparency issue

During testing of the current WFP beta, I reproduced the same UDP transparency problem that was previously observed in the eBPF prototype.

The outgoing UDP datagram is routed through SOCKS5 correctly, the remote endpoint receives it, and the response payload returns intact. However, the application sees the response as coming from ProxyBridge’s local UDP relay rather than from the original remote endpoint.

The cause is that ProxyBridge preserves the original destination for forward routing, but on the reverse path it sends the decoded payload back to the application using a normal sendto() call from the shared local relay socket. As a result, the original remote source IP and port are lost.

This affects both connected and unconnected UDP semantics and can break applications that validate or depend on the peer endpoint, including QUIC, voice communication, games, and other stateful UDP protocols.

A possible first fix is to implement the documented WFP non-TCP redirect-record flow using WSARecvMsg, WSASendMsg, and IP_CONNECTION_REDIRECT_RECORD, preserving the redirect record for the lifetime of the UDP flow. This should then be verified with connected and unconnected UDP tests.

If redirect records cannot restore the original source identity through the SOCKS5 relay topology, the fallback would be a kernel-level reverse-path rewrite or packet reinjection mechanism. Ordinary user-mode sendto(), IP_PKTINFO, or raw-socket spoofing should not be treated as a complete general solution.

[dentatli]

I have published the standalone ProxyBridge TestLab discussed earlier:

https://github.com/dentatli/ProxyBridge-TestLab

Commit-pinned snapshot used for this handoff:

https://github.com/dentatli/ProxyBridge-TestLab/tree/ad8a9256cf5e0ef0f8a212cd2870115e6f729c18

The repository now contains:

• the Windows TCP/UDP test-client source and build script;
• the Linux IPv4/IPv6 TCP/UDP echo endpoint;
• complete Windows client and Linux server deployment instructions;
• automatic ProxyBridge profile generation;
• binary path and SHA-256 verification;
• exact client/VPS payload correlation;
• DIRECT, BLOCK and PROXY route validation;
• known-defect signature matching;
• issue [Windows] Proxy rules stop being applied after hours of uptime: stale port-decision cache leaks traffic direct #206 and [Bug]: [Windows] connection_hash_table identifies flows by source port only, causing TCP/UDP collisions and skipped rules #209 regression scenarios;
• dry-run, fixture-backed mock, real-smoke and IPv4 diagnostic suites;
• machine-readable evidence, summaries and checksums.

Current Windows IPv4 diagnostic result:

• 25 implemented scenarios executed;
• 17 PASS;
• 7 EXPECTED_FAIL matching known defect signatures;
• 1 additional FAIL_PRODUCT under investigation;
• 0 FAIL_HARNESS;
• 0 FAIL_INFRASTRUCTURE;
• 0 CONTAMINATED;
• cleanup passed after all 25 executed scenarios.

Confirmed working:

• TCP IPv4 DIRECT, BLOCK and PROXY;
• UDP IPv4 DIRECT and BLOCK for connected and unconnected sockets;
• basename, destination-IP and port selectors;
• BLOCK and PROXY no-leak checks;
• issue [Windows] Proxy rules stop being applied after hours of uptime: stale port-decision cache leaks traffic direct #206 PROXY → BLOCK with exact abortive local-port reuse.

Reproduced product defects:

1. Full-path application rules can fail open while basename matching works.
2. UDP PROXY does not restore the original remote UDP response source.
3. UDP DIRECT can be silently dropped when the process is watched by another non-DIRECT rule.
4. Issue [Windows] Proxy rules stop being applied after hours of uptime: stale port-decision cache leaks traffic direct #206 PROXY → DIRECT exact-port reuse does not use the direct egress.
5. A mixed DIRECT/PROXY profile produced wrong egress on its first DIRECT flow; this is being treated as a separate candidate because it occurred before port reuse.

IPv6 was not executed because the current environment has no native public IPv6 route. Advanced lifecycle, application, failure-injection and performance scenarios remain explicitly marked as not implemented rather than passed.

The repository contains no ProxyBridge binaries, credentials, private keys or raw environment evidence.

The setup documentation explains how to build the client, deploy the server endpoint, configure .env and capabilities, run a smoke test, and execute the current IPv4 diagnostic suite.

Please let me know whether you would prefer:

• additional scenarios for a specific code path;
• a run against another beta build;
• raw redacted evidence for a specific failure;
• or changes to make the framework suitable for upstream CI/manual release validation.