MichaIng
WireGuard client | Add split tunnel functionality
Required Information
DietPi version | 7.1.2
Distro version | Buster
Kernel version | 4.9.241-arm64 #1 SMP PREEMPT Thu Feb 25 17:57:15 CET 2021 aarch64 GNU/Linux
SBC model | Odroid C4/HC4 (aarch64)
Power supply used | 12V 2A
SDcard used | 32GB eMMC Module
Additional Information (if applicable)
Software title | Deluge-web and qbittorrent
Was the software title installed freshly or updated/migrated? Freshly installed using dietpi-software
Can this issue be replicated on a fresh installation of DietPi? It is a fresh installation
Steps to reproduce
- Use dietpi-software to install deluge or qbittorent
- Try to open the webpage (port 8112 or 1340) on a laptop
Expected behaviour
- The webpage should open
Actual behaviour
- Timeout error
Extra details
- Pihole is running as well and their page ip/admin is working fine, so the problem seems related to the port number?
Hi,
Pihole is running on a standard web server while your other applications have an own one. There is no relationship between them.
Pls can you post ss -tulpn | grep LISTEN
Thank you, that makes sense.
ss -tulpn | grep LISTEN
tcp LISTEN 0 50 0.0.0.0:445 0.0.0.0:* users:(("smbd",pid=11905,fd=31))
tcp LISTEN 0 5 0.0.0.0:6881 0.0.0.0:* users:(("qbittorrent-nox",pid=11945,fd=32))
tcp LISTEN 0 10 0.0.0.0:9090 0.0.0.0:* users:(("kodi-aml",pid=2549,fd=46))
tcp LISTEN 0 5 127.0.0.1:4711 0.0.0.0:* users:(("pihole-FTL",pid=2376,fd=10))
tcp LISTEN 0 50 0.0.0.0:139 0.0.0.0:* users:(("smbd",pid=11905,fd=32))
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("lighttpd",pid=11935,fd=4))
tcp LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("kodi-aml",pid=2549,fd=54))
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=2376,fd=5))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=2454,fd=3))
tcp LISTEN 0 50 *:1340 *:* users:(("qbittorrent-nox",pid=11945,fd=45))
tcp LISTEN 0 50 [::]:445 [::]:* users:(("smbd",pid=11905,fd=29))
tcp LISTEN 0 5 [::]:6881 [::]:* users:(("qbittorrent-nox",pid=11945,fd=31))
tcp LISTEN 0 10 [::]:9090 [::]:* users:(("kodi-aml",pid=2549,fd=55))
tcp LISTEN 0 5 [::1]:4711 [::]:* users:(("pihole-FTL",pid=2376,fd=13))
tcp LISTEN 0 50 [::]:139 [::]:* users:(("smbd",pid=11905,fd=30))
tcp LISTEN 0 128 [::]:80 [::]:* users:(("lighttpd",pid=11935,fd=5))
tcp LISTEN 0 128 [::]:8080 [::]:* users:(("kodi-aml",pid=2549,fd=53))
tcp LISTEN 0 128 *:21 *:* users:(("proftpd",pid=11883,fd=0))
tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=2376,fd=7))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=2454,fd=4))
Deluge doesn't seems to be running at all. Can you do a reboot and check running service afterwards dietpi-services status
I removed deluge to try if qbittorent would work.
[ OK ] DietPi-Services | avahi-daemon active (running) since Thu 2021-05-20 11:30:39 CEST; 28min ago
[ OK ] DietPi-Services | proftpd active (running) since Thu 2021-05-20 11:30:39 CEST; 28min ago
[ OK ] DietPi-Services | nmbd active (running) since Thu 2021-05-20 11:30:39 CEST; 28min ago
[ OK ] DietPi-Services | smbd active (running) since Thu 2021-05-20 11:30:40 CEST; 28min ago
[ OK ] DietPi-Services | php7.3-fpm active (running) since Thu 2021-05-20 11:30:40 CEST; 28min ago
[ OK ] DietPi-Services | lighttpd active (running) since Thu 2021-05-20 11:30:40 CEST; 28min ago
[ OK ] DietPi-Services | qbittorrent active (running) since Thu 2021-05-20 11:30:40 CEST; 28min ago
[ OK ] DietPi-Services | cron active (running) since Thu 2021-05-20 11:30:40 CEST; 28min ago
[ OK ] DietPi-Services | ssh active (running) since Thu 2021-05-20 11:03:28 CEST; 55min ago
[ OK ] DietPi-Services | fail2ban active (running) since Thu 2021-05-20 11:03:09 CEST; 55min ago
[ OK ] DietPi-Services | pihole-FTL active (running) since Thu 2021-05-20 11:03:09 CEST; 55min ago
[ INFO ] DietPi-Services | dietpi-vpn inactive (dead)
[ OK ] DietPi-Services | dietpi-ramlog active (exited) since Thu 2021-05-20 11:03:08 CEST; 55min ago
[ OK ] DietPi-Services | dietpi-preboot active (exited) since Thu 2021-05-20 11:03:09 CEST; 55min ago
[ OK ] DietPi-Services | dietpi-boot active (exited) since Thu 2021-05-20 11:03:28 CEST; 55min ago
[ OK ] DietPi-Services | dietpi-postboot active (exited) since Thu 2021-05-20 11:03:28 CEST; 55min ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor inactive (dead)
I'll reinstall deluge.
I removed deluge
Ok in this case it's clear that I can't find it in the list 😅
After installing deluge via dietpi-software:
[ OK ] DietPi-Services | avahi-daemon active (running) since Thu 2021-05-20 12:04:51 CEST; 7s ago
[ OK ] DietPi-Services | proftpd active (running) since Thu 2021-05-20 12:04:51 CEST; 7s ago
[ OK ] DietPi-Services | nmbd active (running) since Thu 2021-05-20 12:04:51 CEST; 6s ago
[ OK ] DietPi-Services | smbd active (running) since Thu 2021-05-20 12:04:52 CEST; 6s ago
[ OK ] DietPi-Services | php7.3-fpm active (running) since Thu 2021-05-20 12:04:52 CEST; 6s ago
[ OK ] DietPi-Services | lighttpd active (running) since Thu 2021-05-20 12:04:52 CEST; 6s ago
[ OK ] DietPi-Services | qbittorrent active (running) since Thu 2021-05-20 12:04:52 CEST; 6s ago
[ OK ] DietPi-Services | deluged active (running) since Thu 2021-05-20 12:04:52 CEST; 6s ago
[ OK ] DietPi-Services | deluge-web active (running) since Thu 2021-05-20 12:04:53 CEST; 6s ago
[ OK ] DietPi-Services | cron active (running) since Thu 2021-05-20 12:04:53 CEST; 6s ago
[ OK ] DietPi-Services | ssh active (running) since Thu 2021-05-20 11:03:28 CEST; 1h 1min ago
[ OK ] DietPi-Services | fail2ban active (running) since Thu 2021-05-20 11:03:09 CEST; 1h 1min ago
[ OK ] DietPi-Services | pihole-FTL active (running) since Thu 2021-05-20 11:03:09 CEST; 1h 1min ago
[ INFO ] DietPi-Services | dietpi-vpn inactive (dead)
[ OK ] DietPi-Services | dietpi-ramlog active (exited) since Thu 2021-05-20 11:03:08 CEST; 1h 1min ago
[ OK ] DietPi-Services | dietpi-preboot active (exited) since Thu 2021-05-20 11:03:09 CEST; 1h 1min ago
[ OK ] DietPi-Services | dietpi-boot active (exited) since Thu 2021-05-20 11:03:28 CEST; 1h 1min ago
[ OK ] DietPi-Services | dietpi-postboot active (exited) since Thu 2021-05-20 11:03:28 CEST; 1h 1min ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor inactive (dead)
and
tcp LISTEN 0 50 0.0.0.0:445 0.0.0.0:* users:(("smbd",pid=17239,fd=31))
tcp LISTEN 0 50 0.0.0.0:58846 0.0.0.0:* users:(("deluged",pid=17291,fd=16))
tcp LISTEN 0 5 0.0.0.0:6881 0.0.0.0:* users:(("qbittorrent-nox",pid=17281,fd=33))
tcp LISTEN 0 5 0.0.0.0:6882 0.0.0.0:* users:(("deluged",pid=17291,fd=12))
tcp LISTEN 0 10 0.0.0.0:9090 0.0.0.0:* users:(("kodi-aml",pid=2549,fd=46))
tcp LISTEN 0 5 127.0.0.1:4711 0.0.0.0:* users:(("pihole-FTL",pid=2376,fd=10))
tcp LISTEN 0 50 0.0.0.0:139 0.0.0.0:* users:(("smbd",pid=17239,fd=32))
tcp LISTEN 0 50 0.0.0.0:8112 0.0.0.0:* users:(("deluge-web",pid=17302,fd=5))
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("lighttpd",pid=17271,fd=4))
tcp LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("kodi-aml",pid=2549,fd=54))
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=2376,fd=5))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=2454,fd=3))
tcp LISTEN 0 50 *:1340 *:* users:(("qbittorrent-nox",pid=17281,fd=46))
tcp LISTEN 0 50 [::]:445 [::]:* users:(("smbd",pid=17239,fd=29))
tcp LISTEN 0 5 [::]:6881 [::]:* users:(("qbittorrent-nox",pid=17281,fd=32))
tcp LISTEN 0 5 [::]:6882 [::]:* users:(("deluged",pid=17291,fd=10))
tcp LISTEN 0 10 [::]:9090 [::]:* users:(("kodi-aml",pid=2549,fd=55))
tcp LISTEN 0 5 [::1]:4711 [::]:* users:(("pihole-FTL",pid=2376,fd=13))
tcp LISTEN 0 50 [::]:139 [::]:* users:(("smbd",pid=17239,fd=30))
tcp LISTEN 0 128 [::]:80 [::]:* users:(("lighttpd",pid=17271,fd=5))
tcp LISTEN 0 128 [::]:8080 [::]:* users:(("kodi-aml",pid=2549,fd=53))
tcp LISTEN 0 128 *:21 *:* users:(("proftpd",pid=17216,fd=0))
tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=2376,fd=7))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=2454,fd=4))
Still a timeout
Do you have any firewall or port blocker installed? Your services are LISTEN to correct port. Usually it should work using local IP 🤔
My old RPI3 is still up and running deluge and is perfectly accessible via browser and the Deluge application on the same laptop I trying to reach the Odroid.
Could this be related to Unbound?
If you use a local IP, unbound is not involved as unbound is responsible for DNS resolution.
I did a short test on a RPi4 64bit and both deluge as well as qbit working within issue.
Thank you for trying.
I ran:
sudo pkill deluge-web
deluge-web
Obviously it's not running in the background then, however the web page is loading now.
-edit-
Killed it again, ran
deluge-web --fork
Webpage is working fine.
CTRL-C or closing the ssh connection stops the service obviously.
But this is not a permanent solution and deluge will not work after reboot I guess.
Can you reboot your system again and check deluge afterwards. I guess it's not accessible. As a test you could restart the service to see what happens
systemctl restart deluge-web.service
Thanks again for your support!
Rebooted, still got the timeout Restarted the service, still got a timeout
Ok let's stop the deluge service an try to start it manually
systemctl restart deluge-web.service
sudo -u debian-deluged /usr/bin/deluge-web -l /var/log/deluged/web.log -L warning
systemctl restart deluge-web.service
sudo -u debian-deluged /usr/bin/deluge-web -l /var/log/deluged/web.log -L warning
Traceback (most recent call last):
File "/usr/bin/deluge-web", line 11, in <module>
load_entry_point('deluge==1.3.15', 'console_scripts', 'deluge-web')()
File "/usr/lib/python2.7/dist-packages/deluge/ui/web/web.py", line 144, in start
web.start()
File "/usr/lib/python2.7/dist-packages/deluge/ui/web/web.py", line 131, in start
self.server.start()
File "/usr/lib/python2.7/dist-packages/deluge/ui/web/server.py", line 670, in start
self.start_normal()
File "/usr/lib/python2.7/dist-packages/deluge/ui/web/server.py", line 678, in start_normal
self.socket = reactor.listenTCP(self.port, self.site, interface=self.interface)
File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 495, in listenTCP
p.startListening()
File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 1363, in startListening
raise CannotListenError(self.interface, self.port, le)
twisted.internet.error.CannotListenError: Couldn't listen on 0.0.0.0:8112: [Errno 98] Address already in use.
Whoops typo. Stop the service not restart 😃
systemctl stop deluge-web.service sudo -u debian-deluged /usr/bin/deluge-web -l /var/log/deluged/web.log -L warning
No error messages, but the website still timeouts.
If I stop the service again and try your second command with --fork I get:Couldn't listen on 0.0.0.0:8112: [Errno 98] Address already in use. again.
First you would need to ensure that there is no deluge-web process running before you could try to start it manually
Yeah, I did:
root@odroid:~# systemctl stop deluge-web.service
root@odroid:~# systemctl status deluge-web.service
● deluge-web.service - Deluge Web UI (DietPi)
Loaded: loaded (/etc/systemd/system/deluge-web.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:deluge-web
May 20 12:51:36 odroid systemd[1]: deluge-web.service: Succeeded.
May 20 12:51:36 odroid systemd[1]: Stopped Deluge Web UI (DietPi).
May 20 12:51:36 odroid systemd[1]: Started Deluge Web UI (DietPi).
May 20 13:00:23 odroid systemd[1]: Stopping Deluge Web UI (DietPi)...
May 20 13:00:23 odroid systemd[1]: deluge-web.service: Succeeded.
May 20 13:00:23 odroid systemd[1]: Stopped Deluge Web UI (DietPi).
May 20 13:00:23 odroid systemd[1]: Started Deluge Web UI (DietPi).
May 20 13:32:52 odroid systemd[1]: Stopping Deluge Web UI (DietPi)...
May 20 13:32:52 odroid systemd[1]: deluge-web.service: Succeeded.
May 20 13:32:52 odroid systemd[1]: Stopped Deluge Web UI (DietPi).
root@odroid:~# sudo -u debian-deluged /usr/bin/deluge-web --fork -l /var/log/deluged/web.log -L warning
root@odroid:~# Traceback (most recent call last):
File "/usr/bin/deluge-web", line 11, in <module>
load_entry_point('deluge==1.3.15', 'console_scripts', 'deluge-web')()
File "/usr/lib/python2.7/dist-packages/deluge/ui/web/web.py", line 144, in start
web.start()
File "/usr/lib/python2.7/dist-packages/deluge/ui/web/web.py", line 131, in start
self.server.start()
File "/usr/lib/python2.7/dist-packages/deluge/ui/web/server.py", line 670, in start
self.start_normal()
File "/usr/lib/python2.7/dist-packages/deluge/ui/web/server.py", line 678, in start_normal
self.socket = reactor.listenTCP(self.port, self.site, interface=self.interface)
File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 495, in listenTCP
p.startListening()
File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 1363, in startListening
raise CannotListenError(self.interface, self.port, le)
twisted.internet.error.CannotListenError: Couldn't listen on 0.0.0.0:8112: [Errno 98] Address already in use.
Did a reboot.
ps -ef | grep deluge-web:
debian-+ 2693 1 0 13:52 ? 00:00:03 /usr/bin/python /usr/bin/deluge-web -l /var/log/deluged/web.log -L warning
root 3843 3801 0 14:01 pts/0 00:00:00 grep --color=auto deluge-web
Just to give deluge a bit of a break, for example the Kodi web interface (port 8080) is indeed reachable.
Again a different web application running it's own server without any relationship to deluge
I know, thank you, but I'm still not sure if this is related to deluge or a general port issue. Because qbittorent (port 1340) is also still unavailable.
It's not a general issue. It seems these 2 application get blocked somewhere
Hmm, could it be related to the fact both services are running under a user name that is not root?
As long as the process did bind to the listening socket, the user that achieved this, doesn't play a role for network connectivity. But of course when it's about local file access and such, it does.
Please try to get more output when running it as intended user:
systemctl stop deluge-web
killall deluge-web
sudo -u debian-deluged /usr/bin/deluge-web -L info
Keep running it in foreground and test to access the web interface, so you don't need to worry about still running background processes and can easily terminate it via CTRL+C.
Thank you for investigating. Still received a timeout.
[INFO ] 20:36:11 ui:124 Deluge ui 1.3.15
[INFO ] 20:36:11 ui:127 Starting web ui..
[INFO ] 20:36:12 server:666 Starting server in PID 9220.
[INFO ] 20:36:12 server:679 Serving on 0.0.0.0:8112 view at http://0.0.0.0:8112
Nothing more...
Debug log doesn't show anything different, right?
sudo -u debian-deluged deluge-web -L debug
Okay when running as root works, then probably because a different config file is used. Here the config we install: https://github.com/MichaIng/DietPi/blob/dev/.conf/dps_45/deluge_web.conf Can you check which one is used by root:
cat /root/.config/deluge/web.conf
And replace it with the one used by the Deluge user:
cp /mnt/dietpi_userdata/deluge/.config/deluge/web.conf /root/.config/deluge/web.conf
deluge-web -L debug
Aha! The log showed me nothing new, but replacing the file worked. I couldn't log in, but the website responded immediately.
The website responded after running the last command? This means indeed with root user and exact same config used by the service it does work, which is strange.
Can you show the following:
getent passed debian-deluged
And when you start the service with Deluge user and do a local curl access, what is the result?
sudo -u debian-deluged deluge-web --fork -L debug
sleep 5
curl -IL 127.0.0.1:8112
killall deluge-web
Yes the website responded. Of course I've rebooted in the mean time, so it's not working anymore.
getent passwd debian-deluged
debian-deluged:x:106:112::/mnt/dietpi_userdata/deluge:/usr/sbin/nologin
I killed all deluge process first, ran your command:
...
[INFO ] 11:00:21 server:679 Serving on 0.0.0.0:8112 view at http://0.0.0.0:8112
curl -IL 127.0.0.1:8112
HTTP/1.1 200 OK
Date: Sat, 22 May 2021 09:00:25 GMT
Content-Length: 1949
Content-Type: text/html; charset=utf-8
Server: TwistedWeb/18.9.0
But I still can't reach it from my laptop.
Are you sure you are using http to connect to the side as not https? Did you tried it on a different device?
Yup, multiple devices and browsers. And like I said, other services like pihole can be reached perfectly fine. Thank you for checking though.
And file permissions are all correct?
ls -al /mnt/dietpi_userdata/deluge/
And what happens when you run the curl command from another system, using the local IP? This can be also done from Windows cmd.exe.
Did we rule out firewall and routing rules?
iptables -L
ip rule
Next would be to check whether the packages even arrive at the server:
apt install tcpdump
tcpdump 'port = 8112'
# Then try to access
Thank you again for your patience.
ls -al /mnt/dietpi_userdata/deluge/
total 12
drwxr-xr-x 3 debian-deluged debian-deluged 4096 May 20 12:04 .
drwxrwxr-x 7 dietpi dietpi 4096 May 22 00:01 ..
drwxr-xr-x 3 debian-deluged debian-deluged 4096 May 20 12:04 .config
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ip rule
0: from all lookup local
32764: from all uidrange 0-0 lookup main suppress_prefixlength 0
32765: not from all fwmark 0xca6c uidrange 0-0 lookup 51820
32766: from all lookup main
32767: from all lookup default
tcpdump port 8112
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:31:02.918554 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619650164 ecr 0,sackOK,eol], length 0
16:31:03.174033 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126769271 ecr 0,sackOK,eol], length 0
16:31:03.191521 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619650429 ecr 0,sackOK,eol], length 0
16:31:03.294296 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619650531 ecr 0,sackOK,eol], length 0
16:31:03.396667 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619650633 ecr 0,sackOK,eol], length 0
16:31:03.443867 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126769536 ecr 0,sackOK,eol], length 0
16:31:03.499689 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619650735 ecr 0,sackOK,eol], length 0
16:31:03.566622 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126769638 ecr 0,sackOK,eol], length 0
16:31:03.603812 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619650837 ecr 0,sackOK,eol], length 0
16:31:03.653475 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126769740 ecr 0,sackOK,eol], length 0
16:31:03.759650 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126769842 ecr 0,sackOK,eol], length 0
16:31:03.809437 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619651037 ecr 0,sackOK,eol], length 0
16:31:03.866276 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126769944 ecr 0,sackOK,eol], length 0
16:31:04.065079 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126770145 ecr 0,sackOK,eol], length 0
16:31:04.215579 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619651437 ecr 0,sackOK,eol], length 0
16:31:04.481927 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126770545 ecr 0,sackOK,eol], length 0
16:31:05.026596 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619652237 ecr 0,sackOK,eol], length 0
16:31:05.272265 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126771345 ecr 0,sackOK,eol], length 0
16:31:06.631336 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3619653837 ecr 0,sackOK,eol], length 0
16:31:06.897804 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 4126772945 ecr 0,sackOK,eol], length 0
16:31:09.844112 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,sackOK,eol], length 0
16:31:10.106446 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,sackOK,eol], length 0
16:31:16.290841 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,sackOK,eol], length 0
16:31:16.516292 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,sackOK,eol], length 0
16:31:22.680188 IP 192.168.1.247.55011 > 192.168.1.18.8112: Flags [S], seq 3123142943, win 65535, options [mss 1460,sackOK,eol], length 0
16:31:22.941609 IP 192.168.1.247.55012 > 192.168.1.18.8112: Flags [S], seq 2865851884, win 65535, options [mss 1460,sackOK,eol], length 0
Hmm traffic is received but nothing happen on this. Deluge was active right?
I suppose so:
systemctl status deluge-web.service
● deluge-web.service - Deluge Web UI (DietPi)
Loaded: loaded (/etc/systemd/system/deluge-web.service; disabled; vendor preset: enabled)
Active: active (running) since Sat 2021-05-22 11:49:05 CEST; 5h 5min ago
Docs: man:deluge-web
Main PID: 2776 (deluge-web)
Tasks: 1 (limit: 3844)
Memory: 43.8M
CGroup: /system.slice/deluge-web.service
└─2776 /usr/bin/python /usr/bin/deluge-web -l /var/log/deluged/web.log -L warning
May 22 11:49:05 odroid-lk-main systemd[1]: Started Deluge Web UI (DietPi).
Something strange perhaps:
/var/log/deluged# ls -al
total 0
drwxr-s--- 2 debian-deluged adm 80 May 20 13:36 .
drwxr-xr-x 10 root root 400 May 20 12:04 ..
-rw-rw-r-- 1 debian-deluged adm 0 May 22 12:17 daemon.log
-rw-r----- 1 debian-deluged adm 0 May 22 11:49 web.log
Why strange? You mean because those are empty? That might be because of hourly RAMlog clearing.
Hmm, on all my systems I only see these:
# ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
You additionally have:
32764: from all uidrange 0-0 lookup main suppress_prefixlength 0
32765: not from all fwmark 0xca6c uidrange 0-0 lookup 51820
When searching for those, they appear in combination with a VPN (routing table 51820 is the default used by WireGuard) connection active. Of course with a VPN client running, you cannot connect to services at the same system as it is forced to answer through the VPN tunnel, so never reaches the requesting client.
The following might work to bypass the VPN:
ip rule add to 192.168.1 lookup main
This should force all requests to your LAN to use the main routing table instead of the 51820 one added by WireGuard.
Ok, that made things much clearer.
Adding the ip rule didn't work though. I'm an absolute noob regarding this stuff however. When i ran sudo systemctl stop [email protected] the ip rules are cleared and the deluge site is reachable again. At least you narrowed it down to the VPN server. On my old RPI I was running openvpn instead of wireguard. I tried installing openvpn through dietpi-vpn but my vpn provider didn't provide me with a ovpn file so that failed. So I switched to wireguard, got it running and thought it was a good idea overall.
Okay that makes all sense. Yes I'm also a bit new to these rules. When you added the one I suggested, can you show again:
ip rule
It needs to be added with a higher priority (lower first number) than the two VPN rules. What I found is that its by default slightly higher priority, but maybe that is not always true. The priority can also be set manually:
ip rule add to 192.168.1 lookup main priority 32000
There are a few other concepts, do do it with connection marks and such, or based on port or user. But that requires some testing. Good would be if we find a simple rule that allows connections (incoming and outgoing packets) to the local network by default. With OpenVPN that works by default (it does not add rules, but routes only), with WireGuard obviously not.
Okay, here are the results:
# ip rule
0: from all lookup local
32764: from all uidrange 0-0 lookup main suppress_prefixlength 0
32765: not from all fwmark 0xca6c uidrange 0-0 lookup 51820
32766: from all lookup main
32767: from all lookup default
root@odroid-lk-main:~# ip rule add to 192.168.1 lookup main priority 32000
root@odroid-lk-main:~# ip rule
0: from all lookup local
32000: from all to 192.168.1.0 uidrange 0-0 lookup main
32764: from all uidrange 0-0 lookup main suppress_prefixlength 0
32765: not from all fwmark 0xca6c uidrange 0-0 lookup 51820
32766: from all lookup main
32767: from all lookup default
Result: timeout
If using openvpn or dietpi-vpn somehow works better or easier, I'm fine with that too.
32000: from all to 192.168.1.0 uidrange 0-0 lookup main
The UID range was set as well, somehow, and 0-0 does only match the root user. That is also the reason why when running services with the root user, access works, as the WireGuard rules as well apply to the root user only, respectively the second one for non-root users only, applying the different routing table. So we'd need to set this to include the Deluge user, we simply use 5000 as upper range, which covers all current and potential new users:
ip rule del to 192.168.1 lookup main priority 32000
ip rule add to 192.168.1 uidrange 0-5000 lookup main priority 32000
That doesn't seem to work unfortunately.
ip rule add to 192.168.1 uidrange 0-5000 lookup main priority 32000
ip rule
0: from all lookup local
32000: from all to 192.168.1.0 uidrange 0-0 lookup main
32764: from all uidrange 0-0 lookup main suppress_prefixlength 0
32765: not from all fwmark 0xca6c uidrange 0-0 lookup 51820
32766: from all lookup main
32767: from all lookup default
Still a timeout. Also, rebooting removes this new rule anyway. I guess one problem at a time, thank you so much for helping.
Strange, I have to play with the syntax as well then. So it's a general issue/question about how to enable LAN access to (non-root) services on a machine, when running a WireGuard client on it, as WireGuard then adds a new routing table and related rules which apply to non-root users with a higher priority than the main routing table. This is indeed different compared to OpenVPN, which adds two routes (no routing table/rule) for the lower and upper half of the complete IP range and hence override the default route, but have still a lower priority (less specific) than LAN routes.
I've added a allowed IP range in the Wireguard conf file for now:
"On the client, add your LAN’s subnet under AllowedIPs. For example, if your subnet is 192.168.1.x, change AllowedIPs to look like this:"
AllowedIPs = 192.168.2.0/24, 192.168.1.0/24
Source: https://www.stavros.io/posts/how-to-configure-wireguard/
You did this on the DietPi system where you run Deluge etc? That should explicitly break LAN connections since AllowedIPs defines which IP ranges to tunnel. So now the system tunnels LAN connections through the VPN but nothing else. Or did I misunderstand your setup? This is how I understand it:
- DietPi runs Deluge/qBittorrent, and it runs WireGuard as client to connect to a public Mullvad server.
- You want to access to these Deluge/qBittorrent web interfaces from other PCs on your home network without using any VPN client on these.
- If this is true, adding
AllowedIPs = 192.168.2.0/24, 192.168.1.0/24to the WireGuard client config on the DietPi system should break both, the Mullvad connection and all LAN connections (from 192.168.[12].* IP ranges) 🤔.
My conf file looks like this:
AllowedIPs = 0.0.0.0/0,::0/0,192.168.1.0/24 I've added the last entry.
If I run curl https://am.i.mullvad.net/connected I get indeed: You are not connected to Mullvad. Your IP address is [my local IP]
However, if I setup Deluge to use SOCKS5 proxy as per Mullvads instructions (https://mullvad.net/en/help/socks5-proxy/) then I suppose it works, because if I add a torrent file to check you IP, I get the IP from Mullvad.
AllowedIPs = 0.0.0.0/0,::0/0,192.168.1.0/24
In this case, the added IP should have no effect, and what I stated above stays true: The first two entries mean that every request shall be tunnelled, so the LAN IP range is first of all included, as long as not overwritten by other defined routes or rules. But probably it indirectly has an effect. How does the WireGuard routing table actually look like?
ip r l table 51820
You are not connected to Mullvad. Your IP address is [my local IP]
You mean your regular public IP, not your "local=LAN" IP, don't you?
That it works with the SOCKS5 proxy does not necessarily mean the all your traffic (aside of LAN) is tunnelled, as that proxy uses explicitly the VPN servers internal IP. So it is possible that only requests to 10.64.* are tunnelled, while everything else is bypassing the VPN. A route for the subnet of the interface itself is default, but what we want is routing everything through the VPN, excluding only the LAN range. Would be awesome if WireGuard had an UnallowedIPs setting to exclude subnets within the AllowedIPs, then all the manual route/rule hack wouldn't be required at all 😄.
Yeah, I have no idea what I'm doing :)
ip r l table 51820 returns nothing.
Indeed my public IP.
Interesting, but ip rule shows the rule ending with lookup 51820? I'm confused 😄. Although it would fit to the case that currently nothing is tunnelled by default, but only when the VPN is actively used as proxy. Actually, in many cases with BitTorrent, this is quite the wanted case: Only the BitTorrent software uses the VPN via SOCKS5 socket, while everything else bypasses it, including requests from/to LAN.
I'm confused as well and I think it's not really working. For now, it appears like the tunnel is not active at all. But, the scenario you speak of, is exactly what I'm looking for.
I guess a duplicate request, similar like https://github.com/MichaIng/DietPi/issues/2758
You are right. Let's focus on WireGuard here and have the other one for DietPi-VPN. While there are overlaps, the implementation differs.