On 09/20/2016 02:26 PM, Michael Rash wrote:
No, please allow or let me correct myself as I've now found the solution
- just for the reference - on my router I have these:
On Mon, Sep 19, 2016 at 6:49 PM, newsboost
<newsbo...@gmail.com <mailto:newsbo...@gmail.com>> wrote:
Without changing these rules in the web-interface, I tried
to login to
the Asus-router and using SSH (from LAN-side) I wanted to
# iptables -N SSHBFP
# iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m
NEW -j SSHBFP
iptables: Protocol wrong type for socket.
# iptables -A SSHBFP -m recent --set --name SSH --rsource
# iptables -A SSHBFP -m recent --update --seconds 60
--hitcount 4 --name
SSH --rsource -j DROP
# iptables -A SSHBFP -j ACCEPT
So, I'm not completely sure what is going on... I don't
"Protocol wrong type for socket". These commands don't
work. If they
did, I think it should be possible to make the
fwknopd-server let me
I think that iptables error is because of a bug in iptables
and/or the kernel on your system based on some searches I did
- those commands should work just fine. Your strategy is a
good one, and let's try simplifying the iptables commands a
bit. Just do the following and see if you can SSH to the WAN side:
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
You're right - must be a bug in the entware version of iptables,
which I'm using... Anyway, you're right:
wrt54g@router:/tmp/home/root# cd /
wrt54g@router:/# find . | grep -i iptabl
(actually /opt = /tmp/mnt/sda/entware, but that's irrelevant here). Also
wrt54g@router:/# which fwknopd
So I have a firmware-version of iptables and I have the entware-version
of iptables. The entware "opkg"-commands gave me (among others) fwknopd.
/usr/sbin/iptables version is v1.4.14. The /opt/sbin/iptables version is
newer: v1.4.21. As I remember, earlier I discovered that I needed to
have the entware-version of iptables running, in order run fwknopd
(avoid error messages). I also have:
so with my configuration, the entware version of iptables is default and
first in path.
The solution is simply now: Just had to type "IPT=/usr/sbin/iptables"
and then everywhere I needed iptables, I used "$IPT ....." followed by
the rest of the commands... Maybe it can help someone else in the
future, so just for the reference... Now also, I have iptables-restore
working (before it came with an error message, but the problem is that I
have two different version of iptables on the same router, at the same
This cuts out the rate limiting stuff and will help to verify
that SSH is available on eth0. The nmap output you sent had
'filtered' instead of 'closed', so that implies a firewall
policy in the way instead of otherwise having TCP stack access
and SSH not listening on eth0.
You're completely right! First I had my connection "filtered" and
when I tried to ssh to the WAN-side of the router (public IP
address) it was just waiting forever and nothing happens... After
running the command above, when I tried to ssh it immediately said
something about "connection closed" (I'm at work at the moment, I
just didn't have time to reply earlier)...
Ok, so does nmap now report that port 22 is "closed" instead of
"filtered"? If so, then you are either hitting the TCP stack itself
and there is nothing bound to port 22 as Jonathan suspected
(definitely important), or iptables is using the REJECT target against
your connection (as you have below), or both. To be really sure
iptables is not in the way, I would temporarily just flush the whole
policy, test SSH, and then rebuild it. So:
# iptables -F
# iptables -X
... test ssh ...
# iptables-restore ....
You need to make sure SSH is available before fwknopd can have a chance...
SSH is available from the LAN - that's what's so strange... But now I
tested this. Still the same result: I get that port 22 is "filtered"
from the WAN-side until "opening" with:
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
And then I get that port 22 is "closed"... I verified using "shields
up". It says the same, as I discovered: First, I get a good
"stealth"-rating on "shields up" which is normally good. After running
$IPT -F,.... $IPT -X .... $IPT -I INPUT 1 -p tcp --dport 22 -j
ACCEPT,..... I immediately get that port 22 is closed. BUT I can connect
to port 22 from the LAN-side (192.168.1.XXX)...
I think it's something Asus has made to their firmware (as sshd is
built-in to the Asus-firmware, I think)... Maybe some weird propriety
Asus-SSHD-stuff is not 100% following the IPTABLES-rules? I have to ask
in the Asus-Merlin firmware group, if anyone knows what is going on, I
think... But I'm almost 100% positive that I have fwknopd working pretty
good now... I'm a little afraid if there is something custom
Asus-router-stuff that really requires the original iptables-firmware,
because this might conflict with the entware fwknopd-server as well as
the entware iptables-stuff... I think I've a good and a bad conclusion:
fwknopd seems to be working - and I cannot ssh into the router, for some
unknown reason, I suspect something Asus-firmware-security stuff...
Later I'll try the NAT-part of fwknopd, this I believe should take care
of this... But normally most of my machines are closed. Then I would
need to maybe setup fwknopd to open for 30 seconds after the first
SPA-packet, so I could pass on a WOL (wake-on-lan) packet. And then wait
maybe 2 minutes or so. And then I need a new SPA-packet to get an
ssh-connection, to a machine inside the LAN...
I believe fwknopd is very well documented - I think I can read a lot and
study a lot by myself now... But I really appreciate the good help I
received in here... If I figure out the solution to my ssh-problem
later, I'll post an update here...
Thanks a lot for your help, so far, I feel I've learned a lot about
Fwknop-discuss mailing list