From Newsgroup: alt.comp.os.windows-11

HUGE UPDATE:

I finally fixed a huge problem in that I could never (until now) get VPN to work *last* in the chain (i.e., psiphon + proxybridge + VPN) even as VPN worked fine *first* in the chain (i.e., VPN + psiphon + proxybridge).

MULTIPLE problems needed to be identified:
1. Windows TAP adapter race condition ("Waiting for TUN/TAP interface to come up")
2. Psiphon SOCKS5 proxy lacks UDP ASSOCIATE
3. TAP adapter DHCP failures -> APIPA fallback
4. Free VPN server config variability (static IP vs DHCP push)

After solving those problems, finally, VPN works fine on Windows
whether it's the first or the last in the encryption chain of events.

However, initially only two issues seemed to show up which had to be solved:
1. Windows is too slow so we get "Waiting for TUN/TAP interface to come up"
2. The Psiphon SOCKS5 proxy supports TCP ASSOCIATE but not UDP ASSOCIATE

Given that, TCP VPN configs "should" have worked, even as UDP wouldn't work when VPN was last in the chain (i.e., after ProxyBridge was initiated).

What took a while to identify was WHY both UDP & TCP OpenVPN configs failed (where the VPN error for TCP was DIFFERENT than the error for UDP configs).
TCP: "Waiting for TUN/TAP interface to come up"
UDP: AIPA fallback "Initialization Sequence Completed With Errors"

What first needed to be modified in order for both TCP & UDP configs to
work (whether or not VPN was first or last in the encryption chain) was
each OpenVPN config file needed to tell OpenVPN.exe to employ adaptive commands to set up the TAP interface, and to wait longer before route injection occurs.
# Adaptively choose how Windows OpenVPN configures the TAP adapter
ip-win32 adaptive
# Give Windows 10 seconds longer before route injection begins
route-delay 10

In addition to that TAP adapter setup race with route injection, there is
no way around the fact that Psiphon's SOCKS5 proxy doesn't support UDP.

So the Psiphon rules.txt file needed to be modified extensively.

The rules.txt file had to be modified so that OpenVPN traffic
was handled correctly depending on protocol type. Before, both
TCP and UDP configs failed when VPN was placed last in the chain.

Here are the key changes between version 1p7 & 2p0 rules.txt:
a. Explicitly route OpenVPN.exe TCP traffic through Psiphon
Rule added:
openvpn.exe:*:443:TCP -> PROXY
This ensures that TCP VPN configs are proxied through
Psiphon's SOCKS5 tunnel.

b. Explicitly allow OpenVPN.exe UDP traffic to bypass Psiphon
Rule added:
openvpn.exe:*:*:UDP -> DIRECT
Because Psiphon's SOCKS5 proxy does not support UDP ASSOCIATE,
UDP VPN configs must go direct to the server.

c. Allow TAP/DHCP/DNS setup traffic to go DIRECT
Rules added:
svchost.exe:*:53:UDP -> DIRECT
svchost.exe:*:67,68:UDP -> DIRECT
system:*:*:UDP -> DIRECT
These ensure that Windows can perform DNS lookups and DHCP
lease negotiation for the TAP adapter without being blocked
or forced through Psiphon.

d. Block unwanted UDP traffic from browsers and apps
Rules added such as:
chrome.exe:*:443:UDP -> BLOCK
firefox.exe:*:443:UDP -> BLOCK
brave.exe:*:443:UDP -> BLOCK
This prevents browsers from leaking QUIC/UDP traffic outside
the encrypted chain.

e. Maintain TCP direct access for system processes
Rules like:
svchost.exe:*:*:TCP -> DIRECT
services.exe:*:*:TCP -> DIRECT
system:*:*:TCP -> DIRECT
These allow Windows core services to function normally while
keeping user applications proxied.

Here is the current status as of version 2p0 of the rules.txt file:
1. TCP OpenVPN configs now work when VPN is last in the chain,
because their traffic is correctly proxied through Psiphon.
2. UDP OpenVPN configs now work when VPN is last in the chain,
because their traffic bypasses Psiphon and goes direct.
3. TAP adapter setup traffic (DNS, DHCP) is allowed direct, so
Windows no longer fails with APIPA addresses.
4. Browser UDP traffic (QUIC) is blocked, preventing leaks.

The critical changes in rules.txt were:
1. Split handling of OpenVPN.exe traffic: TCP -> PROXY, UDP -> DIRECT.
2. Allow svchost/system UDP traffic direct for TAP setup.
3. Block browser UDP traffic to prevent leaks.
4. Keep system TCP traffic direct for stability.

Together with the OpenVPN config additions
(ip-win32 adaptive + route-delay 10), these rules fixed the
longstanding problem which had prevented VPN from being used after ProxyBridge. Now VPN works reliably whether it is first or last in the encryption chain.

Here is the version 2p0 of the rules.txt file to donate to the team.
# C:\app\network\proxy\proxybridge\rules.txt v1p0 20251023
# This is version 2p0
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Load this into ProxyBridge using the pb.bat script.
# Syntax: --rule <process>:<hosts>:<ports>:<protocol>:<action>
# Rules are case insensitive, # indicates comments, blank lines ignored.
# v1p1 20251023
# Added useful examples of block, direct & proxy for others to benefit
# Added usable inline comments (requires pb.bat v2p6 or higher to handle)
# v1p2 20251023
# Added usability explanations of dns complexity & QUIC/HTTPS3 issues.
# Added UDP block to handle Brave using experimental protocols above.
# v1p3 20251023
# Added clarification that TCP & UDP rules are not overridden
# v1p4 20251024
# Added Tor SOCKS5 proxy server (in addition to Psiphon's)
# v1p5 20251024
# Note that Tor cannot proxy UDP, so I had to add specific rules for that.
# v1p6 20251025
# Added Chrome, Brave, Edge & FF browser rules due to phoning home.
# v1p7 20251024
# Fixed error that Psiphon doesn't support UDP ASSOCIATE
# This is to avoid proxying UDP (Psiphon doesn't support UDP ASSOCIATE)
# Cleaned up DNS section because DNS via proxy is enabled by default
# v1p8 20251130
# Added DIRECT rules for svchost.exe, route.exe, and system UDP.
# So that TAP setup traffic bypasses ProxyBridge.
# Tunnel traffic (openvpn.exe on TCP 443) still goes through Psiphon.
# This separation allowed DHCP and ARP to succeed but Windows was slow
# to set up the tunnel until I added two directives to TCP config files.
# ip-win32 adaptive
# route-delay = 10
# Remaining issue:
# Even with bypasses, Windows was slow to mark TAP up.
# OpenVPN kept looping "Waiting for TUN/TAP interface to come up"
# v1p9 20251201
# Combined both TCP/UDP cases in a single rules.txt file by
# explicitly allowing UDP traffic from OpenVPN to go DIRECT,
# while still proxying TCP 443 through Psiphon
# Now TCP tunnel traffic is proxied through Psiphon
# While UDP tunnel traffic bypasses ProxyBridge (DIRECT)
# And TAP setup traffic (DHCP, ARP, route injection) is always DIRECT so
# OpenVPN can bring the interface up in time given ProxyBridge delays.
# v2p0 20251201
# The rules bypassed ProxyBridge, but the TAP adapter still failed DHCP.
# Windows gave it a fallback 169.254.x.x address, so OpenVPN reported
# "Completed With Errors." For UDP VPNGate configs to work, they must run
# DIRECT without Psiphon, and the network must allow the TAP adapter
# to obtain a proper 10.x.x.x lease from the VPN server.
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

--proxy socks5://127.0.0.1:1080 # Psiphon local SOCKS5 listener
# --proxy socks5://127.0.0.1:9150 # Tor Browser SOCKS5 listener (optional)

# Applications that should always use the proxy
--rule telegram.exe:*:*:TCP:PROXY
--rule MemoryHogs.exe:*:*:TCP:PROXY
--rule dialog.exe:*:*:TCP:PROXY

# Block QUIC/HTTP3 globally
--rule *:*:443:UDP:BLOCK

# Brave rules
--rule brave.exe:*:*:TCP:PROXY
--rule brave.exe:*:443:UDP:BLOCK
--rule BraveUpdate.exe:*:*:TCP:BLOCK
--rule brave.exe:*:5228:TCP:BLOCK
--rule brave.exe:*:53:UDP:BLOCK

# Chromium rules
--rule chrome.exe:*:*:TCP:PROXY
--rule chrome.exe:*:443:UDP:BLOCK
--rule chrome.exe:*:5228:TCP:BLOCK
--rule chrome.exe:*:53:UDP:BLOCK

# Firefox rules
--rule firefox.exe:*:*:TCP:PROXY
--rule firefox.exe:*:443:UDP:BLOCK

# Block telemetry and unwanted processes
--rule OneDrive.exe:*:*:TCP:BLOCK
--rule CompatTelRunner.exe:*:*:TCP:BLOCK
--rule SearchApp.exe:*:*:TCP:BLOCK

# Core system processes bypass proxy
--rule svchost.exe:*:*:TCP:DIRECT
--rule services.exe:*:*:TCP:DIRECT
--rule system:*:*:TCP:DIRECT

# Utility
--rule curl.exe:*:*:TCP:PROXY

# DNS and TAP setup bypass
--rule svchost.exe:*:53:UDP:DIRECT
--rule svchost.exe:*:67,68:UDP:DIRECT
--rule svchost.exe:*:*:UDP:DIRECT
--rule system:*:*:UDP:DIRECT
--rule route.exe:*:*:TCP:DIRECT
--rule route.exe:*:*:UDP:DIRECT

# OpenVPN rules
--rule openvpn.exe:*:443:TCP:PROXY # TCP tunnel proxied through Psiphon
--rule openvpn.exe:*:*:UDP:DIRECT # UDP tunnel bypasses ProxyBridge
# NOTE: For UDP OpenVPN configs to work, they must run DIRECT without Psiphon,
# and the network must allow the TAP adapter to obtain a proper 10.x.x.x lease.
# Otherwise OpenVPN will report "Initialization Sequence Completed With Errors"
# and the TAP adapter will fall back to a 169.254.x.x APIPA address.

# Log level
--verbose 3

# end of C:\app\network\proxy\proxybridge\rules.txt
--
The point of Usenet is for smart people to help each other & for results
to be archived so that anyone can access our immense tribal knowledge.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

Marian wrote:

So the Psiphon rules.txt file needed to be modified extensively.

Correction.

The "ProxyBridge" rules.txt file had to be extensively modified.
[Not the Psiphon rules.txt file (which doesn't exist).]

I never would have started this project of creating a robust proxy on
Windows had I known how many problems would have to be surmounted, but
finally, after a couple of months (elapsed time), it's all resolved.
VPN + {Psiphon/SOCKS5 + ProxyBridge} required extensive modifications
{Psiphon/SOCKS5 + ProxyBridge} + VPN required even more modifications

But it all works well now (although WinHTTP can't use PAC or SOCKS still)
VPN first, Psiphon SOCKS5 proxy second & ProxyBridge last works well now.
Psiphon SOCKS5 proxy first, ProxyBridge second & VPN last works well too.

The fundamental problems first & foremost were not only that Psiphon's
SOCKS5 proxy does not handle UDP tunneling, but that the Windows TAP
adapter (Terminal Access Point) takes time to come up with ProxyBridge.
*Cannot connect OVPN (UDP) through SOCKS5 proxy*
<https://github.com/OpenVPN/openvpn/issues/661>

*What is TAP-Windows Adapter*
<https://www.thewindowsclub.com/tap-windows-adapters-vpn-driver>

In theory, SOCKS5 proxies "should" be able to work with OpenVPN.
*SOCKS5, HTTP, UDP Proxies in OpenVPN*
<https://www.proxyfella.com/2024/11/30/socks5-http-udp-proxies-in-openvpn/>

Each operating system requires DIFFERENT commands to solve these issues.
For example, "ip-win32 adaptive" is a Windows-only OpenVPN directive.

Linux-based operating systems work better than Windows, where, for example,
on Android, Psiphon's tunneling is more complete (TCP + UDP), but Windows support is limited such that some users have resorted to using dns2socks
for DNS resolution (but this has its own inherent problems as noted here).
*psiphon-tun2socks*
<https://github.com/Nebula-Mechanica/psiphon-tun2socks>

Windows is just a lousy platform for networking, it turns out, where, for example, I had to extensively modify Windows just to make it work well.
a. I had to sync WinINET & static WinHTTP proxy settings
b. I had to set AutoConfigURL and AutoDetect registry keys
c. I had to set the PAC file using the Windows registry
d. I had to sync PAC from file:///C:/data/sys/batch/proxy.pac
e. I had to run Mongoose to serve PAC at http://127.0.0.1/proxy.pac
f. I had to route other traffic via SOCKS 127.0.0.1:1080
g. And even then, WinHTTP can't use PAC or SOCKS, so I have to fix that
etc.

Basically, Windows sucks as these things, but one by one we can work around them, which is what the set of files I posted in this thread purport to do.
1. Win+R > psiphon.bat (this starts Psiphon SOCKS5 & syncs the above)
2. Win+R > pb.bat (this starts ProxyBridge which reads in rules.txt)
3. rules.txt (this tells ProxyBridge what to send thru the socks proxy)
4. pac.cmd (this sets a registry key to point to the PAC file)
5. proxy.pac (this sets PAC rules of what domains to skip proxy)
6. launchmongoose.vbs (this locally serves proxy.pac as http & https)
7. Win+R > psiphonstop.bat (this gracefully undoes all of the above setup)

This is a general purpose solution in that it uses 100% freeware so anyone
can run all of the above without cost simply by installing the software.
1. OpenVPN freeware + freely available UDP/TCP OpenVPN config files
2. Psiphon freeware + scripts to sync WinINET + WinHTTP + PAC files
3. ProxyBridge freeware + scripts to add missing rules.txt functionality
4. Mongoose freeware + scripts to serve the localhost PAC file as HTTPS

In summary, this is a complete DIY proxy + VPN system for all Windows executables (whether or not they inherently work with SOCKS5 proxies),
but even now, WinHTTP apps (e.g., Windows update) do not use PAC/SOCKS
and will and will connect directly unless I add something like Polipo.

What I conclude, personally, from this endeavor, is that while everything
you want to accomplish can be done with effort, Windows sucks at this type
of networking. It would have been much easier to do on a Linux-based PC.
--
Everything is possible if you're intelligent, but it's not always worth it.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

README.TXT 20251202
===========

Overview
This directory contains scripts and configuration files that work
together to launch, manage and stop a Psiphon based SOCKS5 proxy
environment on Windows. The setup uses Mongoose to serve a PAC file,
batch scripts to apply and reset proxy settings, ProxyBridge to enforce
process specific rules, and supporting files to control behavior. The
goal is to route browser and selected application traffic through
Psiphon while leaving system services and critical networking functions
direct.

Files
-----

psiphon.bat
This batch script launches Mongoose to serve proxy.pac, verifies
availability of the PAC file, then launches Psiphon in SOCKS mode. It
applies PAC logic to WinINET applications such as browsers, forces
registry keys to persist AutoConfigURL and AutoDetect, and syncs WinINET
proxy settings into WinHTTP. It logs activity to proxy.log. It warns
that WinHTTP applications such as Windows Update do not honor PAC or
SOCKS. It suggests using Privoxy or Polipo to bridge SOCKS to HTTP if
WinHTTP apps must be tunneled.

launchmongoose.vbs
This VBScript starts mongoose.exe silently if not already running. It
serves proxy.pac at http://127.0.0.1/proxy.pac. It logs launch attempts
to mongoose.log. It ensures the working directory is set so proxy.pac is
served correctly. It includes tutorial comments for loading PAC files
directly into Firefox using file:/// URLs. It notes that WPAD auto
discovery requires the file to be named wpad.dat and served at
http://wpad.domain/wpad.dat. Localhost proxy.pac works only with manual
configuration.

proxy.pac
This PAC file defines proxy rules. It bypasses Gmail, Google, Amazon,
and Copilot domains with DIRECT connections. All other traffic is routed
through SOCKS 127.0.0.1:1080. This works for WinINET based applications
such as Chrome, Edge, and IE. WinHTTP applications ignore PAC and SOCKS.
The file includes version history and comments explaining split tunnel
behavior. It notes that WPAD clients expect wpad.dat not proxy.pac.

pac.cmd
This script is a helper called automatically from psiphon.bat. It
enforces PAC logic silently. It logs its run, detects if it was called
from psiphon.bat, and then calls proxy.cmd to perform actual
configuration. It checks current PAC URL and AutoDetect status, applies
changes if needed, forces registry keys, and re captures status for
display. It ensures that proxy.cmd reflects correct status immediately.
It is a wrapper around proxy.cmd designed for automation.

proxy.cmd
This script is the diagnostic and configuration tool for proxy settings.
It can be run directly by the user or indirectly by pac.cmd. It supports
flags such as /help, /sync, /nopac, /status, /reset, /silent, or a PAC
URL. It manipulates registry keys under HKCU\Software\Microsoft\Windows\
CurrentVersion\Internet Settings. It can set or clear PAC URLs, enable
or disable AutoDetect, enable or disable static proxy servers. It syncs
WinINET into WinHTTP if needed. It displays detailed status of WinINET,
WinHTTP, and PAC configuration. It logs every invocation to proxy.log.
It is the heavy duty tool that pac.cmd relies on.

psiphonstop.bat
This batch script stops Psiphon and Mongoose if running, resets WinINET
and WinHTTP proxy settings, flushes DNS, resets IP stack, and attempts
Winsock reset with retry logic. It logs shutdown events to proxy.log and
mongoose.log. It exports registry keys before deletion for backup. It
sets ProxyEnable to 0 to force direct access. It clears ProxyOverride.
It resets WinHTTP proxy with netsh winhttp reset proxy. It checks Wi Fi
adapter state before Winsock reset. It logs environment proxy variables.
It reminds the user to clear browser cache and disable proxy extensions.
It ends with a beep to signal completion.

pb.bat
This batch script launches ProxyBridge CLI with rules defined in
rules.txt. It checks for administrator privileges, sets up logging,
reads rules.txt, strips comments, builds arguments, and runs ProxyBridge.
It ensures only one console window is used and that Ctrl+C stops
ProxyBridge cleanly. It logs output to timestamped files. It is designed
to enforce process specific proxy rules using Psiphon or Tor SOCKS5
listeners. It is a wrapper around ProxyBridge CLI for usability and
persistence.

rules.txt
This file defines ProxyBridge rules. It sets Psiphon SOCKS5 at
127.0.0.1:1080 as the default proxy. It forces browsers such as Brave,
Chrome, and Firefox to use the proxy for TCP traffic and blocks UDP
QUIC. It blocks telemetry processes such as OneDrive and CompatTelRunner.
It bypasses core system processes such as svchost.exe, services.exe, and
system to ensure DNS, DHCP, ARP, and TAP setup traffic go direct. It
proxies OpenVPN TCP 443 traffic through Psiphon but allows UDP tunnel
traffic direct. It logs at verbose level 3. It notes that UDP based VPN
configs must run direct without Psiphon.

Note that VPN can be run either before or after ProxyBridge now, i.e.,
VPN + {Psiphon/SOCKS5 + ProxyBridge/rules.txt} always worked fine
{Psiphon/SOCKS5 + ProxyBridge/rules.ext} + VPN now also works fine

Behavior Summary
----------------
Browsers using WinINET such as Chrome, Edge, IE, and Opera will honor
proxy.pac and route traffic through Psiphon SOCKS except for domains
explicitly bypassed. Firefox requires manual configuration or use of
system proxy settings. WinHTTP applications such as Windows Update and
Microsoft Store do not honor PAC or SOCKS and will connect direct unless
an HTTP to SOCKS bridge is used. Command line tools (such as curl and git)
ignore WinINET PAC unless configured with environment variables.
ProxyBridge enforces process specific rules to ensure selected apps are
tunneled while system services remain direct.

Limitations
-----------
WinHTTP does not support PAC or SOCKS. Windows Update and other system
services will not use Psiphon under this setup. UDP traffic cannot be
proxied through Psiphon SOCKS. WPAD auto discovery requires wpad.dat
served at http://wpad.domain/wpad.dat. Localhost proxy.pac works only
with manual configuration. Environment variables such as HTTP_PROXY may
still affect command line tools unless cleared. ProxyBridge rules must
explicitly list each application to be tunneled. Applications not listed
will connect direct.

Conclusion
----------
This environment provides a controlled way to route browser and selected
application traffic through Psiphon while leaving system services direct.
It uses Mongoose to serve PAC, batch scripts pac.cmd and proxy.cmd to
apply and reset proxy settings, and ProxyBridge with rules.txt to enforce
process specific behavior. For full coverage, including WinHTTP programs,
an HTTP to SOCKS bridge (such as Privoxy or Polipo) is likely required.
--- Synchronet 3.21a-Linux NewsLink 1.2