On Mon, Sep 19, 2016 at 6:49 PM, newsboost <newsbo...@gmail.com> wrote:

> On 09/19/2016 08:55 PM, Jonathan Bennett wrote:
> > It may be that the ssh daemon is bound to the internal ip
> > address/device.  This would cause the ssh connections to be rejected
> > even though the firewall is not blocking them.
>
> Yes, maybe you're right... I'm not sure, what is going on... But to
> begin with, I thought the only way, in which SSH did not work - was due
> to iptables disallowing SSH from the WAN-side. But to see if I could/can
> understand what goes on, I made "iptables-save > LAN_only.txt" followed
> by going into the web-interface of the router. In here ("Administration"
>  > "System" > "Enable SSH: Lan only", I changed this setting to "Enable
> SSH: LAN+WAN", followed by "apply" and "iptables-save > LAN+WAN.txt".
> Then I made a "diff"-comparison and below I've tried to manually "clean
> up" the not so interesting entries (where there is no difference):
>
> ======================================
> rt54g@router:/tmp# diff LAN_only.txt LAN+WAN.txt
> --- LAN_only.txt
> +++ LAN+WAN.txt
>
>   *filter
> +:SSHBFP - [0:0]
> +-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j SSHBFP
> +-A SSHBFP -m recent --set --name SSH --rsource
> +-A SSHBFP -m recent --update --seconds 60 --hitcount 4 --name SSH
> --rsource -j DROP
> +-A SSHBFP -j ACCEPT
> ======================================
>
> I'm definately not an iptables-expert. But what I think I see here, is
> that when I go from SSH-access, from only LAN to LAN+WAN, then the
> "only" difference is that the router adds something extra to the
> IPTABLES-rules. In this case, something extra is added to the
> "filter"-table, more specifically, the INPUT-chain. My understanding is
> that "SSHBFP" is a new "target", so when something (a tcp-packet) tries
> to connect to port 22 from eth0 (the WAN-side of the router = the
> internet-side) and it is new, the first rule says: Jump to target
> "SSHBFP". Then there are 3 new commands - I don't know what they do. And
> finally that packet is ACCEPTED.
>

That is correct - the additional commands apply the iptables 'recent'
extension to effectively do rate limiting on incoming SSH connection
requests. Somewhere else in your INPUT chain there should be a rule to
accept packets that are part of established connections as well.


>
> 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

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.



> Anyway, if it isn't possible for me to login directly to the
> router using fwknopd, would it be possible for me to maybe first send
> the SPA-packet and then SSH into one of the machines on the LAN (from
> the internet/WAN-side), e.g. 192.168.1.150 ? How would I setup this ?
>

You could use the NAT capabilities in fwknopd to NAT an incoming SSH
connection from the WAN side straight through to an internal system if you
prefer that (but it shouldn't be necessary - access to SSH on eth0 should
be possible directly from the WAN side). There are some details on this
here:

http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#nat

Thanks,

--Mike


>
> Thanks for any ideas/help!
>
>
> Br,
> Martin
>
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Fwknop-discuss mailing list
> Fwknop-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
>



-- 
Michael Rash | Founder
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F
------------------------------------------------------------------------------
_______________________________________________
Fwknop-discuss mailing list
Fwknop-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss

Reply via email to