You are not logged in.

#1 2020-04-01 08:43:57

1ndeed
Member
Registered: 2018-09-28
Posts: 41

[SOLVED] network sharing doesn't work after iptables REDIRECT

I set up the network sharing by following https://wiki.archlinux.org/index.php/Internet_sharing

[i@one ~]$ ifconfig 
enp3s10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::e2ab:3c37:20bf:691e  prefixlen 64  scopeid 0x20<link>
        ether 00:19:e0:0a:eb:d8  txqueuelen 1000  (Ethernet)
        RX packets 474  bytes 28440 (27.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 119  bytes 19093 (18.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.31.131  netmask 255.255.255.0  broadcast 192.168.31.255
        inet6 fe80::1c25:ce9d:2894:5789  prefixlen 64  scopeid 0x20<link>
        ether 00:01:6c:50:84:39  txqueuelen 1000  (Ethernet)
        RX packets 3897  bytes 463718 (452.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 839  bytes 115313 (112.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 50  bytes 4675 (4.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 50  bytes 4675 (4.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[i@one ~]$ sudo ifconfig enp3s10 169.254.31.131 netmask 255.255.255.0 up
[i@one ~]$ ifconfig 
enp3s10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.31.131  netmask 255.255.255.0  broadcast 169.254.31.255
        ether 00:19:e0:0a:eb:d8  txqueuelen 1000  (Ethernet)
        RX packets 497  bytes 29886 (29.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 123  bytes 19596 (19.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.31.131  netmask 255.255.255.0  broadcast 192.168.31.255
        inet6 fe80::1c25:ce9d:2894:5789  prefixlen 64  scopeid 0x20<link>
        ether 00:01:6c:50:84:39  txqueuelen 1000  (Ethernet)
        RX packets 4110  bytes 484958 (473.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 888  bytes 120916 (118.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 52  bytes 4850 (4.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 52  bytes 4850 (4.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[i@one ~]$ iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE
[i@one ~]$ iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[i@one ~]$ iptables -A FORWARD -i enp3s10 -o ens33 -j ACCEPT

Then the client successfully opened the websites, being able to access the internet of the server.
Then I tried to use a proxy called sshuttle:

[i@one ~]$ iptables -t nat -vL
Chain PREROUTING (policy ACCEPT 96 packets, 5667 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 26 packets, 1481 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  161  9800 MASQUERADE  all  --  any    ens33   anywhere             anywhere  
[i@one ~]$ sshuttle -r i@$server_ip --dns 0/0 -D
[i@one ~]$ iptables -t nat -vL
Chain PREROUTING (policy ACCEPT 300 packets, 17989 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  487 30642 sshuttle-12300  all  --  any    any     anywhere             anywhere            

Chain INPUT (policy ACCEPT 241 packets, 14387 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 2 packets, 172 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   33  2296 sshuttle-12300  all  --  any    any     anywhere             anywhere            

Chain POSTROUTING (policy ACCEPT 2 packets, 126 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   61  3774 MASQUERADE  all  --  any    ens33   anywhere             anywhere            

Chain sshuttle-12300 (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     tcp  --  any    any     anywhere             localhost           
    0     0 REDIRECT   tcp  --  any    any     anywhere             anywhere             TTL match TTL != 42 redir ports 12300
   28  1884 REDIRECT   udp  --  any    any     anywhere             _gateway             udp dpt:domain TTL match TTL != 42 redir ports 12299
[i@one ~]$ curl icanhazip.com
IP_CHANGED

As you can see, what is does it to add chains in OUTPUT and PREROUTING. Then REDIRECT them to its own port.
And all my data from enp3s10 has been FORWARDed to ens33. So now the client should be able to access the network of the sshuttle.
But it didn't. When the client trys to access a website, It shows

Can not Access This Website
www.website.com Declined Our Request
...
ERR_CONNECTION_REFUSED

Why did the happen? How can I fix it?

Last edited by 1ndeed (2020-04-04 05:05:49)

Offline

#2 2020-04-01 12:01:58

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,911

Re: [SOLVED] network sharing doesn't work after iptables REDIRECT

=https://github.com/sshuttle/sshuttle]
Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling.

The readme file also indicates this  as meant to connect to a vpn network.
Maybe what you get is how sshuttle intends to work.
Are you sure sshuttle is what you need ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#3 2020-04-01 13:04:52

1ndeed
Member
Registered: 2018-09-28
Posts: 41

Re: [SOLVED] network sharing doesn't work after iptables REDIRECT

Lone_Wolf wrote:

=https://github.com/sshuttle/sshuttle]
Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling.

The readme file also indicates this  as meant to connect to a vpn network.
Maybe what you get is how sshuttle intends to work.
Are you sure sshuttle is what you need ?

It is. Except that I want the client of the network sharing to have the VPN connection, not the server itself.
Now I know that as long as the network data is redirected to port 12300, the client is under VPN. I just need to know how to redirect the network connection of the client of the network sharing to that port.

Offline

#4 2020-04-02 14:11:09

Koatao
Member
Registered: 2018-08-30
Posts: 92

Re: [SOLVED] network sharing doesn't work after iptables REDIRECT

Hello,

1ndeed wrote:

It is. Except that I want the client of the network sharing to have the VPN connection, not the server itself.
Now I know that as long as the network data is redirected to port 12300, the client is under VPN. I just need to know how to redirect the network connection of the client of the network sharing to that port.

TCP and DNS over UDP traffic (except the one really at destination to localhost) is redirected to sshuttle listening on 127.0.0.1:port in the PREROUTING chain. I'm not sure it is designed to route all traffic that doesn't come from the local machine in the default config.

Did you try using the --listen parameter and select you 192.168.31.xxx address as the listening interface?

Cuz it seems to me it is what you are looking for. It would be only listening for your client (if it is the only one connected to this interface) and it would redirect only your client traffic then.

EDIT: If it does'nt solve your issue, there is also a parameter to have more verbose outputs from sshuttle:

-v, --verbose
              Print more information about the session.  This option can be used more than once for increased verbosity.  By default, sshuttle prints only error messages.

It could be useful to understand what sshuttle is doing. You could capture traffic too.

Last edited by Koatao (2020-04-02 14:20:23)

Offline

#5 2020-04-02 14:40:30

1ndeed
Member
Registered: 2018-09-28
Posts: 41

Re: [SOLVED] network sharing doesn't work after iptables REDIRECT

Koatao wrote:

Hello,

1ndeed wrote:

It is. Except that I want the client of the network sharing to have the VPN connection, not the server itself.
Now I know that as long as the network data is redirected to port 12300, the client is under VPN. I just need to know how to redirect the network connection of the client of the network sharing to that port.

TCP and DNS over UDP traffic (except the one really at destination to localhost) is redirected to sshuttle listening on 127.0.0.1:port in the PREROUTING chain. I'm not sure it is designed to route all traffic that doesn't come from the local machine in the default config.

Did you try using the --listen parameter and select you 192.168.31.xxx address as the listening interface?

Cuz it seems to me it is what you are looking for. It would be only listening for your client (if it is the only one connected to this interface) and it would redirect only your client traffic then.

EDIT: If it does'nt solve your issue, there is also a parameter to have more verbose outputs from sshuttle:

-v, --verbose
              Print more information about the session.  This option can be used more than once for increased verbosity.  By default, sshuttle prints only error messages.

It could be useful to understand what sshuttle is doing. You could capture traffic too.

Thank you very very much!!! It worked!!!
By checking netstat, I found the sshuttle listens to 127.0.0.1 by default.
I did try the --listen parameter, but I only assigned it to 192.168.*.*, not 169.254.*.*
It took me weeks on this problem... Thank you!!

Last edited by 1ndeed (2020-04-03 06:58:03)

Offline

Board footer

Powered by FluxBB