Join Log in
Score:0
t-r0d avatar Server

Why do netcat packets get re-routed by iptables rules, but not a curl request?

in flag
t-r0d

I am trying to route all of my traffic through an SSH tunnel/SOCKS5 proxy. I have some IP tables rules configured to redirect (almost) all traffic to a socket-based program that then negotiates and redirects the traffic to the SOCKS5 proxy. What I am finding is that not all of my traffic is getting re-routed properly, and I suspect it is my iptables rules that aren't working. Would anyone be willing to lend me a second pair of eyes?

For example, I can run nc 8.8.8.8 80 2>&1 and I see in my socket-based program that the redirection is happening. But when I curl google.com, I get a resolution error: curl: (6) Could not resolve host: google.com. There are no logs in my socket-based program that show that any redirection was attempted.

I have the socket based program listening at 0.0.0.0:9900 and the SOCKS5 proxy is initiated on port 9901, for example. I am running all of this in a Docker container, in case that matters (but I don't think it should matter much...).

I initiate the SOCKS5 proxy like:

#!/usr/bin/env bash

ssh -D 127.0.0.1:9901 -N  [email protected]

Here are the iptables rules I am using:

#!/usr/bin/env bash

# Create a new chain in the NAT table.
iptables -t nat --new-chain CUSTOM

# Create a rule for leaving localhost destined packets alone.
iptables -t nat --append CUSTOM --destination 127.0.0.0/8 --jump RETURN

# Create a rule for leaving the tunnel we will create alone.
# 192.168.0.25 is the static IP of the machine running the SOCKS5 server.
iptables -t nat --append CUSTOM --destination 192.168.0.25 --protocol tcp --destination-port 22 --jump RETURN

# Create a rule for redirecting all other TCP traffic through the SSH tunnel.
iptables -t nat --append CUSTOM --protocol tcp --jump LOG --log-level info --log-prefix='[iptables] '
iptables -t nat --append CUSTOM --protocol tcp --jump REDIRECT --to-ports 9900

# Link the OUTPUT and PREROUTING chains of the NAT table to our custom user-defined chain.
iptables -t nat -I OUTPUT 1 --jump CUSTOM
iptables -t nat -I PREROUTING 1 --jump CUSTOM

And here is the full output of iptables -t nat -L -v:

Chain PREROUTING (policy ACCEPT 165 packets, 21537 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  165 21537 CUSTOM     all  --  any    any     anywhere             anywhere            
 5129  389K DOCKER     all  --  any    any     anywhere             anywhere             ADDRTYPE match dst-type LOCAL
 6987 1026K delegate_prerouting  all  --  any    any     anywhere             anywhere            

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

Chain OUTPUT (policy ACCEPT 40 packets, 2369 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   40  2369 CUSTOM     all  --  any    any     anywhere             anywhere            
    0     0 DOCKER     all  --  any    any     anywhere            !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 39 packets, 2301 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   72  9027 MASQUERADE  all  --  any    !docker0  172.17.0.0/16        anywhere            
 1614 99565 delegate_postrouting  all  --  any    any     anywhere             anywhere            

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  docker0 any     anywhere             anywhere            

Chain CUSTOM (2 references)
 pkts bytes target     prot opt in     out     source               destination         
   39  2301 RETURN     all  --  any    any     anywhere             127.0.0.0/8         
    0     0 RETURN     tcp  --  any    any     anywhere             192.168.0.25         tcp dpt:ssh
    0     0 LOG        tcp  --  any    any     anywhere             anywhere             LOG level info prefix "[iptables] "
    0     0 REDIRECT   tcp  --  any    any     anywhere             anywhere             redir ports 9900

Chain MINIUPNPD (2 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain delegate_postrouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 1614 99565 postrouting_rule  all  --  any    any     anywhere             anywhere             /* user chain for postrouting */
    0     0 zone_lan_postrouting  all  --  any    br-lan  anywhere             anywhere            
    0     0 zone_wifi_postrouting  all  --  any    br-wifi  anywhere             anywhere            
   55  5757 zone_wan_postrouting  all  --  any    eth0    anywhere             anywhere            

Chain delegate_prerouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 6987 1026K prerouting_rule  all  --  any    any     anywhere             anywhere             /* user chain for prerouting */
 4545  342K zone_lan_prerouting  all  --  br-lan any     anywhere             anywhere            
    1    32 zone_wifi_prerouting  all  --  br-wifi any     anywhere             anywhere            
 2441  684K zone_wan_prerouting  all  --  eth0   any     anywhere             anywhere            

Chain postrouting_lan_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain postrouting_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain postrouting_wan_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain postrouting_wifi_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain prerouting_lan_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain prerouting_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain prerouting_wan_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain prerouting_wifi_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain zone_lan_postrouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 postrouting_lan_rule  all  --  any    any     anywhere             anywhere             /* user chain for postrouting */

Chain zone_lan_prerouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 4545  342K prerouting_lan_rule  all  --  any    any     anywhere             anywhere             /* user chain for prerouting */

Chain zone_wan_postrouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   55  5757 postrouting_wan_rule  all  --  any    any     anywhere             anywhere             /* user chain for postrouting */
   55  5757 MASQUERADE  all  --  any    any     anywhere             anywhere            

Chain zone_wan_prerouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 2441  684K MINIUPNPD  all  --  any    any     anywhere             anywhere            
 2441  684K MINIUPNPD  all  --  any    any     anywhere             anywhere            
 2441  684K prerouting_wan_rule  all  --  any    any     anywhere             anywhere             /* user chain for prerouting */

Chain zone_wifi_postrouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 postrouting_wifi_rule  all  --  any    any     anywhere             anywhere             /* user chain for postrouting */

Chain zone_wifi_prerouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    1    32 prerouting_wifi_rule  all  --  any    any     anywhere             anywhere             /* user chain for prerouting */

Let me know if there is any other info I should include, and thanks in advance!

46
0 + 0
dave_thompson_085 avatar
jp flag
dave_thompson_085
The problem is not curl, but DNS, which uses UDP not TCP (except in some special cases not relevant here), and while iptables can redirect UDP (with appropriate changes) you can't send it over an OpenSSH tunnel. `curl http://142.250.65.206` will get forwarded to one of google's (many) systems, although it will just give you a 301 to www.google.com which is at _different_ addresses including 142.250.251.32 -- which will give another 301 for a request using IPaddress. Most of the Internet depends on DNS and trying to use addresses 'by hand' mostly causes trouble. Maybe you want a VPN.
0
Reply
Score:0
avatar Server
cn flag
Joshua Jacobson

Welcome to StackOverflow!

Based on the error from your curl request, it seems like the DNS request is failing before the connection is even attempted to google.com.

In POSIX systems, the DNS resolution is controlled by the /etc/resolv.conf file. If that file doesn't contain any nameserver lines, your system will not be able to resolve the host. Adding one can be as simple as adding this line:

nameserver 8.8.8.8

On newer Linux systems, the resolution may be controlled by systemd-resolved, and you will see a line like this:

nameserver 127.0.0.53

In this case, editing the /etc/resolv.conf file will only be a temporary solution, as systemd will periodically overwrite the file. In that case, you'll need to edit the netplan configuration in /etc/netplan/ or disable systemd-resolved.

References:

0 + 0
t-r0d avatar
in flag
t-r0d
Thanks for the input! I agree that DNS is failing, but wouldn't your suggestion result in DNS happening client side? I would like for the DNS resolution to happen on the remote machine (the SSH server).
0
Reply
dave_thompson_085 avatar
jp flag
dave_thompson_085
No; DNS uses UDP, which you can't forward over SSH.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.