Purevpn gateway

Have some feedback, questions, suggestions, or just fancy a chat? Pop it in here.
User avatar
Joulinar
Posts: 5087
Joined: Sat Nov 16, 2019 12:49 am

Re: Purevpn gateway

Post by Joulinar »

a killswitch can be created using iptables similar to this guide. https://linuxconfig.org/how-to-create-a ... s-on-linux

usually @trendy has good ideas on this topic :)
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
User avatar
MichaIng
Site Admin
Posts: 3087
Joined: Sat Nov 18, 2017 6:21 pm

Re: Purevpn gateway

Post by MichaIng »

See how we did it for the new DietPi-VPN tool: https://github.com/MichaIng/DietPi/blob ... #L346-L360
Feedback are highly welcome. Btw, good change to have PureVPN natively integrated as well :).
User avatar
trendy
Posts: 340
Joined: Tue Feb 25, 2020 2:54 pm

Re: Purevpn gateway

Post by trendy »

That guide looks god to me @Joulinar!
Regarding Diepti-vpn I would suggest:
  1. to include also the FORWARD chain
  2. to get the $VPN_SERVER, $PROTOCOL and $PORT from the ovpn config file.
  3. allow the VPN nameserver to be reachable from the ISP.
User avatar
MichaIng
Site Admin
Posts: 3087
Joined: Sat Nov 18, 2017 6:21 pm

Re: Purevpn gateway

Post by MichaIng »

trendy wrote: Tue Apr 06, 2021 11:40 am to include also the FORWARD chain
What do you mean by this? It is dropped when the killswitch is enabled, so you mean to also allow forwarded requests to the VPN server and LAN by default, so that the VPN connection can be shared to the LAN?
trendy wrote: Tue Apr 06, 2021 11:40 am to get the $VPN_SERVER, $PROTOCOL and $PORT from the ovpn config file.
  • VPN_SERVER in the first place is a variable to have the correct OVPN file selected/created. So in case of NordVPN and ProtonVPN it's the other way round: The variable defines the OVPN file. If it would not match the actually contained remote IP/hostname, then the killswitch would break the VPN server connection, which is fine since we don't want to establish a connection to a server that is not represented by the selected server/variable name. In case of a custom OVPN file, the variable is already derived from the file, so that that killswitch is assured to work correctly: https://github.com/MichaIng/DietPi/blob ... i-vpn#L128
  • Same with PROTOCOL, only that it does not play any role for a custom OVPN file. But since the variable is stored in the settings file, to avoid confusion, we could indeed get it from the custom OVPN file to have the settings file showing the correct protocol.
  • About PORT I agree that this should be scraped from the OVPN file. In case of ProtonVPN we currently use a variety of multiple ports, but to keep it simple I think we should stick with 1194 only: https://www.reddit.com/r/ProtonVPN/comm ... eing_used/
    It's the same with NordVPN. For a custom OVPN file, to not make it too complicated, we should as well expect a single remote (or port) entry only, so that we can scrape one port and use that for the killswitch.
trendy wrote: Tue Apr 06, 2021 11:40 am allow the VPN nameserver to be reachable from the ISP.
By the ISP? You mean by the client? Could you explain a bit more? I mean any DNS can be used, but requests are tunnelled. The same should be true when using the VPN provider's DNS, which should work even when not allowing to connect directly to it. But I think I misunderstand what you mean :).
User avatar
trendy
Posts: 340
Joined: Tue Feb 25, 2020 2:54 pm

Re: Purevpn gateway

Post by trendy »

MichaIng wrote: Fri Apr 09, 2021 2:28 pm
trendy wrote: Tue Apr 06, 2021 11:40 am to include also the FORWARD chain
What do you mean by this? It is dropped when the killswitch is enabled, so you mean to also allow forwarded requests to the VPN server and LAN by default, so that the VPN connection can be shared to the LAN?
Yes, the VPN can be shared with the LAN or a roadwarrior incoming to a VPN server.
MichaIng wrote: Fri Apr 09, 2021 2:28 pm
trendy wrote: Tue Apr 06, 2021 11:40 am to get the $VPN_SERVER, $PROTOCOL and $PORT from the ovpn config file.
  • VPN_SERVER in the first place is a variable to have the correct OVPN file selected/created. So in case of NordVPN and ProtonVPN it's the other way round: The variable defines the OVPN file. If it would not match the actually contained remote IP/hostname, then the killswitch would break the VPN server connection, which is fine since we don't want to establish a connection to a server that is not represented by the selected server/variable name. In case of a custom OVPN file, the variable is already derived from the file, so that that killswitch is assured to work correctly: https://github.com/MichaIng/DietPi/blob ... i-vpn#L128
  • Same with PROTOCOL, only that it does not play any role for a custom OVPN file. But since the variable is stored in the settings file, to avoid confusion, we could indeed get it from the custom OVPN file to have the settings file showing the correct protocol.
  • About PORT I agree that this should be scraped from the OVPN file. In case of ProtonVPN we currently use a variety of multiple ports, but to keep it simple I think we should stick with 1194 only: https://www.reddit.com/r/ProtonVPN/comm ... eing_used/
    It's the same with NordVPN. For a custom OVPN file, to not make it too complicated, we should as well expect a single remote (or port) entry only, so that we can scrape one port and use that for the killswitch.
Excellent! :)
MichaIng wrote: Fri Apr 09, 2021 2:28 pm
trendy wrote: Tue Apr 06, 2021 11:40 am allow the VPN nameserver to be reachable from the ISP.
By the ISP? You mean by the client? Could you explain a bit more? I mean any DNS can be used, but requests are tunnelled. The same should be true when using the VPN provider's DNS, which should work even when not allowing to connect directly to it. But I think I misunderstand what you mean :).
Let me clarify. I am not exactly sure at which point these rules will be applied, so I wanted to cover the case that the tunnel is still not up, so the nameserver to resolve the hostname of the tunnel endpoint needs to be routed over the ISP, hence it needs to be allowed.
Post Reply