> > From: Michael Rash <michael.rash@gm...> - 2016-09-20 03:01:54 >
Hi Michael, sorry if this message is weird, I received messages as "digest" but now changed it and did some copy/paste here as I didn't receive this "digest"-mail yet, but wanted to reply to it anyway... > On Mon, Sep 19, 2016 at 6:49 PM, newsboost <newsbo...@gmail.com> wrote: > >> >> ====================================== >> 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. > Thanks! You're right, I'm sure there is a rule for established connections but that is probably not caught by the diff-tool... > >> 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: > 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)... 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, I begin to understand it and it makes me feel very happy that by using your iptables command I now get connection closed instead of filtered... But why doesn't it yet allow ssh from the outside, just by running: # iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT Am I right, somewhere else in the iptables-rules - something must be REJECTING (isn't that the difference between -j DROP which acts like a "filter" and -j REJECT which just closes the attempt to SSH in) ? Or can it be something in the implementation of sshd, on the router? When I get home from work later today, I'll try to see all the iptables rules and see if I can understand why it rejects ssh-connections... Thanks! Br, Martin
------------------------------------------------------------------------------
_______________________________________________ Fwknop-discuss mailing list Fwknop-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
