[iptables] port forwarding --> port nicht vom internen lan erreichbar!

[mpuaschitz]

Hello Leute!

Szenario:

Gerät A hat eine öffentliche und die private IP 192.168.2.1 und sellt das Gateway zum Internet dar. Eth0 ist intern, eth1 ist extern.

Nun möchte ich einen Port des Gateway's direkt auf einen Gerät im internen LAN weiterleiten. Das mache ich mit folgender Regel:

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j DNAT --to 192.168.2.100:443

Das funktioniert super, nur leider nicht vom internen LAN heraus. Wenn ich mich auf die Firewall Port 443 connecte erhalte ich den Port 443 der Firewall, nicht dessen Gerät wohin ich eigentlich weiterleiten möchte. Hab versucht das mit folgender Regel zu erreichen, leider erfolglos:

iptables -t nat -A POSTROUTING -o eth1 -d 192.168.2.100 -s 192.168.2.0/24 -p tcp --dport 443 -j SNAT --to 192.168.2.1:443

Dann noch mit folgendem probiert:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 192.168.2.100:443

Ideen?

m.

[TNC.Phil]

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to 192.168.2.100:443

wenns auch von intern gehen soll?

[flinx]

Das funktioniert super, nur leider nicht vom internen LAN heraus. Wenn ich mich auf die Firewall Port 443 connecte erhalte ich den Port 443 der Firewall, nicht dessen Gerät wohin ich eigentlich weiterleiten möchte.

[ot]
Nur interessehalber: Warum sollte man im Lan nicht direkt verbinden, sondern den Umweg über die Firewall nehmen? Welche Szenarien machen dies wünschenswert?
[/ot]
TIA

[mpuaschitz]

Original geschrieben von TNC.Phil
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to 192.168.2.100:443

wenns auch von intern gehen soll?

haut nicht hin, warum ist fraglich.

m.

[mpuaschitz]

Original geschrieben von flinx
[ot]
Nur interessehalber: Warum sollte man im Lan nicht direkt verbinden, sondern den Umweg über die Firewall nehmen? Welche Szenarien machen dies wünschenswert?
[/ot]
TIA

weil die firewall bisher das gemanaged hat, was nun ein anderes gerät machen darf/muss und so keine umstellung der clients notwendig ist, alle einstellungen extern sowie intern ident sein können und es eine eindeutig, klare linie gibt.

m.

[mpuaschitz]

ich habe jetzt folgende regeln aktiv:

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to 192.168.2.100:443

iptables -t nat -A POSTROUTING -j SNAT --to 192.168.2.1

die erste funktioniert tadellos, warum die zweite nicht das tut, was ich will....

m.

[MANX]

Hi!

Nur kurz eine Frage:
Welche IPs haben denn die internen Rechner.
bzw. Ins iptables LOG schauen, tcpdump verwenden.

Grüße

Manx

[mpuaschitz]

Original geschrieben von MANX
Hi!

Nur kurz eine Frage:
Welche IPs haben denn die internen Rechner.
bzw. Ins iptables LOG schauen, tcpdump verwenden.

Grüße

Manx

Die Rechner im Nat haben 192.168.2.x per DHCP ausgenommen jene, die bereits für die Server (.1 / .100 / .101) vergeben worden sind.

iptables-log; hm, du meinst kern.log oder syslog. im syslog erscheint kein eintrag wenn ich z.B. "lynx https://domainname.at" mache der dazu passt....

m.

[MANX]

Hi!

Wie ich vermutet habe, ...
Dann brauchst Du auch in keinen Logfiles schauen, denn IMHO:

Die Clients haben 192.168.2.x, der Linuxgateway hat intern eine IP aus dem 2er Subnet, und das zu erreichende Gerät hat eine IP aus dem 2er. Ergo kommt kein Client auf die Idee über den Gateway zu gehen, sondern wird immer direkt zu 192.168.2.100 verbinden, da sich beide im gleichen Subnet befinden.

Grüße

Manx

[mpuaschitz]

Original geschrieben von MANX
Hi!

Wie ich vermutet habe, ...
Dann brauchst Du auch in keinen Logfiles schauen, denn IMHO:

Die Clients haben 192.168.2.x, der Linuxgateway hat intern eine IP aus dem 2er Subnet, und das zu erreichende Gerät hat eine IP aus dem 2er. Ergo kommt kein Client auf die Idee über den Gateway zu gehen, sondern wird immer direkt zu 192.168.2.100 verbinden, da sich beide im gleichen Subnet befinden.

Grüße

Manx

nein, um das gehts ja gar nicht. das gateway hat eine öffentliche ip und damit eine domain, die clients connecten sich zur domain und werden von der auf .100 weitergeleitet, dann schickt .100 ein reply an den client. der client denk sich quasi "warum redet der mit mir? ich wollte doch das gateway". daher braucht man die postrouting-regel.

habe nun eine variante gefunden

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to 192.168.2.100:443

iptables -t nat -A POSTROUTING -p tcp -j SNAT --to 192.168.2.1

Was mich irgendwie gestört hat war, dass ich mich wenn ich auf dem gateway versuche zu testen ob das port-forwarding geht es nicht funktioniert. aber egal, dass muss es ja eigentlich gar nicht.

m.