edgd1er / nordlynx-proxy

use nordvpn app to open a vpn connection, run a socks proxy
16 stars 8 forks source link

Dante times out, but NordVPN is successfully connected #32

Closed darkson95 closed 10 months ago

darkson95 commented 11 months ago

Unfortunately, I have issues with dante. NordVPN connects without any problem.

nordvpn status

Status: Connected
Hostname: de1117.nordvpn.com
IP: 156.67.85.18
Country: Germany
City: Frankfurt
Current technology: NORDLYNX
Current protocol: UDP
Uptime: 4 minutes 31 seconds

checkip returns private ip address but curl --interface nordlynx ifconfig.co returns nordvpn ip address (156.67.85.18)

So the issue is not the connection with the vpn server, it has to be with dante. I set

DANTE_LOGLEVEL=error
DANTE_ERRORLOG=/dev/stdout
DANTE_DEBUG=1

getdante

internal: eth0 port=1080
internal: 127.0.0.1 port=1080
external: nordlynx
logoutput: stdout
debug: 1
socksmethod: none
clientmethod: none
user.privileged: root
user.notprivileged: nobody
client pass {
        from: 10.0.0.0/8 to: 0.0.0.0/0
  log: error
}
client pass {
        from: 172.16.0.0/12 to: 0.0.0.0/0
        log: error
}
client pass {
        from: 192.168.0.0/16 to: 0.0.0.0/0
        log: error
}
client pass {
        from: 127.0.0.0/8 to: 0.0.0.0/0
        log: error
}
client pass {
        from: 172.18.0.0/16 to: 0.0.0.0/0
        log: error
}
socks pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        protocol: tcp udp
        log: error
}

I attached the logs from dante. Maybe this helps.

edgd1er commented 11 months ago

Could you try to test the container with this script. adapt PROXY_HOST if needed. run: test.sh -t

Could run these command from within the container, the same ip should come up: checksocks checkhttp getcheck checkip

root@2415ad1e7bc2:/app# checksocks 
193.42.96.62
root@2415ad1e7bc2:/app# checkhttp 
193.42.96.62
root@2415ad1e7bc2:/app# getcheck
{
  "ip": "193.42.96.62",
  "isp": "DediPath",
  "status": "Unprotected",
  "country": "United States",
  "code": "US"
}
root@2415ad1e7bc2:/app# checkip
193.42.96.62

curl/7.88.1

here is the timeout occurring: 17 19:13:16 (1689613996.100220) danted[831]: info: pass(2): tcp/accept ]: 0 -> 172.18.0.1.50524 172.18.0.4.1080 -> 0: connect timeout. Session duration: 32s

these lines are odd: Jul 17 19:13:15 (1689613995.354968) danted[801]: debug: getroute(): request: VER: 5 CMD: 1 FLAG: 0 ATYP: 1 address: 34.117.65.55.443, authmethod 0 Jul 17 19:13:15 (1689613995.354973) danted[801]: debug: getroute(): no routes, faking direct route

do you have a dns problem ? a firewall set ? in the container logs, is there a problem with routes ? what is your set up ? could you share your settings ?

darkson95 commented 11 months ago

The test script failed on both tests.

root@SYNOLOGY:/volume1/docker/nordvpn# docker exec -it nordvpn /bin/bash
root@1700d18f5ece:/app# checksocks

root@1700d18f5ece:/app# checkhttp

root@1700d18f5ece:/app# getcheck
{
  "ip": "XXX.XXX.225.107",
  "isp": "Deutsche Telekom AG",
  "status": "Unprotected",
  "country": "Germany",
  "code": "DE"
}
root@1700d18f5ece:/app# checkip
XXX.XXX.225.107
XXXXXXX.dip0.t-ipconnect.de
curl/7.88.1

root@1700d18f5ece:/app# nordvpn status
Status: Connected
Hostname: de827.nordvpn.com
IP: 5.180.62.153
Country: Germany
City: Frankfurt
Current technology: NORDLYNX
Current protocol: UDP
Uptime: 3 days 15 hours 11 minutes 51 seconds

This is my setup on my Synology:

services: 
  proxy:
    image: edgd1er/nordlynx-proxy:latest
    container_name: nordvpn
    restart: unless-stopped
    ports:
      - "1080:1080"
      - "8118:8888" # this is intentional because port 8888 is used by another application
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1 # I tried to remove this, but without success
    cap_add:
      - NET_ADMIN
    volumes:
      - /etc/localtime:/etc/localtime:ro
    environment:
      - ANALYTICS=off
      - TZ=Europe/Berlin
      - COUNTRY=de 
      - GROUP=P2P 
      - NORDVPN_LOGIN=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
      - DANTE_LOGLEVEL=error 
      - DANTE_ERRORLOG=/dev/stdout 
      - DANTE_DEBUG=1 

I don't have a firewall, but I use AdGuard Home as a DNS-Server. The DNS is not a problem because inside the container every domain can be resolved. NordVPN is connected, so it has to be something different I think. I test the whole thing by entering the SOCKS5 proxy in Chrome (and Firefox) and then calling https://ifconfig.co/.

The same configuration on another machine (Raspberry Pi 4) did not work as well.

edgd1er commented 11 months ago

In the docs, I didn't made clear that LOCAL_NETWORK is required. It's used in dante configuration, nordvpn network whitelisting and route adding. Somewhere in the logs, you should have the line"WARNING: OVPN: undefined LOCAL_NETWORK, sockd and http proxies available only through 127.0.0.1 or 0.0.0."

Could you define in the compose file LOCAL_NETWORK ?

darkson95 commented 11 months ago

I had LOCAL_NETWORK first in the configuration, but it did not work either. In the dante_config.sh line 31 script you have a default for the LOCAL_NETWORK.

I added - LOCAL_NETWORK=192.168.0.0/16 again, but without any success :(

Full Log after container start

Jul 23 10:20:48 (1690100448.080785) danted[802]: debug: rulespermit(): 172.18.0.1.35641 -> 172.18.0.4.1080, clientauth N/A, srcauth notset, command accept, fd 8 from 172.18.0.1.35641, accepted on 172.18.0.4.1080
Jul 23 10:20:48 (1690100448.080999) danted[802]: debug: rulespermit(): trying to match against client-rule-rule #1, verdict = pass
Jul 23 10:20:48 (1690100448.081003) danted[797]: debug: addchild(): created new negotiate-child with pid 884, data-pipe 52 and ack-pipe 55.  Minimum rcvbuf: 24536, set: 49072 and 49072.  Minimum sndbuf: 2355456, set: 4710912 and 4710912
Jul 23 10:20:48 (1690100448.081016) danted[797]: debug: childcheck(): added child, pid 884
Jul 23 10:20:48 (1690100448.081032) danted[802]: debug: addrmatch(): matching ruleaddress IPv4 address 192.168.0.0/16 against IPv4 address 172.18.0.1.35641 for protocol tcp, without alias
Jul 23 10:20:48 (1690100448.081039) danted[802]: debug: rulespermit(): trying to match against client-rule-rule #2, verdict = pass
Jul 23 10:20:48 (1690100448.081045) danted[802]: debug: addrmatch(): matching ruleaddress IPv4 address 127.0.0.0/8 against IPv4 address 172.18.0.1.35641 for protocol tcp, without alias
Jul 23 10:20:48 (1690100448.081049) danted[802]: debug: rulespermit(): trying to match against client-rule-rule #3, verdict = pass
Jul 23 10:20:48 (1690100448.081054) danted[802]: debug: addrmatch(): matching ruleaddress IPv4 address 172.18.0.0/16 against IPv4 address 172.18.0.1.35641 for protocol tcp, without alias
Jul 23 10:20:48 (1690100448.081060) danted[802]: debug: addrmatch(): matching ruleaddress IPv4 address 0.0.0.0/0 against IPv4 address 172.18.0.4.1080 for protocol tcp, without alias
Jul 23 10:20:48 (1690100448.081076) danted[802]: debug: methodisset(): checking if method notset is set in the list (1) "none"
Jul 23 10:20:48 (1690100448.081083) danted[802]: debug: rulespermit(): changing authmethod from -1 to 0
Jul 23 10:20:48 (1690100448.081087) danted[802]: debug: methodisset(): checking if method none is set in the list (1) "none"
Jul 23 10:20:48 (1690100448.081096) danted[802]: debug: accesscheck(): method: none, 172.18.0.1.35641 -> 172.18.0.4.1080 
Jul 23 10:20:48 (1690100448.081099) danted[802]: debug: methodisset(): checking if method none is set in the list (0) ""
Jul 23 10:20:48 (1690100448.081101) danted[802]: debug: methodisset(): checking if method none is set in the list (0) ""
Jul 23 10:20:48 (1690100448.081103) danted[802]: debug: accesscheck(): authentication matched
Jul 23 10:20:48 (1690100448.081116) danted[802]: debug: rulespermit(): rule matched: 3 (client-rule), verdict pass

Here we can see, that the request is not blocked.

nordvpn settings

Technology: NORDLYNX
Firewall: enabled
Firewall Mark: 0xe1f1
Routing: enabled
Analytics: disabled
Kill Switch: enabled
Threat Protection Lite: disabled
Notify: disabled
Auto-connect: disabled
IPv6: disabled
Meshnet: disabled
DNS: disabled
Whitelisted ports:
         1080 (UDP|TCP)
         8888 (TCP)
Whitelisted subnets:
        172.16.0.0/12
        172.18.0.0/16
        192.168.0.0/16

Here the local network is listed as well.

I am very confused :(

edgd1er commented 11 months ago

so am i. I've looked through the log and couldn't find the cause. these two lines are likely a clue that may show us the path to the problem.

Jul 23 10:21:08 (1690100468.637090) danted[805]: debug: getroute(): no routes, faking direct route
Jul 23 10:21:08 (1690100468.637098) danted[805]: debug: getoutaddr(): client 172.18.0.1.35793, cmd connect, reqhost 172.64.41.4.443, external.rotation = none

I'm afraid you'll have to run many commands to try to understand what is going on. Could you run the following commands from within the container ? all 3 return should be the same or alike.

curl https://www.google.com
curl -x socks5://127.0.0.1:1080 https://www.google.com
source /app/utils.sh
getEthIp
curl -x socks5://<getIthIp result>1080 https://www.google.com

could you also run route -n you should have something similar to:

root@2415ad1e7bc2:/app# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.18.0.1      0.0.0.0         UG    0      0        0 eth0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
192.168.0.0    172.21.0.1      255.255.255.0   UG    0      0        0 eth0
darkson95 commented 11 months ago

First of all, thank you for your support! This is not a matter of course. ♥️

curl https://www.google.com
    <returns HTML from google.com>
curl -x socks5://127.0.0.1:1080 https://www.google.com
    curl: (97) Can't complete SOCKS5 connection to www.google.com. (6)
source /app/utils.sh
    <nothing>
getEthIp
    172.18.0.4
curl -x socks5://172.18.0.4:1080 https://www.google.com
    curl: (97) Can't complete SOCKS5 connection to www.google.com. (6)

route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         172.18.0.1      0.0.0.0         UG    0      0        0 eth0
    172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
    192.168.0.0     172.18.0.1      255.255.0.0     UG    0      0        0 eth0

When I compare your result with mine from the -n route, I notice that the last line is not the same. Could this be the error?

edgd1er commented 11 months ago

Well, I think we are getting somewhere...

Adding -v to the curl may show more detailed errors .