SSH vanuit WAN (Internet) werkt niet

[zwerfkat]

Ik heb de ssh server (dropbear) uit de oleg firmware (1.9.2.7-9) draaien op mijn wl500g router. Vanaf LAN kan ik zonder problemen met Putty inloggen.

Zodra ik echter vanaf WAN probeer in te loggen met Putty krijg ik geen connectie. Ik heb netjes de stappen gevolgd op de site van Mascat.

Als ik poort 22 test via bijvoorbeeld deze site geeft ie aan dat poort 22 gesloten is en komt er in de log file een DROP te staan met DPT=22:

Oct 28 21:37:38 kernel: DROP IN=eth1 OUT= MAC=00:11:d8:eb:3a:50:00:30:b8:c5:e6:10:08:00 SRC=72.47.224.20 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=26925 DF PROTO=TCP SPT=41949 DPT=22 SEQ=627047993 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT

Met poort 21 (FTP) geeft ie wel aan dat ie open staat, zoals verwacht.

In de router-interface staat bij "Status & Log ==> Port Forwarding" de juiste waarde:

all TCP 22 192.168.1.1 (is IP van mijn router)

Ook heb ik al geprobeerd bij "NAT settings ==> Virtual Server" poort 22 naar ip=192.168.1.1 poort 22 te forwarden, maar ook hiermee geen resultaat.

Het commando "cat /usr/local/sbin/post-firewall" geeft:

#!/bin/sh
iptables -D INPUT -j DROP
iptables -A INPUT -p tcp -m tcp -d 192.168.1.1 --dport 22 -j ACCEPT
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 22 -j DNAT --to-destination 192.168.1.1:22
iptables -A INPUT -j DROP

Ik begrijp er niets van wat er mis gaat. Ook het uitzetten van de firewall op de router maakt geen verschil. Heeft iemand tips?

[DrChair]

Bij de asus zit het WAN op vlan1 ipv ppp0

Je moet in je post-firewall dus ppp0 vervangen door vlan1

[zwerfkat]

Bedankt voor de tip, maar vlan1 en eth1 werkte ook niet. Uiteindelijk heb ik gewoon $1 en $4 gebruikt (zie de uitleg hier bij post-firewall), maar daar moeten backslashes voor (\$1 en \$4) anders worden ze geëxpandeerd door het echo commando wat ik gebruik om naar het bestand te schrijven (ik ben niet zo bekend met vi).

Maar toen werkte het nog niet. Min of meer bij toeval ontdekte ik de iptables optie -L waarmee je kunt kijken hoe de "chains" worden opgebouwd. En toen bleek al snel dat mijn chain INPUT niet eindigt met target DROP maar met "logdrop". (waarschijnlijk omdat ik in de web interface heb aangegeven bij "Logged packets type:" "dropped" maar dat weet ik niet zeker). Met als gevolg dat deze regel met logdrop in de tabel bleef staan en dat de ACCEPT van SSH daar weer achter kwam te staan en dus nooit werd uitgevoerd!

Nadat ik mijn post-firewall script had gewijzigd (DROP in logdrop):

#!/bin/sh
iptables -D INPUT -j logdrop
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t nat -A PREROUTING -i $1 -p tcp --dport 22 -j DNAT --to-destination $4:22
iptables -A INPUT -j logdrop

werkte het meteen! Nou ja meteen, na heel veel uren aanklooien dus. Maar altijd leuk als het dan uiteindelijk toch gaat werken.

Morgen op mijn werk eens kijken of het volgende gaat lukken: Via Wake-on-LAN mijn PC aanzetten (werkt al), vervolgens met Putty een tunnel opzetten naar het lokale IP-adres van mijn PC (poort 5900) en dan VNC viewer draaien. Kan ik eindelijk eens zien wat mijn vrouw allemaal loopt uit te spoken op mijn PC als ik er niet ben