Homewide VPN faces issues with Putty and code.
Homewide VPN faces issues with Putty and code.
Ok, premise is, want to set up a VPN for the whole network. Found a good video, with lots of great help here: https://www.youtube.com/watch?v=xFficDCEv3c&t I find his instructions incredibly clear, but I am not doing the same thing. I have managed to cobble my way through a great deal of what he is talking about, but I have hit a couple of walls, so wanted to see if anyone here had enough experience/knowledge and time to help me through this. One of the problems I encounter is that when I run the iptables.sh I get an error. (sudo bash iptables.sh) If I use Putty to ssh into the terminal, this error causes Putty to crash out, and I need to restart the VM to ssh back in. If I run the command from VNC wtihin Freenas, it gives some errors, but does complete. This is where it gets troublesome, if I run the iptables command from the VNC, whilst connected with Putty, it crashes putty. If I run the iptables without putty but then try and connect with putty, I don't have any joy. If I try and run 'connect.sh' from putty, it works just fine (sudo bash connect.sh) if I try and run connect.sh from VNC it fails, cannot resolve address. Now what I think is happening, somewhere, is that when I run the iptables it is too large for putty to handle, or too large for my 2 cpu and 2gb of RAM to handle through SSH, but can complete through VNC. However, when that happens, it is changing something, hence causing my Putty connection to break, and making it impossible for Putty to reconnect. This is the code for the iptables.sh #!/bin/bash # Flush iptables -t nat -F iptables -t mangle -F iptables -F iptables -X # Block All iptables -P OUTPUT DROP iptables -P INPUT DROP iptables -P FORWARD DROP # allow Localhost iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Make sure you can communicate with any DHCP server iptables -A OUTPUT -d 255.255.255.255 -j ACCEPT iptables -A INPUT -s 255.255.255.255 -j ACCEPT # Make sure that you can communicate within your own network iptables -A INPUT -s #.#.#.#/24 -d #.#.#.#/24 -j ACCEPT iptables -A OUTPUT -s #.#.#.#/24 -d #.#.#.#/24 -j ACCEPT # Allow established sessions to receive traffic: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow TUN iptables -A INPUT -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -o tun+ -j ACCEPT iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE iptables -A OUTPUT -o tun+ -j ACCEPT # allow VPN connection iptables -I OUTPUT 1 -p udp --destination-port 1194 -m comment --comment "Allow VPN connection" -j ACCEPT # Block All iptables -A OUTPUT -j DROP iptables -A INPUT -j DROP iptables -A FORWARD -j DROP # Log all dropped packages, debug only. iptables -N logging iptables -A INPUT -j logging iptables -A OUTPUT -j logging iptables -A logging -m limit --limit 2/min -j LOG --log-prefix "IPTables general: " --log-level 7 iptables -A logging -j DROP echo "saving" iptables-save > /etc/iptables.rules echo "done" #echo 'openVPN - Rules successfully applied, we start "watch" to verify IPtables in realtime (you can cancel it as usual CTRL + c)' #sleep 3 #watch -n 0 "sudo iptables -nvL" I have amended the iptables at: iptables -A OUTPUT -s #.#.#.#/24 -d #.#.#.#/24 -j ACCEPT To reflect my IP initial address xxx.xxx.1.1 I get the following error messages: iptables v1.8.4 (legacy): option "-s" requires an argument Try 'iptables -h' or 'iptables --help' for more informationiptables ' This occurs twice, and then is followed by saving done The saving/done is what it should do without the errors. I don't know if the errors are breaking it or whether it matters not. I then try to run the connect.sh from the VNC and the error is: RESOLVE: Cannot resolve host address: lon-004.vpn.privado.io:1194 (Temporary failure in name resolution) I have setup a rule to allow 1194, and as I mentioned above, if I run this same command from Putty, through SSH, it works just fine and completes no problem. What I can't work out is why I cannot connect using Putty and sudo bash iptables.sh - are those error messages too much for Putty to handle? or after I sudo bash iptables.sh from VNC, it stops Putty connecting at all. That part I just don't understand - why wouldn't it connect now? Why does it time out? When I check the VNC using ip address, the address is the one in which I direct Putty towards. So it hasn't changed just because I ran the iptables.sh. Yes the video is in promox but it is still running unbuntu, the promox stuff was just to get the VM up and running and shouldn't really affect the code. Unless the code changed between 18.04 and 20.04 (which is what I am running now)
These IPtables scripts seem to be reworking existing solutions. Avoid applying the default DROP rules until you’ve completed your setup; this is why SSH keeps complaining. Initially set policies to ACCEPT, then switch to DROP once everything is ready. Consider adding a line like iptables -A INPUT -p tcp -m tcp --dport=22 -m state --state NEW -m comment "Permit SSH access" after the relevant lines as a precaution when adjusting settings. #.#.#.#/24 Since the address isn’t a fixed IP, use iptables -A INPUT -s 192.168.1.0/24 -d 192.168.1.0/24 -m comment "Permit LAN traffic" as a temporary fix while you modify the rules. You also have options like iptables -A INPUT -i eth0 -m comment "Allow LAN connections" for easier management. When working with simpler iptables commands, remember to use -i for inputs and -o for outputs. For easier management, add entries in ~/.bashrc with aliases such as iplist, natlist, and manlist to view and edit rules by line number. This helps you remove temporary rules cleanly with commands like iptables -D INPUT [line]. It’s also wise to consider stricter rules in FORWARD if you’re planning a VPN connection. A more streamlined approach is to create a single "catch-all" table for all three tables, applying it via iptables -N FIREWALL and chaining rules appropriately. Remember to save your configuration with iptables-save, storing it in a file like ~/MyFirewall-0.1, and periodically update it with iptables-save > ~/MyFirewall-0.1. This way, you can revert changes easily if needed. Learning IPtables takes time, but once you master it, managing firewall rules becomes much more manageable. If you encounter issues, share the relevant commands and their outputs for troubleshooting.
After two hours of troubleshooting, I realized the issue wasn't about matching a percentage value. Once I addressed several factors and confirmed everything functioned, the VM started correctly. The problem remains with my Pi-Hole VM—its IP hasn't changed, and nothing else has shifted. I set a static IP through the VPN, but then configured it to use Pi-Hole first. However, I set the Gateway4 to point to the VPN's IP address. The setup for the VPN device (tun0) was configured properly, including MTA settings and IPv6 initialization. Once the IP configuration was resolved, Putty didn’t drop connections and is now working as expected. My suggestion for the code change is worth considering.
Configure the gateway on each client device to point to the VM's LAN IP, then direct traffic via tun0 to the internet. After setting up, display the output of ip addr ip route to verify routing.
UDP: network issue detected. Connection attempts are failing with code 101. The system is repeatedly restarting and entering a loop. No obvious changes were made to connect.sh, though the original iptables settings haven’t resolved the problem. The UNTAB install on Ubuntu in the VM needs five lines of code to start each boot, which is tiring. Consider a full reboot or checking the logs for more details.
Sleeping is for the weak, heh. I deleted the VM and plan to start fresh, aiming to dodge many of the errors I made initially. I’m trying to reach a stage where I can set up the VPN via iptables and connect both services, just like they did before. I’ll remember to apply the netplan, which hopefully will help everything function. This isn’t a plug-and-play situation. Still, I’ve picked up some Linux commands, just to get things working. Much of it remains unclear, but it’s becoming part of my skill set and I’m hoping for deeper insight as I continue.
Could have rested a bit longer. Noticed several adjustments outside the VPN, especially on the router, that stopped working once I switched the static IP. My PiHole server was now pointing to an inactive address, while the VPN kept redirecting me. Eventually fixed it with iptables, but when I did, everything went offline—my internet just froze.
Ensure you get a solid night's rest, and start fresh from the beginning. The setup is now functioning properly. VPN is active, Pi-Hole operates through it, and disconnecting from the VPN removes access to Pi-Hole. Everything is working well.