search

mr-canoehead / vpn_client_gateway

Pi-Powered VPN Client Gateway: installation documentation and related files.
115 stars 31 forks source link

iptables don't work for TCP connections [enhancement] #40

Closed ashishpandey closed 5 years ago

ashishpandey commented 5 years ago

the current firewall config script doesn't work when connected to to a vpn over TCP. Only a predefined set of UDP ports are routed

For my setup, I need to connect over TCP over well defined ports like 443. As a quick fix, I have added a predefined set of common VPN TCP ports on a fork - https://github.com/mr-canoehead/vpn_client_gateway/commit/34659b3afc2271ce3fd3ac4f8f4cb5984ef5af60. The script handles cases when either port list is empty. If you want, I can send in a pull request

I was further thinking to further add an option to configuration tool to work out the protocol and port from the actual server.conf to tailor it to individual installs. That way, we won't have unnecessary ports configured in the firewall. Thoughts? I will give it a shot in coming days and can contribute a patch if it sounds sensible?

mr-canoehead commented 5 years ago

(added email reply to issue thread for tracking purposes) Hi Ashish,

Yes, please send a pull request for the first change (adding TCP ports to the firewall script). As for managing the TCP / UDP ports configured in the firewall, can you please provide a little more detail as to how you envision that working (e.g. pseudocode)?

In the future I would like to extend the vpnservers XML schema to include an optional 'serverprotocol' element which will allow users to switch between servers using different transport protocols (e.g. server A using TCP on port 443, server B using UDP on port 53). The schema currently supports an optional 'serverport' element which, if present, is used by the change_server function to update the port value in server.conf. I envision the 'serverprotocol' element being used in the same way; if it is present in the vpnserver element, change_server will use its value to update server.conf accordingly.

My concern with locking down the ports during the installation process based on the current setting in server.conf is that this may limit the ability to switch between servers using different transport protocols after the installation is complete.

Perhaps a mid-ground solution would be to have the user choose a VPN provider during the installation process, and based on that choice the install script could open the appropriate set of UDP/TCP ports supported by that provider. In this way the number of outbound open ports could be limited to some degree, but without impacting the ability to switch between servers using different transport protocols.

Chris

ashishpandey commented 5 years ago

Coming back to this after some time. Have submitted the pull for the simple change

Will experiment with the next steps as mentioned in the pull request. Repeating here for continuity of the discussion:

In current state, the VPN switch does not change the protocol at all, so it remains whatever was chosen in the original server.conf, so my guess is anyone using this currently is locked to a single choice of protocol and switching servers within that protocol

As a first subsequent step, I will test if the FW script can be applied to discover protocol and ports from the current server.conf after every switch and tweak a user-defined chain based on that. If that works, the FW config can be isolated from switching step. As an additional step, then the vpnserves config can be enhanced to optionally include the protocol per server, which can then be used to rewrite the servers.conf

I will try out this when I get some downtime, and follow up on this thread

mr-canoehead commented 5 years ago

Closing issue due to lack of activity, if you are working on this enhancement please let me know, I'll re-open this issue.