You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a Tor entry guard is running on the same server (same IP) as the VPN server (same IP), and if VPN breaks down, Tor may connect directly to the VPN if it happened to choose that Tor relay (same IP) as entry guard. This is not that unlikely, because a lot VPN providers support VPN port forwarding, use public IPs and people host Tor servers behind VPN's.
(partial solution):
(A partial solution for this to set the VPN VM's firewall rules to allow connections only to the VPN server. Specifying destination port in that firewall rule should help a lot. Some cases will not be solved (like VPN running on 443).)
full solution:
A full solution is to allow only user tunnel to connect to the open internet. All other users not.
TODO:
Implement the full solution.
Build on top of the development branch.
starting point:
This was fixed in a similar firewall project. This was fixed in whonix-ws-firewall and whonix-gw-firewall. (These are firewalls tailored for Whonix that will not work as drop in replacement for vpn-firewall.)
The usability-misc package simplifies this by requesting less file creation from the user. [1] [2]
Footnotes:
[1] The user needs to comment in a few things to make it work. Here in vpn-firewall we could emulate/duplicate these configuration files and have them commented in by default.
[2] Can conflict with whonix-(gw|ws)-firewall but not with usability-misc. [3]
[3] Not have same file names as in usability-misc package so these can still be co-installed.
use ip(6)tables --wait
made ip(6)tables commands configurable
RELATED,ESTABLISHED -> ESTABLISHED for better security (fixes#9)
ported from sysvinit to (systemd) netfilter-persistent
also source configuration folder /rw/config/vpn-firewall.d/*.conf
Debian packaging
licensing
refactoring
comments
problem description:
If a Tor entry guard is running on the same server (same IP) as the VPN server (same IP), and if VPN breaks down, Tor may connect directly to the VPN if it happened to choose that Tor relay (same IP) as entry guard. This is not that unlikely, because a lot VPN providers support VPN port forwarding, use public IPs and people host Tor servers behind VPN's.
(partial solution):
(A partial solution for this to set the VPN VM's firewall rules to allow connections only to the VPN server. Specifying destination port in that firewall rule should help a lot. Some cases will not be solved (like VPN running on 443).)
full solution:
A full solution is to allow only user tunnel to connect to the open internet. All other users not.
TODO:
starting point:
This was fixed in a similar firewall project. This was fixed in whonix-ws-firewall and whonix-gw-firewall. (These are firewalls tailored for Whonix that will not work as drop in replacement for vpn-firewall.)
tickets:
git commits:
documentation and implementation notes [as footnotes]:
The usability-misc package simplifies this by requesting less file creation from the user. [1] [2]
Footnotes:
[1] The user needs to comment in a few things to make it work. Here in vpn-firewall we could emulate/duplicate these configuration files and have them commented in by default.
[2] Can conflict with whonix-(gw|ws)-firewall but not with usability-misc. [3]
[3] Not have same file names as in usability-misc package so these can still be co-installed.
Bounty too low?:
The text was updated successfully, but these errors were encountered: