# [Solved] IPTABLES: Server Port 313 an internen Port 22

## Finswimmer

Hi!

Ich möchte von meiner No-Ip Adresse mittels Port 313 auf meinen SSH Port von 192.168.0.3 zugreifen.

Dazu habe ich folgende Chain:

```
Chain FORWARD (policy ACCEPT)

target     prot opt source               destination

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:313
```

Nur geht es damit nicht.

```
tobi@tobi-lap ~ $ ssh xxx.no-ip.com -p 313 -l root

ssh: connect to host xxx.no-ip.com port 313: Connection refused

## Per IP Adresse im LAN:

tobi@tobi-lap ~ $ ssh tobi -p 22 -l root

Password:

Last login: Tue Dec 12 15:40:10 2006 from tobi-lap

```

Laut http://www.gentoo.org/doc/de/home-router-howto.xml#doc_chap6 habe ich es richtig gemacht.

Hier im Forum gabs schonmal so einen Thread, leider hilft mir der nicht weiter, denn derjenige hatte noch einen anderen Fehler.

Hier zur Sicherheit mal meine IPTABLES:

```
server ~ # iptables -L

Chain INPUT (policy DROP)

target     prot opt source               destination

ACCEPT     all  --  anywhere             anywhere

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ftp state NEW

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh state NEW

ACCEPT     icmp --  anywhere             anywhere            icmp echo-request

ACCEPT     icmp --  anywhere             anywhere            icmp echo-reply

ACCEPT     icmp --  anywhere             anywhere            icmp destination-unreachable

ACCEPT     icmp --  anywhere             anywhere            icmp source-quench

ACCEPT     icmp --  anywhere             anywhere            icmp time-exceeded

ACCEPT     icmp --  anywhere             anywhere            icmp parameter-problem

ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:313 state NEW

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:313

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:313

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

```

Hat jemand einen Tipp?

Muss ich eventuell ssh noch irgendwas mitteilen?

Danke

Tobi

----------

## STiGMaTa_ch

Muss das ganze anstatt durch die FORWARD nicht durch die NAT Chain gehen?

Ist nur so ein Schuss ins blaue, bin mir grad überhaupt nicht sicher   :Embarassed: 

Lieber Gruss

STiGMaTa

----------

## Finswimmer

Ich habe es auch in NAT eingetragen:

```
server ~ # iptables -t nat -L

Chain PREROUTING (policy ACCEPT)

target     prot opt source               destination

DNAT       tcp  --  anywhere             anywhere            tcp dpt:313 to:192.168.0.3:22

DNAT       tcp  --  anywhere             anywhere            tcp dpt:313 to:192.168.0.3:22

Chain POSTROUTING (policy ACCEPT)

target     prot opt source               destination

MASQUERADE  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

```

Der Befehl lautete:

iptables -t nat -I PREROUTING -p tcp --dport 313 -i eth1 -j ACCEPT --to 192.168.0.3:22

Ich bin echt aufgeschmissen. Es sieht doch eigentlich gut aus.

Tobi

----------

## Polynomial-C

Hi,

das ist jetzt nur ein Schuß ins Blaue, aber versuche doch mal statt --to die Option --to-destination.

Grüße

Poly-C

----------

## Finswimmer

 *Quote:*   

> Later Kernels (>= 2.6.11-rc1) don't have the ability to NAT to multiple ranges anymore

 

```
 iptables -t nat -I PREROUTING -p tcp --dport 313 -i eth1 --to-destination  192.168.0.3:22

iptables v1.3.5: Unknown arg `--to-destination'

```

Mag er leider nicht...

Tobi

----------

## schmutzfinger

Da fehlt ja auch das -j DNAT.

----------

## Finswimmer

Hmm. Stimmt. Aber auch das hilft leider nichts.

Iptables -L ergibt auch keinen Unterschied und der ssh Versuch ergibt immer noch "Connection refused".

Tobi

----------

## Child_of_Sun_24

Hi,

vielleicht hilft dir ja meine Config weiter:

iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/16 -j MASQUERADE

iptables -A FORWARD -i ppp0 -d 192.168.0.0/24 -j ACCEPT

iptables -A FORWARD -o ppp0 -p TCP --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

iptables -t nat -A PREROUTING -i ppp0 -p TCP --dport 4662 -j DNAT --to-destination 192.168.0.4

iptables -t nat -A PREROUTING -i ppp0 -p UDP --dport 4672 -j DNAT --to-destination 192.168.0.4

iptables -t nat -A PREROUTING -i ppp0 -p TCP --dport 53349 -j DNAT --to-destination 192.168.0.4

iptables -t nat -A PREROUTING -i ppp0 -p UDP --dport 53349 -j DNAT --to-destination 192.168.0.4

weiß allerdings nicht wie man die destination Ports angibt. vlt. mit :

iptables -t nat -A PREROUTING -i ppp0 -p TCP --dport 313 -j DNAT --to-destination 192.168.0.4:22

oder so.

CoS24

----------

## bbgermany

ich würde das so machen:

```

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 313 -j DNAT --to 192.168.0.3:22

iptables -A FORWARD -i eth1 -p tcp --dport 22 -d 192.168.0.3 -j ACCEPT

```

----------

## Finswimmer

Hmm. 

@bbgermany: Nee, das will auch nicht. Habe ich evtl bei den anderen Regeln einen Fehler gemacht?

Wie kann ich überprüfen, ob das Weiterleiten klappt?

Im Moment kommt ja nur "Connection refused", was ich eingestellt, dass es immer kommt, egal ob der Port offen ist, oder geschlossen. (Damit da keiner Rückschlüsse auf offene Ports machen kann)

Ich weiß nämlich grade nicht, ob Iptables oder mein sshd das Problem ist.

Tobi

----------

## bbgermany

Hallo Tobi,

du könntest mal ein telnet auf port 313 machen. 

```

telnet xxx.no-ip.com 313

```

Wenn du da ein "Connection Refused" bekommst oder dein Telnet "steht", dann stimmt etwas nicht mit dem Portforwarding. Auf jeden Fall musst du, wenn der Rechner hinter der Firewall steht, ein DNAT machen via Portforwarding, sowie das Forward erlauben. Also im Endeffekt, so wie ich es geschrieben habe. Nur solltest du darauf achten, dass wenn du keinen Rechner als Router hast, dass ppp0 meistens das eingehende Interface ist und nicht eth0/eth1.

Außerdem ist nmap beim scannen von Ports dein Freund  :Wink: 

----------

## schmutzfinger

Also ich sehe jetzt auch nicht wo das Problem mit den Regeln liegt. Fehlt vielleicht was im Kernel? Ist Forwarding in /proc angeschaltet? Die Regel in der FORWARD Chain kannst du auch weglassen, die ist sicher nicht das Problem. Denn die Chain hat ACCEPT als Policy. Debuggen kann man sowas gut mit tcpdump.

----------

## Finswimmer

```
server ~ # telnet kaminsky.no-ip.com 313

Trying xxx.xxx.xxx.xxx...

telnet: Unable to connect to remote host: Connection refused
```

Versuchte Verbindung mit SSH von Tobi auf no-ip.com 313 mit ETH0 (interne Netzwerkkarte):

```
server ~ # tcpdump -i eth0 port 313

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes

07:25:14.063544 IP tobi.2864 > acor-ip.net.313: S 2500389978:2500389978(0) win 5840 <mss 1460,sackOK,timestamp 880207[|tcp]>

07:25:14.082677 IP arcor-ip.net.313 > tobi.2864: R 0:0(0) ack 2500389979 win 0

2 packets captured

4 packets received by filter

0 packets dropped by kernel

```

Man sieht doch ziemlich gut, dass er es weitleleitet: Allerdings auf: tobi.2864

SSH von Tobi auf no-ip.com Port 313 mit ETH1/PPP0:

```
server ~ # tcpdump -i ppp0 port 313 -vv

tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 68 bytes

0 packets captured

0 packets received by filter

0 packets dropped by kernel

server ~ # tcpdump -i ppp0 port 313 -vv

server ~ # tcpdump -i eth1 port 313 -vv

tcpdump: WARNING: eth1: no IPv4 address assigned

tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
```

Ist es nun ein SSH Problem?

Wo kann ich einstellen, dass er von überall auf SSH lauschen soll?

Auch wenn das eigentlich keine Lösung ist, denn es kann ja nur von 192.168.0.1 (server) und Port 22 kommen, wenn die Regel richtig eingestellt ist.

Wie kann ich überprüfen, ob FORWARD richtig eingestellt ist?

Danke, Gruß Tobi

----------

## bbgermany

Hallo Tobi,

schau mal in /proc/sys/net/ipv4/ip_forward ob dort eine 1 steht. Wenn nicht, einfach via echo rein damit  :Wink:  Dann ist zumindest das IP-Forwarding erschlagen.

Vielleicht ist das ja der "Bringer" im letzten Moment.  :Very Happy: 

EDIT: Nachsehen ob ssh auf allen Schnittstellen läuft kannst du mit netstat, so wie dieses Beipiel:

```

dskpower:~ # netstat -tupan | grep sshd

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      5844/sshd

dskpower:~ #

```

----------

## Finswimmer

Hey!

IP_Forward war aktiviert. Internet über den Server geht ja auch ohne Probleme.

Server:

```
server ~ # netstat -tupan | grep sshd

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      5935/sshd
```

Tobi:

```
[07:50:59]|[root@tobi-rechner]|/tmp$netstat -tupan | grep sshd

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      7842/sshd
```

Ich glaub, ich kill nachher alle Regeln und setz die nach dem Gentoo Handbuch neu auf.

Tobi

----------

## bbgermany

Hallo Tobi,

vielleicht musst du garnicht alle Regeln killen. Kannst du mir mal alle deine Regeln anzeigen (Also filter-chain, nat-chain und mangle-chain)?

Möglicherweise haben wir irgendwas übersehen.

EDIT: Ich weis zwar nicht, was du gemacht hast, aber ich bekomme bei deinem Server sofort ein connect und den Pubkey angeboten, wenn ich via ssh darauf will  :Sad: 

Kann es vielleicht sein, dass du von deiner Lokation, von wo du den ssh Zugriff aus machen möchtest, nicht raus darfst via ssh?

----------

## Finswimmer

@bbgermany:

2 Fragen dazu: 1) Woher kennst du meinen Server? Nicht, dass es schlimm ist, aber ich dachte, ich hätte alle Daten gelöscht.

2) Meinst du wirklich Port 313?

Tobi

----------

## Finswimmer

Nein. *unzählige Flüche*

Wie kann das denn passieren?

Hab mich auf der Uni eingeloggt, dort dann wieder zurück auf 313 und es geht.

Wenn ich von meinem Tobi Rechner mich allerdings auf 313 einlogge, geht es nicht.

Probiere ich aber Port 22, geht es ohne Probleme, mich auf den Server einzuloggen.

Wohl gemerkt, alles über die no-ip.com Adresse.

Auf jedenfall schonmal ein riesen DANKE!

tobi

----------

## think4urs11

 *Finswimmer wrote:*   

> Wenn ich von meinem Tobi Rechner mich allerdings auf 313 einlogge, geht es nicht.
> 
> Probiere ich aber Port 22, geht es ohne Probleme, mich auf den Server einzuloggen.

 Weil Anfragen von tobi an server nicht über eth1 hereinkommen sondern über eth0, richtig?

Von innen kannst du iptablesrules für Zugriffe von extern nur schlecht testen wenn du sozusagen 'von hinten' ankommst.

----------

## bbgermany

 *Finswimmer wrote:*   

> @bbgermany:
> 
> 2 Fragen dazu: 1) Woher kennst du meinen Server? Nicht, dass es schlimm ist, aber ich dachte, ich hätte alle Daten gelöscht.
> 
> 2) Meinst du wirklich Port 313?
> ...

 

Hast du selber oben geschrieben  :Wink:  Schau mal deine Quotes durch  :Very Happy: 

Schön das du es noch hinbekommen hast,

Grüße, Stefan

----------

## Finswimmer

 *Think4UrS11 wrote:*   

>  *Finswimmer wrote:*   Wenn ich von meinem Tobi Rechner mich allerdings auf 313 einlogge, geht es nicht.
> 
> Probiere ich aber Port 22, geht es ohne Probleme, mich auf den Server einzuloggen. Weil Anfragen von tobi an server nicht über eth1 hereinkommen sondern über eth0, richtig?
> 
> Von innen kannst du iptablesrules für Zugriffe von extern nur schlecht testen wenn du sozusagen 'von hinten' ankommst.

 

Du hast den Nachsatz, dass alle dies Versuche über die no-ip.com Adresse gehen, überlesen.

Oder ändert das nichts an der Sache?

Eine Verbindung sieht doch so aus: ssh xxx.no-ip.com -p 313

tobi in Internet (no-ip.com) -> IP Adresse -> zu Port 313 -> geht nicht

tobi in Internet (no-ip.com) -> IP Adresse -> zu Port 22 -> geht

Oder hat sich da ein Denkfehler eingeschlichen?

Tobi

----------

## think4urs11

es ändert dann nichts wenn die Anfragen von tobi an server über eine andere NIC hereinkommen als solche aus dem Internet

----------

## Finswimmer

Na gut.Hauptsache ist, es geht nun alles  :Smile: 

Tobi

----------

## STiGMaTa_ch

 *Think4UrS11 wrote:*   

> es ändert dann nichts wenn die Anfragen von tobi an server über eine andere NIC hereinkommen als solche aus dem Internet

 

Hmm.. Ich merke grad, dass ich zwar wusste dass man "von hinten" nichts testen kann, mir aber ehrlich gesagt nie Gedanken darüber gemacht habe warum das so ist.

Verstehe ich das richtig, dass ich - um das Problem zu umgehen - einen Rechner mit 2 oeffentlichen IP's haben müsste und den ausgehenden Traffic über z.B. eth1 leiten, den eingehenden Traffic aber nur über z.B. eth0 zulassen dürfte?

Lieber Gruss

STiGMaTa

----------

## think4urs11

 *STiGMaTa_ch wrote:*   

> Verstehe ich das richtig, dass ich - um das Problem zu umgehen - einen Rechner mit 2 oeffentlichen IP's haben müsste und den ausgehenden Traffic über z.B. eth1 leiten, den eingehenden Traffic aber nur über z.B. eth0 zulassen dürfte?

 

Um wirklich *alle* Eventualitäten abzudecken mußt du dafür sorgen das deine Tests exakt den gleichen Weg nehmen wie die 'Live-Pakete' auch.

Zwei offizielle IPs bringt dir nur dann etwas wenn 100% gewährleistet ist das die Verbindung IP1->IP2 nur außenherum laufen kann.

Mit zwei PPPoE-Verbindungen über z.B. deinen Homerouter/Linux-FW klappt das nicht weil die dann immer den kürzesten Weg nehmen werden - und der ist innenherum.

Oder anders gesagt die Simpellösung 'secondary IP auf externem Interface' oder 'ppp1 auf das gleiche eth-Interface/die gleiche Maschine hängen wie ppp0' entfällt wegen geht nicht.

Und deine Idee ist auch nicht so einfach - was machst du mit Antwortpaketen die z.B. von einem Client (z.B. http get) über eth1 hinausgingen? Die müssen auch über eth1 wieder rein. Was natürlich geht ist eine IP speziell dafür zu reservieren um einen Service gen Internet anzubieten - ändert aber nichts an der Problematik das dieser von innen nur umständlich bis gar nicht sauber 'live' getestet werden kann.

Ich bin in der glücklichen Lage zwei DSL-Anschlüsse von unterschiedlichen Providern zu haben, u.a. auch aus diesem Grund (außerdem zahlt einen mein AG)  :Wink: 

----------

