Redsocks proxy not working

Nodens · December 11, 2020, 11:56am

Hello.

Im trying to setup a device behind a sock4 proxy but with no luck.

This is the config in /mnt/boot/system-proxy/redsocks.conf

base {
log_debug = off;
log_info = on;
log = "syslog:local7";
daemon = off;
redirector = iptables;
}

redsocks {
type = socks4;
ip = 192.168.15.30;
port = 1080;
local_ip = 127.0.0.1;
local_port = 12345;
}

Ping to proxy works but not to outside ips.

PING 192.168.15.30 (192.168.15.30): 56 data bytes
64 bytes from 192.168.15.30: seq=0 ttl=64 time=1.436 ms
64 bytes from 192.168.15.30: seq=1 ttl=64 time=0.876 ms

--- 8.8.8.8 ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss

Redsocks check config

1607017648.044236 warning redsocks.c:177 redsocks_onexit(...) Overwriting `redsocks:local_ip` entry: it needs to match OS' iptables configuration.

Journal ctl entries

-- Logs begin at Fri 2013-01-18 09:08:59 UTC, end at Thu 2020-12-03 17:46:57 UTC. --
Dec 03 16:48:25 23d02a5 systemd[1]: Started redsocks transparent proxy redirector.
Dec 03 16:48:25 23d02a5 redsocks[803]: 1607014105.790775 warning redsocks.c:177 redsocks_onexit(...) Overwriting `redsocks:local_ip` entry: it needs to match OS' iptables configuration.

journalctl -u resin-proxy-config

-- Logs begin at Fri 2013-01-18 09:08:59 UTC, end at Thu 2020-12-03 17:48:17 UTC. --
Dec 03 16:48:25 23d02a5 systemd[1]: Starting Resin proxy configuration service...
Dec 03 16:48:25 23d02a5 sh[742]: resin-proxy-config: Found config.json in /mnt/boot/config.json .
Dec 03 16:48:25 23d02a5 sh[742]: iptables: No chain/target/match by that name.
Dec 03 16:48:25 23d02a5 sh[742]: iptables: No chain/target/match by that name.
Dec 03 16:48:25 23d02a5 sh[742]: iptables v1.6.2: Couldn't load target `REDSOCKS':No such file or directory
Dec 03 16:48:25 23d02a5 sh[742]: Try `iptables -h' or 'iptables --help' for more information.
Dec 03 16:48:25 23d02a5 sh[742]: iptables v1.6.2: Couldn't load target `REDSOCKS':No such file or directory
Dec 03 16:48:25 23d02a5 sh[742]: Try `iptables -h' or 'iptables --help' for more information.
Dec 03 16:48:25 23d02a5 sh[742]: iptables v1.6.2: Couldn't load target `REDSOCKS':No such file or directory
Dec 03 16:48:25 23d02a5 sh[742]: Try `iptables -h' or 'iptables --help' for more information.
Dec 03 16:48:25 23d02a5 sh[742]: iptables: No chain/target/match by that name.
Dec 03 16:48:25 23d02a5 sh[742]: iptables: No chain/target/match by that name.
Dec 03 16:48:25 23d02a5 systemd[1]: Started Resin proxy configuration service.

I wasn’t sure if redsocks is really loading the config file, but the systemctl status says it’s ok.

systemctl status redsocks.service

redsocks.service - redsocks transparent proxy redirector
   Loaded: loaded (/lib/systemd/system/redsocks.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-12-03 16:48:25 UTC; 1h 18min ago
 Main PID: 803 (redsocks)
   CGroup: /system.slice/redsocks.service
           └─803 /usr/bin/redsocks -c /mnt/boot/system-proxy/redsocks.conf

Dec 03 16:48:25 23d02a5 systemd[1]: Started redsocks transparent proxy redirector.
Dec 03 16:48:25 23d02a5 redsocks[803]: 1607014105.790775 warning redsocks.c:177 redsocks_onexit(...) Overwriting `redsocks:local_ip` entry: it needs to match OS' iptables configuration.

Anything else I could check?

Thanks in advance.

mpous · December 11, 2020, 12:43pm

Hello, thank you for reporting this problem to the balena forum!

Could you please try to change the local_ip to 0.0.0.0?

Nodens · December 11, 2020, 12:56pm

Hello.
Sadly same result.

Dec 03 16:48:25 23d02a5 systemd[1]: Started redsocks transparent proxy redirector.
Dec 03 16:48:25 23d02a5 redsocks[792]: 1607014105.652835 warning redsocks.c:177 redsocks_onexit(...) Overwriting `redsocks:local_ip` entry: it needs to match OS' iptables configuration.

Just in case
iptables -L

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (3 references)
target     prot opt source               destination

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-ISOLATION-STAGE-2 (3 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

The proxy seems to be working from other machines.

Is there any test i can do from the balena device to check if the proxy is there?

Edit: Yep found a test

curl -sSf -x socks4://192.168.15.30:1080 http://185.99.*.*/

Nice ngnix response

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

alexgg · December 11, 2020, 2:46pm

Hi, could you please let us know what BalenaOS version and device type you are using?

alexgg · December 11, 2020, 3:39pm

#status A user with redsocks problems, have asked for OS version and device type so we can replicated with guarantees. #pendinguserresponse

Nodens · December 11, 2020, 5:57pm

Hi.

Device is an Asus Tinkerer and balena version is balenaOS 2.38.3+rev1

Os version given by uname -a

Linux 23d02a5 4.4.103-yocto-standard #1 SMP Tue Jul 16 15:52:40 UTC 2019 armv7l armv7l armv7l GNU/Linux

Nodens · December 14, 2020, 3:31pm

Update.

The proxy config is clearly doing something but it does not work.

Plugged the device to the net with direct connection but left the proxy config.
Device didn’t come online but ping was working

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=116 time=3.126 ms
64 bytes from 8.8.8.8: seq=1 ttl=116 time=3.029 ms
64 bytes from 8.8.8.8: seq=2 ttl=116 time=3.303 ms
64 bytes from 8.8.8.8: seq=3 ttl=116 time=3.357 ms

Moved the proxy config to a .bk file and rebooted.
Device is now online.

Seems tha the redsocks config is being read and used but it does not work properly.
The proxy is socks4. Please tell me that it works with socks4 and not only socks5.

pipex · December 14, 2020, 9:08pm

Hi, could you also share your device supervisor version and share supervisor logs? redsocks should work with socks4 as far as I know so we are trying to gather information what could be causing the issue. Thank you

Nodens · December 15, 2020, 8:29am

Hello.
Supervisor is 9.15.7

Where do I get the supervisor logs? web terminal?

AlidaOdendaal · December 15, 2020, 9:02am

Hi @Nodens

In the dashboard terminal, you can start a HostOS terminal session, and do
journalctl -u resin-sup* --all

Kind regards
Alida

Nodens · December 15, 2020, 1:52pm

Got it

-- Logs begin at Fri 2013-01-18 09:55:26 UTC, end at Thu 2020-12-03 16:50:35 UTC. --
Dec 03 16:48:49 23d02a5 systemd[1]: Starting Resin supervisor...
Dec 03 16:48:49 23d02a5 resin-supervisor[1217]: resin_supervisor
Dec 03 16:48:49 23d02a5 resin-supervisor[1252]: active
Dec 03 16:48:49 23d02a5 systemd[1]: Started Resin supervisor.
Dec 03 16:48:50 23d02a5 resin-supervisor[1261]: Container config has not changed
Dec 03 16:48:55 23d02a5 resin-supervisor[1261]: Starting system message bus: dbus.
Dec 03 16:48:55 23d02a5 resin-supervisor[1261]:  * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon
Dec 03 16:48:55 23d02a5 resin-supervisor[1261]:    ...done.
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: (node:1) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods >
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Starting event tracker
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Starting up api binder
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Starting logging infrastructure
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Event: Supervisor start {}
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Performing database cleanup for container log timestamps
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Connectivity check enabled: true
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Starting periodic check for IP addresses
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Reporting initial state, supervisor version and API info
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Waiting for connectivity...
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Skipping preloading
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Starting API server
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Applying target state
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Ensuring device is provisioned
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Starting current state report
Dec 03 16:49:03 23d02a5 resin-supervisor[1261]: Starting target state poll
Dec 03 16:49:04 23d02a5 resin-supervisor[1261]: Supervisor API listening on all interfaces
Dec 03 16:49:04 23d02a5 resin-supervisor[1261]: Finished applying target state
Dec 03 16:49:04 23d02a5 resin-supervisor[1261]: Apply success!
Dec 03 16:49:14 23d02a5 resin-supervisor[1261]: Failed to get target state for device: Error: getaddrinfo EAI_AGAIN api.balena-cloud.com api.balena-cloud.com:443
Dec 03 16:49:39 23d02a5 resin-supervisor[1261]: Failed to get target state for device: Error: getaddrinfo EAI_AGAIN api.balena-cloud.com api.balena-cloud.com:443
Dec 03 16:50:19 23d02a5 resin-supervisor[1261]: Failed to get target state for device: Error: getaddrinfo EAI_AGAIN api.balena-cloud.com api.balena-cloud.com:443

For clarification, system still does not connect. Curl test of proxy still works.

Just learned that ping is never going to work with a socks4 proxy since it does not proxy udp.

anujdeshpande · December 16, 2020, 8:57am

Hi

AFAIK getaddrinfo relies on UDP. So if socks4 doesn’t support UDP (which seems to be the case), then getaddrinfo might need some custom flags to force it to use TCP instead. At least that’s what I understood based on some cursory googling.

If that’s indeed the case, it explains why you are getting the EAI_AGAIN i.e. try again errors - in your supervisor logs.

Nodens · December 16, 2020, 9:19am

Hi.

Then it might work if i can set the options use-vc for resolv.conf

I see many files relating to resolv.conf

 resolv-conf.systemd  resolv.conf          resolv.dnsmasq       resolvconf/

Where should I set the option? Also the filesystem of this files is read only mode.

Nodens · December 16, 2020, 11:00am

Hi again.

Okey. Thanks to a last month update of the hardware i’m using got a socks5 proxy working.

root@23d02a5:~# curl -sSf -x socks4://192.168.15.30:1080 http://185.99.****/
curl: (7) Failed to receive SOCKS4 connect request ack.
root@23d02a5:~# curl -sSf -x socks5://192.168.15.30:1080 http://185.99.****/
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Still no connection.

Tried the 0.0.0.0 and 127.0.0.1 local ip in config. No luck.

getaddrinfo errors are still there

root@23d02a5:~# journalctl -u resin-sup* --all
-- Logs begin at Sat 2013-01-19 00:29:24 UTC, end at Thu 2020-12-03 16:53:05 UTC. --
Dec 03 16:48:48 23d02a5 systemd[1]: Starting Resin supervisor...
Dec 03 16:48:49 23d02a5 resin-supervisor[1198]: resin_supervisor
Dec 03 16:48:49 23d02a5 resin-supervisor[1224]: active
Dec 03 16:48:49 23d02a5 systemd[1]: Started Resin supervisor.
Dec 03 16:48:49 23d02a5 resin-supervisor[1227]: Container config has not changed
Dec 03 16:48:55 23d02a5 resin-supervisor[1227]: Starting system message bus: dbus.
Dec 03 16:48:55 23d02a5 resin-supervisor[1227]:  * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon
Dec 03 16:48:56 23d02a5 resin-supervisor[1227]:    ...done.
Dec 03 16:49:02 23d02a5 resin-supervisor[1227]: (node:1) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods >
Dec 03 16:49:02 23d02a5 resin-supervisor[1227]: Starting event tracker
Dec 03 16:49:02 23d02a5 resin-supervisor[1227]: Starting up api binder
Dec 03 16:49:02 23d02a5 resin-supervisor[1227]: Starting logging infrastructure
Dec 03 16:49:02 23d02a5 resin-supervisor[1227]: Event: Supervisor start {}
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Performing database cleanup for container log timestamps
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Connectivity check enabled: true
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Starting periodic check for IP addresses
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Reporting initial state, supervisor version and API info
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Waiting for connectivity...
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Skipping preloading
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Starting API server
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Applying target state
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Ensuring device is provisioned
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Starting current state report
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Starting target state poll
Dec 03 16:49:03 23d02a5 resin-supervisor[1227]: Supervisor API listening on all interfaces
Dec 03 16:49:04 23d02a5 resin-supervisor[1227]: Finished applying target state
Dec 03 16:49:04 23d02a5 resin-supervisor[1227]: Apply success!
Dec 03 16:49:13 23d02a5 resin-supervisor[1227]: Failed to get target state for device: Error: getaddrinfo EAI_AGAIN api.balena-cloud.com api.balena-cloud.com:443
Dec 03 16:49:38 23d02a5 resin-supervisor[1227]: Failed to get target state for device: Error: getaddrinfo EAI_AGAIN api.balena-cloud.com api.balena-cloud.com:443
Dec 03 16:50:18 23d02a5 resin-supervisor[1227]: Failed to get target state for device: Error: getaddrinfo EAI_AGAIN api.balena-cloud.com api.balena-cloud.com:443
Dec 03 16:51:28 23d02a5 resin-supervisor[1227]: Failed to get target state for device: Error: getaddrinfo EAI_AGAIN api.balena-cloud.com api.balena-cloud.com:443

Updating previous info, everything seems the same.

root@23d02a5:~# journalctl -u resin-proxy-config
-- Logs begin at Sat 2013-01-19 00:21:23 UTC, end at Thu 2020-12-03 16:54:00 UTC. --
Dec 03 16:48:25 23d02a5 systemd[1]: Starting Resin proxy configuration service...
Dec 03 16:48:25 23d02a5 sh[740]: resin-proxy-config: Found config.json in /mnt/boot/config.json .
Dec 03 16:48:25 23d02a5 sh[740]: iptables: No chain/target/match by that name.
Dec 03 16:48:25 23d02a5 sh[740]: iptables: No chain/target/match by that name.
Dec 03 16:48:25 23d02a5 sh[740]: iptables v1.6.2: Couldn't load target `REDSOCKS':No such file or directory
Dec 03 16:48:25 23d02a5 sh[740]: Try `iptables -h' or 'iptables --help' for more information.
Dec 03 16:48:25 23d02a5 sh[740]: iptables v1.6.2: Couldn't load target `REDSOCKS':No such file or directory
Dec 03 16:48:25 23d02a5 sh[740]: Try `iptables -h' or 'iptables --help' for more information.
Dec 03 16:48:25 23d02a5 sh[740]: iptables v1.6.2: Couldn't load target `REDSOCKS':No such file or directory
Dec 03 16:48:25 23d02a5 sh[740]: Try `iptables -h' or 'iptables --help' for more information.
Dec 03 16:48:25 23d02a5 sh[740]: iptables: No chain/target/match by that name.
Dec 03 16:48:25 23d02a5 sh[740]: iptables: No chain/target/match by that name.
Dec 03 16:48:25 23d02a5 systemd[1]: Started Resin proxy configuration service.

root@23d02a5:~# systemctl status redsocks.service
● redsocks.service - redsocks transparent proxy redirector
   Loaded: loaded (/lib/systemd/system/redsocks.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-12-03 16:48:25 UTC; 3min 23s ago
 Main PID: 800 (redsocks)
   CGroup: /system.slice/redsocks.service
           └─800 /usr/bin/redsocks -c /mnt/boot/system-proxy/redsocks.conf

Dec 03 16:48:25 23d02a5 systemd[1]: Started redsocks transparent proxy redirector.
Dec 03 16:48:25 23d02a5 redsocks[800]: 1607014105.660122 warning redsocks.c:177 redsocks_onexit(...) Overwriting `redsocks:local_ip` entry: it needs to match OS' iptables configuration.

root@23d02a5:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (3 references)
target     prot opt source               destination

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-ISOLATION-STAGE-2 (3 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Im still suspicios of that message

Overwriting redsocks:local_ip entry: it needs to match OS’ iptables configuration

And the

iptables v1.6.2: Couldn’t load target `REDSOCKS’:No such file or directory

Nodens · December 16, 2020, 11:28am

Okey, good news.
Curl without manually specifiyng proxy works.

root@23d02a5:~# curl  http://185.99.**.**
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Since the same server that has the proxy can act as dns I setted the dns config to the same server and now it’s working.

My guess is that the DNS requests are not getting proxied.

Don’t know if this is intended but if you do not have a working dns server before the proxy the balena supervisor in never going to work behind a proxy.

Edit: As a sidenote, if your are having problem updating your app behind a socks proxy. Change the connection idle timeout. Mine was at 2 minutes and the image download could not finish.

klutchell · December 16, 2020, 3:28pm

Hey @Nodens!

So glad to hear you’ve had some success with socks5! Can you confirm if the device is available in the Dashboard?
Do you see logs on the socks5 server indicating that the proxy is actually being used by this device?

Keep us updated if you are still experiencing issues! Internally we are looking at workarounds for socks4 support in case it is encountered by another user.

Take care,
Kyle

Nodens · December 17, 2020, 9:11am

Hi @klutchell

It’s properly working right now and it’s on the dashboard but I think it needs a bit of clarification.

DNS requests are not being proxied but being served by a DNS server that is in the same network as the device. Works in my case but it’s not a full “proxification” of the device and may not be the solution for everyone.
I tested this setting the dns 8.8.8.8 directly in config and didn’t work, changed to local DNS server before proxy and no problem.

Same solution could have worked with socks4 but I do not have time to test that.

I can see the connections in the socks5 server so I’m sure it’s working through it.
Just had a problem with app updates. Download connection was being idle for too much time (2 minutes) at some points and the proxy was closing it. Just had to change the timeout to a higher limit in the proxy and everything worked.

I would look to 2 things for a “real” fix.

First. Let the user set up the options use-vc in resolv.conf so dns requests use TCP.

Second. Make sure to proxy the DNS requests. This is probably related to previous point.

Thanks all for the help.

klutchell · December 17, 2020, 8:45pm

Hey @Nodens, is your firewall blocking outbound DNS traffic and that’s why 8.8.8.8 wasn’t working (since it was not proxied)?

My understanding is we intentionally do not proxy DNS traffic today as it’s almost always slower. Can you outline your use case for proxied DNS traffic and we can look at opening a request with the OS team?

Thanks!
Kyle

chriswiggins · December 18, 2020, 1:10am

One thing to check, we use redsocks too and have issues if there isn’t a newline at the end of the redsocks.conf file. Does doing this help?

Nodens · December 18, 2020, 9:54am

Hi @klutchell As far as I know there is no firewall. Not super confident with the setup since it’s new grounds for me but I do not think it is blocking anything. In fact, testing with firefox and proxy addon worked fine.

I’ll explain my use case.

2 nets, one with access to the internet (A) and one totally air-gapped from the internet because of critical stuff (B).

Balena device is in net B.

Setted up a device between the 2 nets. It’s a mikrotik router but configured to act as a client for both nets, no DHCP, no routing, just acting as client for both nets at the same time. This “router” transfers what that comes from B to A gateway through the socks proxy. It behaves as a computer with 2 net cards one for each net.

So the balena device uses the mikrotik proxy to access the internet. Only the connections going through proxy go out and get to the internet. Thats why DNS needed to be proxied too.

Since DNS petitions are not being proxied I setted up a DNS server in the mikrotik that just relays the petitions (and caches) to 8.8.8.8. This DNS server can be seen from net B so no need to proxy DNS petitions anymore. This workaround works for me but may not suit for everyones situation.

Hope this helps.

@chriswiggins Yeah, saw it somewere, but I wasn’t the issue, config was being loaded correctly.