On 09/20/2016 02:26 PM, Michael Rash wrote:

        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
            type in
            something like:

            # iptables -N SSHBFP
            # iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m
            state --state
            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
            understand the
            "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
            in...


        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:

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:

wrt54g@router:/tmp/home/root# cd /
wrt54g@router:/# find . | grep -i iptabl
./opt/bin/iptables-xml
./opt/lib/opkg/info/iptables.control
./opt/lib/opkg/info/iptables.list
./opt/lib/iptables
./opt/lib/iptables/libxt_NOTRACK.so
./opt/lib/iptables/libxt_state.so
./opt/sbin/iptables
./opt/sbin/iptables-restore
./opt/sbin/iptables-save
./usr/sbin/iptables
./usr/sbin/iptables-restore
./usr/sbin/iptables-save

(actually /opt = /tmp/mnt/sda/entware, but that's irrelevant here). Also remember:

wrt54g@router:/# which fwknopd
/opt/sbin/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: $PATH=/opt/bin:/opt/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/home/wrt54g:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin 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 time)...


        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 fwknopd now!


Br,
Martin

------------------------------------------------------------------------------
_______________________________________________
Fwknop-discuss mailing list
Fwknop-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss

Reply via email to