Best way to run a VPN router with shadowsocks

hello everyone,

I wondering what's the best and recent tuto for transforming my router to a vpn router, using shadowsocks, I already have a server, so I don't need to set up one. I have a Linksys wrt 1900ac, runnning OpenWrt 18.06.4
I tired to follow this tutoriel, but I wasn't able to see shadowsocks in the webgui, so I made a reset factory, tried to install everything again, and same result, so I guess that the tutoriel is not up to date.

NB: I'm a newbie in this world, this is why I need a step by step tutoriel. thank you guys =)

1 Like

And I wonder is there any package similar vpn-policy-routing for shadowsocks to route not everything but part marked with DSCP tagging?

The tutorial you mentioned is not for shadowsocks-libev build maintained by OpenWrt buildbots.

A recipe for forwarding all traffic through ss-redir is available at https://github.com/openwrt/packages/tree/master/net/shadowsocks-libev#forward-all

The LuCI app is available as luci-app-shadowsocks-libev

2 Likes

ss-rules is made specifically for ss-redir. Currently it supports diverting by src then dst ip addresses. Likely you can make it suit your needs by specifying ipt_args matching dscp labels.

root@OpenWrt:~# opkg install shadowsocks-libev-ss-redir
Unknown package 'shadowsocks-libev-ss-redir'.
Collected errors:
 * opkg_install_cmd: Cannot install package shadowsocks-libev-ss-redir.
root@OpenWrt:~# opkg install shadowsocks-libev-ss-rules
Unknown package 'shadowsocks-libev-ss-rules'.
Collected errors:
 * opkg_install_cmd: Cannot install package shadowsocks-libev-ss-rules.
root@OpenWrt:~# opkg install shadowsocks-libev-ss-tunnel
Unknown package 'shadowsocks-libev-ss-tunnel'.
Collected errors:
 * opkg_install_cmd: Cannot install package shadowsocks-libev-ss-tunnel.

this what I have, so I looked around and I found a good tutorial this one, now I can find "Service = Shadowsocks" I followed all the steps, put my server and everything, but google won't open...

1 Like

Please post intermediate check commands' output as suggested by the recipe. So that we have enough input to actually help.

when I run an nslookup google.com, I have this :

Server:		127.0.0.1
Address:	127.0.0.1#53

*** Can't find google.com: No answer
Name:      google.com
Address 1: 2404:6800:4012::200e

And when I try these three command :

iptables-save | grep ss_rules
netstat -lntp | grep -E '8053|1100'
ps ww | grep ss-
root@OpenWrt:~# iptables-save | grep ss_rules
:ss_rules_dst - [0:0]
:ss_rules_forward - [0:0]
:ss_rules_local_out - [0:0]
:ss_rules_pre_src - [0:0]
:ss_rules_src - [0:0]
-A PREROUTING -p tcp -j ss_rules_pre_src
-A OUTPUT -p tcp -j ss_rules_local_out
-A ss_rules_dst -m set --match-set ss_rules_dst_bypass dst -j RETURN
-A ss_rules_dst -m set --match-set ss_rules_dst_forward dst -j ss_rules_forward
-A ss_rules_dst -m comment --comment "dst_default: forward" -j ss_rules_forward
-A ss_rules_forward -p tcp -j REDIRECT --to-ports 1100
-A ss_rules_local_out -m set --match-set ss_rules_dst_bypass_ dst -j RETURN
-A ss_rules_local_out -p tcp -m comment --comment "local_default: checkdst" -j ss_rules_dst
-A ss_rules_pre_src -m set --match-set ss_rules_dst_bypass_ dst -j RETURN
-A ss_rules_pre_src -p tcp -j ss_rules_src
-A ss_rules_src -m set --match-set ss_rules_src_bypass src -j RETURN
-A ss_rules_src -m set --match-set ss_rules_src_forward src -j ss_rules_forward
-A ss_rules_src -m set --match-set ss_rules_src_checkdst src -j ss_rules_dst
-A ss_rules_src -m comment --comment "src_default: checkdst" -j ss_rules_dst
:ss_rules_dst - [0:0]
:ss_rules_forward - [0:0]
:ss_rules_pre_src - [0:0]
:ss_rules_src - [0:0]
-A PREROUTING -p udp -j ss_rules_pre_src
-A ss_rules_dst -m set --match-set ss_rules_dst_bypass dst -j RETURN
-A ss_rules_dst -m set --match-set ss_rules_dst_forward dst -j ss_rules_forward
-A ss_rules_dst -m comment --comment "dst_default: forward" -j ss_rules_forward
-A ss_rules_forward -p udp -j TPROXY --on-port 1100 --on-ip 0.0.0.0 --tproxy-mark 0x1/0x1
-A ss_rules_pre_src -m set --match-set ss_rules_dst_bypass_ dst -j RETURN
-A ss_rules_pre_src -p udp -j ss_rules_src
-A ss_rules_src -m set --match-set ss_rules_src_bypass src -j RETURN
-A ss_rules_src -m set --match-set ss_rules_src_forward src -j ss_rules_forward
-A ss_rules_src -m set --match-set ss_rules_src_checkdst src -j ss_rules_dst
-A ss_rules_src -m comment --comment "src_default: checkdst" -j ss_rules_dst
root@OpenWrt:~# netstat -lntp | grep -E '8053|1100'
tcp        0      0 0.0.0.0:1100            0.0.0.0:*               LISTEN      25999/ss-redir
root@OpenWrt:~# ps ww | grep ss-
25998 root      1952 S    /usr/bin/ss-local -c /var/etc/shadowsocks-libev/ss_local.cfg013015.json
25999 root      2264 S    /usr/bin/ss-redir -c /var/etc/shadowsocks-libev/ss_redir.hi.json -v
28509 root      1932 S    /usr/bin/ss-tunnel -c /var/etc/shadowsocks-libev/ss_tunnel.cfg0249c0.json
28532 root      1056 R    grep ss-

There are 2 things to check

The first being port 8053 was not in the output of netstat command. Port 8053 in the recipe should be served by ss-tunnel to tunnel dns query to 8.8.8.8. I see there is a ss-tunnel running there, but it looks like it's not working as expected. Please share with us the content of ss_tunnel section and the generated ss-tunnel config file on ps command output /var/etc/shadowsocks-libev/ss_tunnel.cfg0249c0.json.

The other thing is that nslookup google.com only returned ipv6 address record. Not quite sure what happened. I assume you have added the list server ... option to /etc/config/dhcp and issued the nslookup command on the router itself. How about adding another option option localuse 1, restart dnsmasq and try again?

Remember to redact the server address and password, etc.

1 Like

Thank you very much for your time =)

for content os ss_tunnel I have this :

ss_tunnel.cfg0249c0
server: sss0
local_address: 0.0.0.0
local_port: 1090
tunnel_address: 8.8.8.8:53
mode: tcp_and_udp
timeout: 60

and for the /var/etc/shadowsocks-libev/ss_tunnel.cfg0249c0.json .

{
	"use_syslog": true,
	"ipv6_first": false,
	"fast_open": false,
	"reuse_port": false,
	"local_address": "0.0.0.0",
	"local_port": 1090,
	"mode": "tcp_and_udp",
	"timeout": 60,
	"server": "*******",
	"server_port": ******,
	"method": "aes-256-cfb",
	"password": "***********",
	"tunnel_address": "8.8.8.8:53"
}

and now when I added the option localuse '1' when I try to restrast dnsmasq I have this :

root@OpenWrt:~# /etc/init.d/dnsmasq restart
udhcpc: started, v1.28.4
udhcpc: sending discover
udhcpc: no lease, failing

What else can I provide?
Thank you very much =)

So it's 1090, not 8053. Do you also have list server '127.0.0.1#1090' in /etc/config/dhcp?

What's the dns lookup result of www.google.com on your laptop or desktop?

What's the error details when browsing that site, name not resolved, connection timeout, connection reset?

2 Likes

I just inserted this instead of the 127.0.0.1#1090, and it's working as a charm ! you are a genius my friend ! A GENIUS ! thank you very much, thank you

EDIT : it worked for five minutes, then it stopped...

root@OpenWrt:~# nslookup www.google.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:      www.google.com
Address 1: 8.7.198.45
Address 2: 2404:6800:4012:1::2004

now I have this...

It's still name pollution. How about adding option noresolv 1 to /etc/config/dhcp and restart dnsmasq again.

2 Likes

IT'S WORKING !
Give this man a medal ! he just saved my life ! I followed all what you said and it's working, and also, if one day I will have a son, his name will be "yousong" even if I had a daughter!

Thank you for your time, patience and guidance.

1 Like

I tried your version of ss, and it works. But works very slowly, while on mobile client I've got 200 mbps download speed, on windows client - round 300 mbps, on openwrt with your shadowsocks-libev I've got only 50-60 mbps with the same settings and same server. That's not good at all. Why don't you support original shadowsocks-libev implementation?

But they are from different hardware, do they?

I suppose the site is just providing another build of the same source code as does OpenWrt buildbots. For OpenWrt project, builds provided by buildbots are "official", "original". The project is supposed to only provide support for things made by the project itself.

Is it really hardware problem? Or implementation? Must shadowsocks works faster openvpn?

It supports plugins also and goes with 1 packet

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.