iptables: No chain/target/match by that name

[FlexMcMurphy]

Hello Sebastian,

There is a lot of information here but I would be very grateful if you could help me debug !

I am trying to install sshttp on my Raspberry Pi 3 running Raspbian. Kernel information: Linux raspbianpi 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l GNU/Linux

My aim is to deliver https/ssh traffic to my routers external port 443 with sshttp listening on router internal port 444 and then send ssh traffic to port 1022 and https traffic to port 443 in my LAN.

In my nf-setup and nf6-setup scripts I have this line at the top: PORTS="1022 443 7350" Is that correct? Do I need to include the port 7350?

I am following this guide by theYinYeti: http://yalis.fr/cms/index.php/post/2014/02/22/Multiplex-SSH-and-HTTPS-on-a-single-port

I ran into some trouble make'ing the daemon.. libcap wasn't available only libcap2 which I used. I'm not sure if that would be a problem? Also I was unable to load the nf_tproxy_core module and it is not in my distribution apt-get at all. I downloaded the headers and sources from the latest Raspbian Kernel but nf_tproxy_core is not in there at all. Is it deprecated by now maybe?

I did manage to make the daemon but when I run it I get the error:

"iptables: No chain/target/match by that name"

... which happens when the nf-setup script tries to run this command: iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT

Here is the output of the last two times I tried to start the daemon using theYinYeti init script. It is taken from the output of the command: # grep 'sshttp' /var/log/daemon.log

By the way at 23:39:00 there is an unusual error with process sshttpd... sshttpd[1778]: sshttp::loop::NS_Socket::dstaddr::getsockopt:No such file or directory

In my init file I named the daemon sshttp (not sshttpd) and I thought it had already exited with an error at 23:11:16 and this was a few minutes before I tried starting it again at 23:59:28.

And this is the error output from systemctl:

I try to start the daemon as root user (sudo su). Here is the output of running the command: # strace -o /home/pi/strace_op1 /etc/init.d/sshttp start strace_op1.txt

This is the script I run before everytime I try to start sshttp. It clears all rules and chains in iptables: init_fw.sh.txt

Here is the output of the command # iptables-save > /home/pi/iptables_bckp2 This is what iptables looks like after sshttp fails to start: iptables_bckp2.txt

Here are all the modules that are loaded: loadedmodules.txt

I double checked the permissions and ownership of the daemon and init files and they are as per theYinYeti setup advice.

By the way this page https://blog.stalkr.net/2012/02/sshhttps-multiplexing-with-sshttp.html sets up a dedicated user for the daemon... I left it as 'nobody' in my config.

Do you think this because I never loaded the nf_tproxy_core module?

If so, does this mean I won't be able to use sshttp on my Pi or is there some way to compile/make the nf_tproxy_core module for my system?

Thank you,

Flex

[stealth]

Thats a detailed report. I wish everything would be like it.

However; as you describe, you want to run sshttpd on a dedicated node, muxing traffic to your internal LAN. For that to work, you would need TPROXY support.

The common nf-setup configs are for "local" setups, that is sshttpd, httpd and sshd run on the same machine. This wont work with your Pi setup.

You need to config your system via nf-tproxy script, and start sshttpd with -T. For that to work, you also need kernel support, otherwise iptables wont find the TPROXY jump target. How to get nf_tproxy_core support on Pi, is beyond my scope. I bet its easily doable by cross-compiling it. Maybe you should bring this to attention in some Pi forum, since sshttpd on Pi as a muxer sounds like a good project and others may benefit from it, so why not having tproxy support enabled in future Pi image builds...

[FlexMcMurphy]

Hello,

Great to hear back from you!

By the way I'm not running sshttp on a dedicated machine. I'm trying to get it running on the same Pi that has apache and sshd as well. Also I haven't tried to run it with the -T parameter. That's why I was asking if I need tproxy support at all?

Do you think this error: sshttpd[1778]: sshttp::loop::NS_Socket::dstaddr::getsockopt:No such file or directory .. which I get when I try to run sshttp.. with PORTS="1022 443 7350" in my sshttp-nf-setup

..and this error: iptables: No chain/target/match by that name ... which happens when the nf-setup script tries to run this command: iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT

.. is because I don't have the nf_tproxy_core module? If so then it seems like your program requires it anyway even if you don't use -T and you have all the programs on the same machine.

If that's the case then currently no one can use sshttp on a Pi which is a shame because I think more and more people are running personal web servers at home on a Pi that is administered from ssh.

Flex

[stealth]

Ok, then this can be ruled out and using nf-setup is indeed correct. You dont need port 7350.

First, check that your network intf is indeed eth0 on your machine.

Then, since you say you run outside port 443 and inside 444 and 1022, you would have

PORTS="1022 444"

instead of you having "1022 443" in your setup. Please see nf-setup script for exact explanation why.

You would run "sshttpd -S 1022 -H 444 -L 443" then sshttpd will open outside port 443 and mux to 1022 SSH and 444 HTTPS.

I think your kernel is ok, and you even have TPROXY support, but the return -ENOENT; at the end of kernels getorigdst() gives the sshttpd error. This is because it cant find a matching connection, since your PORTS= setup is wrong in the first place.

[FlexMcMurphy]

Hello,

sshttp still won't start for me.

sshttp, apache2 and sshd are running on the same Pi3. Communication arrives to my router on external port 443 and I port forward in the router to internal port 443.

My apache web server is listening on port 444 to all ip addresses... in each of my Virtual hosts I have: <VirtualHost _default_:444>

In ports.conf I have:

Listen 80
<IfModule ssl_module>
        Listen 444
</IfModule>
<IfModule mod_gnutls.c>
        Listen 444
</IfModule>

I also restarted apache2.

In my ipv4 and ipv6 nf-setup I have: PORTS="1022 444"

When I try running it like this: # /etc/init.d/sshttp start

I get.... # systemctl status sshttp.service

# grep 'sshttp' /var/log/daemon.log

Instead when I try running it like this.. # sshttpd -S 1022 -H 444 -L 443

Address already in use?

Here are the various ports that are open and being listened to:

By the way running either of these commands in a terminal window: iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT or ip6tables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT

Gives: ... whereas previously it was giving me: iptables: No chain/target/match by that name

I'm not sure if that is related to sshttp not starting?

Thanks for your help,

Flex

[stealth]

You are doing something weird. netstat shows that sshttpd is running, which doesnt match your error logs from systemd.

Before adding the service to your startup units, you should test everything by hand. So remove the sshttp/fw startup scripts to have a clean default Pi boot, with the apache and sshd on the ports 444 and 1022.

Then, you would run nf-setup by hand and check what it says and whether the rules are in place. I strongly doubt that on a 4.14 kernel your ethernet device is still named "eth0"?? It should rather be some enp45357s0 or similar. Note that nf-setup would probably kill your ssh-session so it should be done on a serial console or a second sshd on a different port. Only when nf-setup runs without error and iptables shows you that all rules are in place, it makes sense to run sshttpd. If the nf-setup doesnt run, you know that its related to the iptables setup and not sshttpd.

Your PORTS=... seems to be correct now. For the DEV=, I am in doubt...

Also, you say that you forward external port 443 to internal 443? The "router" is not the Pi itself, right? Its some cable modem box or so?

Can you attach a

"ip addr" "ip link"

your last error message about DIVERT suggests that it wasnt possible for nf-setup to create that chain in the first place which could well be b/c of wrong device name.