Search the Community

Sorry if this is a silly question but I can't find the answer anywhere. If you have a torrent client set to start on boot, and the torguard app (Raspberry Pi) lagged a few seconds behind it, would the torrent client be open to the original network for those few seconds? Does anyone know? Thanks!

Hi, Long time consumer here. I had received a copyright strike & I did some testing & After me voluntarily choosing to disconnect torguard the killswitch set to my torrent client takes about 10 - 15 seconds to see that that killswitch terminates torrent client after disconnect. I have torguard version 0.3.77.

If you are lucky to have pfsense box, then use this hack to create full proof kill switch: Firewall > Rules, Floating tab Action: Pass Disabled: unchecked Quick: checked Interface: WAN Direction: out TCP/IP Version: IPv4 Protocol: UDP Source: any Destination: TorGuard's IP ADDRESS Destination port range: VPN X port of TorGuard's VPN server Then below that rule: Action: Reject Disabled: unchecked Quick: checked Interface: WAN Direction: out TCP/IP Version: IPv4 Protocol: any Source: any Destination: any Destination port range: any That will allow outbound connections to only 1 IP on UDP X and block everything else. x = port

Hi All. I added Torguard to the kill switch list. Now I can not undo that as there is no settings panel to display any more. It connects auto, then when I disconnect, it shuts down & I have to log in again with the same results. I have uninstalled & reinstalled. No luck. I am now stuck on 1 server & cant change to another. I just want to take Torguard off the list. If I have to use the terminal, I will probably stroke out in a fit of swearing.

What's the most reliable way to implement an internet kill switch on VPN disconnection? I assume its either on-disconnection script to disable net adapters, or have the VPN manage the net adapters. What adapters need to be disabled? Is it the adapter that connects to the internet router or the TAP adapter or both? Is there an up to date guide anywhere? Thanks

How to remotely terminate a VPN connection while ensuring the remote computer is still able to access the internet via normal means? I would presume this might be possible by temporarily changing the "Service Password" under the 'Security' drop down menu in the Torguard Account Area, but if I do this, 1) Will I be able to change the password right back to what it was before? 2) Will this actually terminate any of my active Torguard VPN sessions, and if so, 3) Will the target computer still be able to access the internet normally, or will some sort of "kill switch" functionality disable the internet connection of the remote computer? A suggestion for Torguard support staff: I would recommend, in the 'My Services' section, that two additional options of functionality be added to the 'Management Actions' drop down box beside the listing for 'Anonymous VPN monthly,' consisting of: 1) Terminate active VPN sessions without kill switch, to still allow the target computer to access the internet, or 2) Terminate active VPN sessions while employing internet kill switch. That is just a suggestion. The problem I am having is one which I have already brought to the attention of Torguard Support but am still awaiting a resolution for. Shortly after I activate a VPN session on a remote computer which I am controlling via Teamviewer - the Teamviewer session terminates, and another successful Teamviewer connection to the remote computer cannot be made until maybe upwards of a half hour or so after the VPN is manually terminated by the support staff. While awaiting a resolution to this Teamviewer incompatibility, in the meantime I would like to know how I can remotely terminate the VPN connection of the remote machine myself so I can regain Teamviewer control, without having to rely upon Torguard Support to do it for me? Torguard Support just so happens to be closed right now. -Thank you.

This hack will create PF firewall rules on mac that will only allow in/out traffic to single IP (TG's VPN server in this case). When disconnect happens, you won't be able to surf, and only pinging that IP works. 1) Open Temrinal and type this
 sudo nano /etc/pf.conf Enter your admin password after that, and PF file will open 2) Scroll to the bottom, and add the following at the bottom --------- block out on en0 from 192.168.0.0/16 to any block out on en3 from 192.168.0.0/16 to any pass out quick on en0 from 192.168.0.0/16 to 178.162.216.8 pass out quick on en3 from 192.168.0.0/16 to 178.162.216.8 pass out quick on utun0 from any to any --------- These rules will block traffic on ethernet and on wifi, unless that traffic is going towards 178.162.216.8 (IP of TG's for example) or unless VPN is connected (last line), then traffic is allowed. Here utun0 is name of our virtual VPN adapter, and en0 and en3 are names of ethernet and wifi. You can find out those names by running “ifconfig†in terminal.
 3) Enable PF, by running in termial: sudo pfctl -e 4) Load the rules sudo pfctl -f /etc/pf.conf Now if VPN gets disconnected, you won't have access to internet, not counting the IP address specified before 5) To regain Internet access, disable PF in terminal sudo pfctl -d

Hi, I used TG Pro software. My problem is when connection drop, TG software should show the message that VPN disconnected or somethings like that. I though problem was reconnect option and disable it. I am very confused now. Because software sometimes show the message that TG is dc and sometime don't. Reconnect option is disable but not working!!! I reinstall program, disable firewall and ....but can't find the solution. it's important for me because i use Kill Switch option. When software showing the message Kill Switch works truly, otherwise its not working. someone can help?

forget about software kill switches, as you can't trust them in firewall, in ddwrt, put this line iptables -I FORWARD -s 192.168.0.0/16 -o $(nvram get wan_iface) -j DROP this will include from 192.168.0.0 to 192.168.255.255 no single machine with those internal IPs will be access the net, if VPN is not up. this is the real deal, tried and tested, works like a charm ——————— i - insert FORWARD - for packets being forwarded through the router s - source o - defining interface physical name $(nvram get wan_iface) - gets the wan interface name j - jumps to drop - packets are dropped