Hallo Gruppe,
nachdem ich beim Kunden fast in die Tischplatte gebissen habe, stelle ich mein Prob. im Labor nach.
Ziel interne Dienste per Destnat im internen Netzerreichen, z.B. owa oder im Laborfall rdp 3389, Securepoint Dienst ms-rdp
externe LAN 172.16.252.0/24
externes interface 172,16,252.40
Internes Lan 192.168.175.0/24
internes interface 192.168.175.1
zu erreichender Server 192.168.175.2
Internetzugang aus dem internen Lan funtioniert.
Netzwerk Obejekt TSSrv erstellt, Zone intern.
Regel erstellt. Internet - ExternesInterface - Dienst ms-rdp, accept Login ja, Destnat TSSrv Dienst ms-rdp
wen ich jetzt ein rdp auf das externe interface starte, keine Verbindung möglich, timeout
Das Log der Firewall sagt:
kernel ACCEPT: in rule 6 IN=eth0 OUT= MAC=00:0c:29:e8:aa:e1:00:21:cc:5e:d5:ee:08:00 SRC=172.16.252.102 DST=172.16.252.40 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=30824 DF PROTO=TCP SPT=56046 DPT=3389 WINDOW=8192 RES=0x00 SYN URGP=0
Sieht eigentich gut aus,
tcpdum port 3389 gibt ff. Ausgabe:
root@firewall:~# tcpdump port 3389
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:25:43.646680 IP 172.16.252.102.56226 > 172.16.252.40.ms-wbt-server: Flags , seq 1451369517, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
13:25:43.646754 IP 172.16.252.40.ms-wbt-server > 172.16.252.102.56226: Flags [R.], seq 0, ack 1451369518, win 0, length 0
13:25:44.158481 IP 172.16.252.102.56226 > 172.16.252.40.ms-wbt-server: Flags , seq 1451369517, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
13:25:44.158544 IP 172.16.252.40.ms-wbt-server > 172.16.252.102.56226: Flags [R.], seq 0, ack 1, win 0, length 0
13:25:44.668683 IP 172.16.252.102.56226 > 172.16.252.40.ms-wbt-server: Flags , seq 1451369517, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:25:44.668742 IP 172.16.252.40.ms-wbt-server > 172.16.252.102.56226: Flags [R.], seq 0, ack 1, win 0, length 0
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
JA der Server SBS2008, akzeptiert eine RDP Verbindung, zumindest aus dem internen LAN
Was mache ich noch falsch! Ich bin am Tischplatte beissen und über Sophos nachdenkend....
Grüße
Georg
DestNat oder ev. zu Dumm für Vers. 11.4,0
Moderator: Securepoint
Ihre angelegte Regel ist in jedem Fall falsch. In unserem Wiki gibt es einen Artikel zum Thema Portweiterleitung.
Um den RDP-Server aus dem Internet zu erreichen, muss sie lauten:
Internet -> TSSrv -> ms-rdp -> ACCEPT -> DESTNAT, external-interface, ms-rdp
Um den RDP-Server auch aus dem internen Netzwerk über die öffentliche IP zu erreichen, benötigen Sie die Regeln:
internal-network -> TSSrv -> ms-rdp -> ACCEPT -> DESTNAT, external-interface, ms-rdp
internal-network -> TSSrv -> ms-rdp -> ACCEPT -> HIDENAT, internal-interface
Um den RDP-Server aus dem Internet zu erreichen, muss sie lauten:
Internet -> TSSrv -> ms-rdp -> ACCEPT -> DESTNAT, external-interface, ms-rdp
Um den RDP-Server auch aus dem internen Netzwerk über die öffentliche IP zu erreichen, benötigen Sie die Regeln:
internal-network -> TSSrv -> ms-rdp -> ACCEPT -> DESTNAT, external-interface, ms-rdp
internal-network -> TSSrv -> ms-rdp -> ACCEPT -> HIDENAT, internal-interface
Hallo Erik,
das werde ich sofort testen. ich denke zwar ich habe es auch so mal probiert. aber sobald ich wieder ins labor darf, teste ich.
eine frage hinterher. die firewall hat versch. externe ips, kann ich dann pro ip ein externes object, zone firewall-EXTERNAL anlegen und dann bei dest.nat diese onjecte angeben? versch. server solen per z.b. https erreichbarsein?
gruesse
georg
das werde ich sofort testen. ich denke zwar ich habe es auch so mal probiert. aber sobald ich wieder ins labor darf, teste ich.
eine frage hinterher. die firewall hat versch. externe ips, kann ich dann pro ip ein externes object, zone firewall-EXTERNAL anlegen und dann bei dest.nat diese onjecte angeben? versch. server solen per z.b. https erreichbarsein?
gruesse
georg
Hallo Erik,
Danke erstmal für die Tipps im Forum.
Ich hätte da noch ne kleine Anekdote. Als ich die Regel entsprechend Ihres Tipps angelegt hatte,
gings immer noch nicht. Erst nach einem Reboot der FW hat die Regel gegriffen.
Ist das so üblich? Ich mal weiter üben...
Grüße und Danke,
Georg
Danke erstmal für die Tipps im Forum.
Ich hätte da noch ne kleine Anekdote. Als ich die Regel entsprechend Ihres Tipps angelegt hatte,
gings immer noch nicht. Erst nach einem Reboot der FW hat die Regel gegriffen.
Ist das so üblich? Ich mal weiter üben...
Grüße und Danke,
Georg
Das ist weder üblich, noch notwendig. Für TCP-Verbindungen reicht im allgemeinen ein Regelupdate (sofern der Client für jede Verbindung einen neuen Quellport verwendet). Haben Sie einen Dauerping laufen, müssen Sie den nach dem Anlegen der Regeln für mindestens 30 Sekunden stoppen, damit dasCOnnection Tracking die Verbindung verliert.