Hey the new dietpi-vpn addition to v7.2 is great but I’m having issues with the killswitch.
I am able to enable it after it automatically installs iptables, but upon a reboot I’m unable to connect to my Raspberry Pi 4. I see it successfully connect to my router, but it is unresponsive via SSH after turning on killswitch and rebooting. What settings should I be changing to allow SSH? I’m assuming I need to adjust iptables? I’m trying to do a headless setup
Are you running ssh daemon on the regular port 22 or some custom port?
Should be port 22, I did a fresh install of dietpi and went straight to configuring dietpi-vpn
Should be port 22, I did a fresh install of dietpi and went straight to configuring dietpi-vpn
MichaIng I think the current killswitch is lacking ssh for remote administration.
vbarter edit /var/lib/dietpi/dietpi-vpn/killswitch.rules and add:
-A INPUT -s 192.168.0.0/16 -m conntrack --ctstate NEW -p tcp --dport 22 -j ACCEPT
-A INPUT -s 172.16.0.0/12 -m conntrack --ctstate NEW -p tcp --dport 22 -j ACCEPT
-A INPUT -s 10.0.0.0/8 -m conntrack --ctstate NEW -p tcp --dport 22 -j ACCEPT
before the last line with COMMIT
The killswitch should allow any requests coming from the LAN. vbarter, could you post the output of:
hostname -i
root@DietPi:~# hostname -i
127.0.1.1
Should make those edits to killswitch file in the comment above?
Sorry, my bad. Could you post:
hostname -I
instead? Those edits probably won’t change anything, but if you want to try you can.
root@DietPi:~# hostname -I
192.168.1.108 10.8.8.11
The first IP is my local IP on my network, 2nd is the VPN external IP
Pi works fine with SSH with killswitch turned off so I don’t dare turn it on for now.
It is all as intended (while probably not as wanted):
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -d 192.168.0.0/16 -j ACCEPT
-A OUTPUT -d 172.16.0.0/12 -j ACCEPT
-A OUTPUT -d 10.0.0.0/8 -j ACCEPT
-A OUTPUT -d $VPN_SERVER -p $PROTOCOL --dport $VPN_PORT -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
So incoming packets are only allowed from the loopback interface (so the system can connect to locally running servers) and from established connections. With this is impossible to initiate a connection from anywhere else.
The killswitch’s major task is to prevent the system from doing WAN connections as fast as the VPN tunnel is down. Wouldn’t it hence be okay to simply allow ANY incoming packet? For LAN connections there is generally no issue with this, is it? For WAN connections, as long as the VPN is up, the system is anyway forced by routes to “answer” through the tunnel, hence practically also inbound www connections are only possible through the tunnel, which most VPN providers do no support (port forwarding through the VPN), but some do, which is then great to have support for. As fast as the VPN is down, the iptables OUTPUT rules still prevent the system from answering to WAN, so while incoming packets can arrive, they do not lead to working connections? Or would this imply paths to bypass the killswitch, or weaken it otherwise?
Hello,
Thanks for this idea, but after making the change to that killswitch.rules file it does not save if I ever turn off the killswitch option in dietpi-vpn. I made the edit, reconnected vpn, but when I try to turn off the killswitch that rules file disappears when I check via ls command. When I re-enable the killswitch it appears a fresh, unmodified killswitch.rules is created.
Thank you @MichaIng for marking this as an potential improvement in github. I hope it can possibly be an option for SSH within local network only. For now I’m using Up and Down scripts to stop and start the specific software I want under VPN.
Currently iptables changes would need to be done via “up” script that can be configured in dietpi-vpn as well. Add the iptables commands to add those rules individually. That script runs after the others, after the tunnel has been established and the other killswitch rules have been applied.
Don’t forget to prefix iptables before the -A …
I added it now like that: https://github.com/MichaIng/DietPi/commit/cbad2b84702c0a18c68eb5b5da591dee92988080
As explained in the commit text, the OUTPUT rules limit possible SSH connections to LAN and VPN, so the additional filters, respectively adding the rule for each LAN IP range doesn’t make a difference compared to the single rule, or do I overlook something?
Looks good to me.
Would adding the following rule to the dietpi-vpn “up” script be the best way to allow local access to the Transmission web interface while connected to a VPN service?
iptables -A INPUT -s 192.168.0.0/16 -m conntrack --ctstate NEW -p tcp --dport 9091 -j ACCEPT
I’ve adapted this code from the above posts, as I’m not very familiar with iptable rules.
The -m conntrack --ctstate NEW can be skipped, as ESTABLISHED state incoming packets are allowed anyway. No sure whether there is any measurable overhead involved when a rule uses another module to to another check.
If 192.168.0.0 - 192.168.255.255 is the range or our LAN IPs, then this is correct, but usually only the last octal is variable, so that 192.168.0.0/24 would be tighter to include only 192.168.0.0 - 192.168.0.255.
Wonderful, thank you!
I’ve adjusted my rules as per your guidance:
# Allow local access to Transmission web interface
iptables -A INPUT -s 192.168.10.0/24 -p tcp --dport 9091 -j ACCEPT