Hey guys, I posted this over in the SAB forum but they suggested I ask over here instead.
Sabnzbd doesn’t stay locked to Locahost:8080 when using a VPN on my browser. I use Windows 10 and I split tunnel so I can use the VPN to browse the internet, but since SAB’s web interface is accessed through the browser, anytime the VPN is on Sab’s address changes to 10.16.0.* (with the * being variable depending on the VPN server I connect to). My VPN is using a virtual VPN adapter for the split tunneling and routing all traffic through that. It’s unlike Sonarr and Prowlarr which seem to adapt to the localhost address and work the same whether I’m using VPN or not. Additionally, in Sonarr I have to add the address as an IP instead of “localhost:8080” which has caused me some issues.
The workaround seems to be opening a different browser outside of the VPN just for using Sab and making the host address 0.0.0.0 and download client address 127.0.0.1. This works fine but it means I can’t access sab consistently with a favorites link on my main browser or by clicking “show interface” on the taskbar icon.
Does anybody know of a way to get SAB to work more like Sonarr/Prowlarr in regards to localhost?
Just to think of another solution instead of fighting with vpn software and windows networking… do you have the ability to containerize SAB? You could spin up a container that only utilizes VPN traffic, such as a gluetun solution. I’ve played around with it before with Windscribe and it works great - just a bit slower but that’s on Windscribe.
Personally, I’d weigh if a VPN is really needed for your usenet if you’re utilizing SSL.
I tried having SAB bind to 127.0.0.1 and it works until I connect the VPN and then nothing. When the VPN address changes to 10.16.0.*, it doesn’t recognize how to get back to 127.0.0.1, that’s why I set it to 0.0.0.0. I tried the local lan address but it does the same thing.
For further clarification Sonarr, Prowlarr, and SAB all connect on 127.0.0.1 before I connect the VPN. After I connect the VPN, Sonarr, Prowlarr, and SAB all connect on a 10.16.0.* address. The last digit changes whenever I reconnect but all 3 are always on the same local address. But for some reason Sonarr’s favorite link of localhost:8989 (127.0.0.1:8989) and Prowlarr’s favorite link of localhost:9696 (127.0.0.1:9696) both recognize the change in VPN and the localhost address changes to 10.16.0.*:8989 and 10.16.0.*:9696 respectively. It happens automatically and I can access the web interface through my saved links. SAB, on the other hand, fails on Localhost:8080 after I connect the VPN. I can still punch in the 10.16.0.* but I have to look up the address to find out what it is.
From what I read in the SAB wiki is that SAB does know that the 10.16… address ranges are local but then why doesn’t the localhost:8080 through sab automatically update the web interface to be accessed through the new address like Sonarr/Prowlarr? I’m sure there is a setting I’m missing or something.
I’m using a VPN specifically for the web browser traffic but turns out the programs are still able to connect locally, just on the IPv6 address while my split tunneling passes through the IPv4 connection. I was confused with how it was connecting to the web interface but it turns out I could connect either way. But I got it working and it’s clear now. I just overlooked the SAB setting of :: which was exactly what I needed.
It might be worth looking at the routing table after enabling the VPN.
I would use the 127.0.0.1 IP instead of the localhost hostname on the off chance that something is doing something tricky. Based on the behavior you describe it seems like enabling the VPN also causes “localhost” to resolve to the VPN adapter IP. You should be able to verify the name lookup in the Network tab of the Developer Tools though.
If your 127.0.0.1 traffic no longer works after enabling the VPN and there’s still a route in place you can add another route with a lower metric.
You can use Wireshark to make sure the right interface is getting the request from the browser if it’s at all confusing.
“it seems like enabling the VPN also causes “localhost” to resolve to the VPN adapter IP”
Yes
“You should be able to verify the name lookup in the Network tab of the Developer Tools though”
Where is that?
“If your 127.0.0.1 traffic no longer works after enabling the VPN and there’s still a route in place you can add another route with a lower metric.”
I have 127.0.0.1 setup through Sonarr as the address to the download client SAB and it works just fine. I can pull up a secondary browser (not going through VPN) and access 127.0.0.1 just fine. I think while the VPN is turned on, the localhost defaults to the local address of the newly detected IP gateway (VPN adapter) which is 10.16.0.1. Because traffic is being routed to the local address on the VPN, it’s 10.16.0.1 but outside the VPN it’s still 127.0.0.1. Hope that makes sense. Should I be able to access both from within the VPN? And how to I add another route with a lower metric?
I’ll see about trying wireshark, because it seems that SAB is the only interface that doesn’t get redirected automatically when I connect the VPN. Unless it has a setting that automatically blocks that from happening.
F12, should work in Firefox and Chrome (and thus probably Edge, but not sure). Beyond that there are more specific differences but it should be easy enough to find “Network.”
I have 127.0.0.1 setup through Sonarr as the address to the download client SAB and it works just fine.
So Sonarr can talk to SAB via 127.0.0.1. Does that mean the VPN is somehow only set up for the specific browser instance (e.g. you need a proxy setting or plugin in the browser to use the VPN connection)? You mentioned opening a secondary browser outside of the VPN…
I think while the VPN is turned on, the localhost defaults to the local address of the newly detected IP gateway (VPN adapter)
This makes sense if the VPN uses a local nameserver to map “localhost” to 10.0.16.x, which is why I’d want to just use 127.0.0.1 and make sure that request flows through the loopback interface. Which would break your access by name to the 127.0.0.1 bound port.
Should I be able to access both from within the VPN?
If the above nameserver thing is true, no, but it seems like an unreasonable limitation to break access to the loopback interface when the VPN is enabled. So I think you should always be able to access 127.0.0.1:8989, for example, regardless of the VPN enabled state, but if you can’t, you’d want to check the routing table. And if it’s only enabled for one application, maybe ProcessExplorer shows that? I’m not sure.
That’s why it’d be interesting to see what exactly happens during a request to say Sonarr when you use localhost:8989 and comparing that to what happens when you use 127.0.0.1:8989.
And how to I add another route with a lower metric?
Well sure, just lmgtfy…
As far as why SAB’s web UI works differently, it’s easy enough to dig into since you have all of the pages to look at… Harder without.
So Sonarr can talk to SAB via 127.0.0.1. Does that mean the VPN is somehow only set up for the specific browser instance (e.g. you need a proxy setting or plugin in the browser to use the VPN connection)? You mentioned opening a secondary browser outside of the VPN…
So I have a VPN program that allows me to check which programs I want to pass through the VPN. I pass the Brave browser through the VPN so any instances of Brave, even if I open multiple windows or tabs will pass through the VPN. However, if I open Opera or Firefox, I don’t have them set up to use the VPN and just use my normal internet connection.
F12, should work in Firefox and Chrome (and thus probably Edge, but not sure). Beyond that there are more specific differences but it should be easy enough to find “Network.”
Okay so I was able to find this and it looks like Sonarr and Prowlarr show remote address of [::1]:#### (both show different port numbers) but the requested address is http://localhost:#### and that seems to connect on the VPN browser (Brave) and the Browser not using VPN (Opera). From what I understand is that ::1 is IPv6 and my VPN adapter (which Brave is using) is through IPv4 so that seems to make sense. Sonarr and Prowlarr are still able to connect through localhost but its because they are bypassing the VPN and connect on IPv6. I’m pretty sure I don’t have SAB set up to use IPv6 so it doesn’t behave the same way. Instead I have to use the IPv4 address the web interface changes to after my VPN connects.
I was able to change the SAB host address from 0.0.0.0 to :: and it works using localhost now. Geez that was a simple mistake I overlooked on the configuration page but I didn’t know enough about how to diagnose the issue. Thanks for all of your help.
Interesting. So [::1] is the IPv6 loopback address.
I think my wild assumption of a local nameserver hijacking localhost is probably not happening. But I can’t explain why the VPN program breaks access to 127.0.0.1 for Brave once its enabled. Might be to avoid any potential data leaking if you think you’re sending everything down the VPN pipe.
You do you, but I wouldn’t want the local service bound to the VPN adapter’s IP, which seems like what you could get binding to 0.0.0.0 (all adapters).
You’re also then exposing your local services to your LAN which may also be undesirable. Granted the Windows Firewall may save you. But it’s just unsavory to my taste.
Glad you got it working. It seems worthwhile to get a handle on some basic networking to be more intentional about your setup.
But I can’t explain why the VPN program breaks access to 127.0.0.1 for Brave once its enabled. Might be to avoid any potential data leaking if you think you’re sending everything down the VPN pipe.
Many vpn programs do that, it seems one need to setup a port forward associated with 127.0.0.1 & local pvt ip (like 192.168.x.x) to work correctly with vpn.
Hm, interesting. Thanks for the perspective. Is it to avoid accidentally failing to satisfy an “all traffic really went through the VPN” assumption?
But if you can access LAN IPs that still wouldn’t hold…
Anyway, as I commented before, if you’re running something on one computer that should just be used there (i.e. bound to the loopback interface) then this workaround significantly broadens the scope of access for that thing. A concrete example, maybe you run SAB without a password. That seems perfectly reasonable when it’s only used and accessible from that machine. But when you bind to all interfaces suddenly anyone on the LAN segment with you (ignoring firewall details) can also get to it. That seems unsavory at best and something people with less network experience might find surprising.
Is it to avoid accidentally failing to satisfy an “all traffic really went through the VPN” assumption?
Most likely, yes.
But if you can access LAN IPs that still wouldn’t hold…
You typically can’t on a typical vpn configuration.
Anyway, as I commented before, if you’re running something on one computer that should just be used there (i.e. bound to the loopback interface) then this workaround significantly broadens the scope of access for that thing.
Agree. However I think op has mistakenly used the term “split tunneling” here because it usually mean that selected programs traffic go through vpn tunnel while rest remain outside. It is meant to be used like that exactly for reasons like accessing *arrs locally & on local network without going through vpn. You should ideally select your torrent clients & a browser to pass traffic through vpn while rest of the program/pc/windows services traffic use connection as usual without going through vpn. If you need to access local web interface then use a browser which is not selected to pass traffic through vpn.
Agree. However I think op has mistakenly used the term “split tunneling” here because it usually mean that selected programs traffic go through vpn tunnel while rest remain outside.
No that’s what’s happening. My Brave browser is selected to pass through the VPN tunnel.
It is meant to be used like that exactly for reasons like accessing *arrs locally & on local network without going through vpn. You should ideally select your torrent clients & a browser to pass traffic through vpn while rest of the program/pc/windows services traffic use connection as usual without going through vpn.
Yeah, that’s what was happening but also I could access the *arrs web interfaces through the VPN as well with the correct IP address. All programs besides brave browser use my normal connection.
If you need to access local web interface then use a browser which is not selected to pass traffic through vpn.
Yes, I could but that was pretty annoying to be surfing the web with one browser and then switching to another just to use SAB. Luckily, changing to the :: was the fix that allowed me to use the same browser, bypass the split tunneling and still connect through the IPv6 localhost.
