Unitymedia Firewall hinter FB 6490 und die richtigen IP Settings / Umstellung auf RIP FW 6.75

[un1que]

Ok, dann hat sich das erledigt. Ich habe mich nicht in das Thema reingelesen, hab's nur wegen dem Begriff gepostet, lag aber wohl daneben.

 

[tomcatcw]

Ok, dann hat sich das erledigt. Ich habe mich nicht in das Thema reingelesen, hab's nur wegen dem Begriff gepostet, lag aber wohl daneben.

Danke trotzdem. Es funktioniert jetzt alles.


Gesendet von iPhone mit Tapatalk Pro

 

[premiumpixel]

Hallo,

ich habe ein ähnliches Problem und deine Lösung ist wahrscheinlich auch die richtige in meinem Fall.

Konntest du deine anderen Adressen .43-46 aus der Geräte-Dropdown auswählen oder musstest du diese manuell eintragen?

Vielen Dank für eine kurze Info!

 

[tomcatcw]

Hallo,

ich habe ein ähnliches Problem und deine Lösung ist wahrscheinlich auch die richtige in meinem Fall.

Konntest du deine anderen Adressen .43-46 aus der Geräte-Dropdown auswählen oder musstest du diese manuell eintragen?

Vielen Dank für eine kurze Info!

Hallo Premiumpixel,

Ganz genau. In der Fritte habe ich alle öffentlichen statischen IPs eingetragen und als exposed host freigegeben. Die Fritte hängt über den LAN Port 4 am WAN der pfsense. In der pfsense ist die erste verfügbare IP als statische am WAN eingetragen. Die anderen verbleibenden 4 IP als virtual IP eingetragen und können dann individuell zugeordnet werden. Vergiss nicht die einzelnen IP im Outbound NAT im Manual Mode einzutragen.

Viel Erfolg, meld du noch Fragen hast.

Gruß.


Gesendet von iPhone mit Tapatalk Pro

 

[tq1199]

... am WAN der pfsense. In der pfsense ...

BTW: Wenn Du mal Zeit und Lust hast, könntest Du bitte testen ob aus dem "lokalen" Subnetz der PFsense und bei deaktiviertem Gast-LAN, die IP-Adresse 192.168.179.1 (oder gleichwertig) bzw. die Ports 80 und 443 über diese IP-Adresse erreicht werden können? Z. B.:

<i>
</i>ping -c 3 -W 2 192.168.179.1
nc -zv 192.168.179.1 80
nc -zv 192.168.179.1 443
mtr -4nr -c 2 -i 2 192.168.179.1

(oder gleichwertig). Danke.

 

[tomcatcw]

... am WAN der pfsense. In der pfsense ...

BTW: Wenn Du mal Zeit und Lust hast, könntest Du bitte testen ob aus dem "lokalen" Subnetz der PFsense und bei deaktiviertem Gast-LAN, die IP-Adresse 192.168.179.1 (oder gleichwertig) bzw. die Ports 80 und 443 über diese IP-Adresse erreicht werden können? Z. B.:

<i>
</i>ping -c 3 -W 2 192.168.179.1
nc -zv 192.168.179.1 80
nc -zv 192.168.179.1 443
mtr -4nr -c 2 -i 2 192.168.179.1

(oder gleichwertig). Danke.

Hmm, also anpingen per

<i>
</i>ping -c 3 -W 2 192.168.178.1

geht. Die anderen Befehle kennt pfsense nicht. Aber ich kann von einem Rechner aus nicht auf die WebGUI der Fritte zugreifen.

 

[Andreas1969]

Aber ich kann von einem Rechner aus nicht auf die WebGUI der Fritte zugreifen.

Auch nicht, wenn Du im Browser die "192.168.179.1" eingibst :kratz:

 

[tomcatcw]

Aber ich kann von einem Rechner aus nicht auf die WebGUI der Fritte zugreifen.

Auch nicht, wenn Du im Browser die "192.168.179.1" eingibst :kratz:

Nein. Mal ganz abgesehen davon dass die Standard Webadresse der Fritte 192.168.178.1 lauten müsste. Aber über beide komme ich nicht hinter der pfsense drauf weder http noch https.

Auf was willst du hinaus?


Gesendet von iPhone mit Tapatalk Pro

 

[Andreas1969]

Auf was willst du hinaus?

Das WEB IF der Fritzbox ist auch unter der Gast-LAN Adresse erreichbar, also unter der 192.168.179.1
Die Frage war ja jetzt , ob das auch vom Bridge Anschluss aus geht :kratz:

 

[tomcatcw]

Auf was willst du hinaus?

Das WEB IF der Fritzbox ist auch unter der Gast-LAN Adresse erreichbar, also unter der 192.168.179.1
Die Frage war ja jetzt , ob das auch vom Bridge Anschluss aus geht :kratz:

Ah so. Ich habe aber m. E. Das Gast LAN deaktiviert. Damit eben genau das nicht passiert und irgend jemand die pfsense hintergeht.


Gesendet von iPhone mit Tapatalk Pro

 

[Andreas1969]

Ah so. Ich habe aber m. E. Das Gast LAN deaktiviert. Damit eben genau das nicht passiert und irgend jemand die pfsense hintergeht.

Bei @Freaky21 geht das komischerweise, obwohl er das Gast LAN auch deaktiviert hat.
https://www.unitymediaforum.de/viewtopic.php?f=90&t=36100

 

[premiumpixel]

Hallo Premiumpixel,

Ganz genau. In der Fritte habe ich alle öffentlichen statischen IPs eingetragen und als exposed host freigegeben. Die Fritte hängt über den LAN Port 4 am WAN der pfsense. In der pfsense ist die erste verfügbare IP als statische am WAN eingetragen. Die anderen verbleibenden 4 IP als virtual IP eingetragen und können dann individuell zugeordnet werden. Vergiss nicht die einzelnen IP im Outbound NAT im Manual Mode einzutragen.

Viel Erfolg, meld du noch Fragen hast.

Gruß.

Hallo tomcatcw,

vielen Dank für deine Antwort.
Noch ein Detail: "Sieht" die fritz.box auch die Virtuellen IPs direkt? Also unter Heimnetzwerk, tauchen da alle 5 IPs auf?

Meine Firewall (Cisco Meraki MX80) kann leider keine virtuellen IPs, sondern nur NAT.
Somit ist in meiner fritz.box nur eine IP (die der Firewall) sichtbar und Exposed Host Einträge müssen auf bekannte IPs zeigen.

Vielen Dank für die Hilfe!

 

[tq1199]

Hmm, also anpingen per

<i>
</i>ping -c 3 -W 2 192.168.178.1

geht. Die anderen Befehle kennt pfsense nicht. Aber ich kann von einem Rechner aus nicht auf die WebGUI der Fritte zugreifen.

Es geht nicht um die IP-Adresse 192.168.178.1 sondern um die IP-Adresse 192.168.179.1 (auch bei deaktiviertem Gast-LAN):

BTW: mtr und nmap könnten für die pfsense aber (nach)installiert werden. Z. B.:

<i>
</i>https://github.com/pfsense/FreeBSD-ports/blob/devel/net/pfSense-pkg-mtr-nox11/pkg-descr
https://github.com/pfsense/FreeBSD-ports/blob/devel/security/pfSense-pkg-nmap/pkg-descr
https://doc.pfsense.org/index.php/Package_Port_List

Betr. nc siehe evtl. auch nach:

<i>
</i>which netcat
which ncat

in der pfsense.

Hast Du evtl. in der pfsense (mit der Firewall), Anfragen bzw. den Zugang aus deren Subnetz in die Subnetzte der FB (192.168.178.0/24 bzw. 192.168.179.0/24) blockiert?

 

[thomas_lange]

Hallo Zusammen,
ich kann zu dem Thema auch meine Odyssee schreiben...

Bei mir war es die Umstellung auf 200/20 und damit der Wechsel der FB von 6360 auf 6490 und Wechsel von Bridge Mode auf RIPE...

Nach langem hin und her, und da man ja von UM keine Anleitung erwarten darf, geschweige den Telefonische Hilfe, habe ich die FB mit "statischer IP" so zum Laufen gebracht:

FB UM FW 6.75 - IP xxx.61
FB Netz 192.168.10.0/24
LAN 4 bei Portkonfiguration angehakt
feste IP als exposed Host "manuell" eingetragen xxx.62
IP (xxx.62) + Netmask (255.252) + GW (xxx.61) beim Server manuel eingetragen - DHCP wie früher im Bridged Modus gibt es nicht mehr...

OK so ist der Server aus dem Internet erreichbar... so weit so gut, nun die Probleme:

1. Die Eintragung als Exposed Host gehen ab und zu nach Neustart der Fritzbox verloren, dann ist der Server nicht mehr erreichbar! Die IP eintragen geht dann nicht, - bricht mit Fehler ab!!!! Dann muss erst bei Portkonfig der Haken bei LAN4 raus und wieder rein, dann kann der Host wieder eingetragen werden.

2. Aus dem FB Netz (192.168.10.0/24) ist der Server weder per Ping noch per tracert erreichbar!!! - Nachdem ich am Client als DNS Server nicht die FB sondern 8.8.8.8 eingetragen habe ist der Server pingbar, aber http/https etc. geht nicht!!!!

Hat jemand eine Idee wie ich meinen Server auf der offziellen Adresse auf meinem FB Netz erreichen kann? - Ich habe inzwischen herausgefunden, dass man wohl etwas bei den IP Routen einstellen kann, leider hat das nur bedingt Erfolg gebracht - http/https geht aber SSH geht nicht.... Die Route scheint wohl eine Einbahnstrasse zu sein.

3. Trotz aktvieren IPv6 sind weder vom Server, noch vom FB Netz IPv6 Adressen im Internet erreichbar!! (und ja IPv6 ist auch am Client aktiv..)

Hat jemand die selben Probleme oder Ideen was man machen oder einstellen kann?

Danke

 

[tq1199]

2. Aus dem FB Netz (192.168.10.0/24) ist der Server weder per Ping noch per tracert erreichbar!!! - Nachdem ich am Client als DNS Server nicht die FB sondern 8.8.8.8 eingetragen habe ist der Server pingbar, aber http/https etc. geht nicht!!!!

Wie hast Du gepingt? Warum soll ein anderer DNS-Server so einen Einfluss haben, ob eine _IP-Adresse_ per ping erreichbar ist oder nicht erreichbar ist?

Ich habe inzwischen herausgefunden, dass man wohl etwas bei den IP Routen einstellen kann, leider hat das nur bedingt Erfolg gebracht - http/https geht aber SSH geht nicht.... Die Route scheint wohl eine Einbahnstrasse zu sein.

Was hast Du bei dem routing konfiguriert? Wenn http bzw. https funktioniert, warum soll ein anderer Port (hier 22 für ssh?) nicht auch erreichbar sein. Evtl. ist ssh nicht richtig konfiguriert? Versuch mal auf dem Server mit z. B.:

<i>
</i>sudo tcpdump -c 40 -vvveni <Interface> tcp portrange 22-443

(oder gleichwertgi) und danach ein Portscan aus dem FB-Netz auf die Ports 22, 80, 443 (wenn so konfiguriert).

3. Trotz aktvieren IPv6 sind weder vom Server, noch vom FB Netz IPv6 Adressen im Internet erreichbar!! (und ja IPv6 ist auch am Client aktiv..)

Haben die Geräte, externe IPv6-Adressen? Evtl. mit:

<i>
</i>dig -6 aaaa +short myip.opendns.com @2620:0:ccc::2

(oder gleichwertig) testen. Wie hast Du IPv6, für deinen Business-Tarif konfiguriert? ... denn Dual-Stack wirst Du mit dem Business-Tarif ja nicht haben, oder?

 

[thomas_lange]

Hi,
hier die Antworten:

- Wie hast Du gepingt? Warum soll ein anderer DNS-Server so einen Einfluss haben, ob eine _IP-Adresse_ per ping erreichbar ist oder nicht erreichbar ist?

Ping auf Server <domainname>.biz aus FB Netz - nicht erreichbar. Der Server ist von außen pingbar, habe extra die TTL im DNS lange vor der Umstellung auf 600 gestellt. Auf jeden Fall kann der Fritzbox DNS Server nicht die IP des Servers auflösen. Mit 8.8.8.8 kann er die IP auflösen, aber Ping Timeout (ohne die Route in der FB - siehe unten)

- Was hast Du bei dem routing konfiguriert?

Also "Heimnetz - Netzwerkeinstellungen - Statische IPv4 Routen:
Netzwerk xxx.60 (oder 62)
Netmask 255.252
Gateway <FB Locel IP> 192.168.10.254

So lässt sich der Server pingen und http/s geht, SSH nicht. Ich habe aber gesehen das ab und zu der Server nicht erreichbar ist, dann geht es wieder (ohne das ich was mache)....

- Wenn http bzw. https funktioniert, warum soll ein anderer Port (hier 22 für ssh?) nicht auch erreichbar sein. Evtl. ist ssh nicht richtig konfiguriert?

Genau das ist das was ich mich auch Frage! Macht von der Logik her keinen Sinn!!
SSH etc. ist korrekt konfiguriert, wie gesagt, von extern kann ich auf alle Server Dienste zugreifen.

- Haben die Geräte, externe IPv6-Adressen?
Ja haben sie eine schöne 2002 unter dem der FB IPv6

Ich habe (wie vorher auch schon) bei "Internet - Zugangsart - IPv6-Unterstützung aktiv gesetzt", dann bekommt die FB neben der IPv4 auch eine IPv6 zugewiesen. Gleiche Konfig läuft so auch auf einer anderen FB von UM allerding mit FW 6.50.

Fritzbox:
IPv4, verbunden seit 05.02.2018, 00:04 Uhr
IPv4-Adresse: XXX.XXX.XXX.61

IPv6, verbunden seit 05.02.2018, 00:04 Uhr
IPv6-Adresse: 2002:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

Server:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet XXX.XXX.XXX.62 netmask 255.255.255.252 broadcast XXX.XXX.XXX.63
inet6 2002:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx prefixlen 64 scopeid 0x0<global>
inet6 fe80::xxxx:xxxx:xxxx:xxxx prefixlen 64 scopeid 0x20<link>
ether XX:XX:XX:XX:XX:XX txqueuelen 1000 (Ethernet)
RX packets 31685058 bytes 68127297547 (63.4 GiB)
RX errors 0 dropped 28 overruns 0 frame 0
TX packets 42839961 bytes 85179338172 (79.3 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Client im FB Netz:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.5 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::20c:29ff:xxxx:xxxx prefixlen 64 scopeid 0x20<link>
inet6 2002:xxxx:xxxx:0:20c:29ff:xxxx:xxxx prefixlen 64 scopeid 0x0<global>
ether 00:0c:XX:XX:XX:XX txqueuelen 1000 (Ethernet)
RX packets 369049 bytes 141495461 (134.9 MiB)
RX errors 0 dropped 41383 overruns 0 frame 0
TX packets 47951 bytes 41038109 (39.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

thx
Thomas

 

[tq1199]

SSH etc. ist korrekt konfiguriert, wie gesagt, von extern kann ich auf alle Server Dienste zugreifen.

Dann schau mal auf dem Server, mit tcpdump oder wireshark (oder gleichwertig), ob die Anfrage (über die externe IPv4-Adresse) aus dem Netz der FB, auf dem lauschenden TCP-Port des sshd ankommt.

Client im FB Netz:

<i>
</i>eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.5 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::20c:29ff:xxxx:xxxx prefixlen 64 scopeid 0x20<link> inet6 2002:xxxx:xxxx:0:20c:29ff:xxxx:xxxx prefixlen 64 scopeid 0x0<global> ether 00:0c:XX:XX:XX:XX txqueuelen 1000 (Ethernet)

Wie das mit RIP und IPv6 ist weiß ich nicht, ... aber für den Client im FB-Netz per IPv6, hast Du die IPv6-Firewall der FB entsprechend konfiguriert?

 

[thomas_lange]

- Dann schau mal auf dem Server, mit tcpdump oder wireshark (oder gleichwertig), ob die Anfrage (über die externe IPv4-Adresse) aus dem Netz der FB, auf dem lauschenden TCP-Port des sshd ankommt.

Kommt nix an! Auf zweitem Interface mit FB Netzwerk geht es sauber durch...

- Wie das mit RIP und IPv6 ist weiß ich nicht, ... aber für den Client im FB-Netz per IPv6, hast Du die IPv6-Firewall der FB entsprechend konfiguriert?

Firewall in der Fritzbox ? Der Server ist als exposed Host eingetragen, da sollte nichts dazwischen stehen..

 

[tq1199]

Kommt nix an! ...

Und für die Ports 80 und 443 kommt was an? Dann hast Du einen Konfigurationfehler, evtl. auch im Client, ... eine Firewall?

Firewall in der Fritzbox ? Der Server ist als exposed Host eingetragen, da sollte nichts dazwischen stehen..

Ja, IPv6-Firewall in der FB. Aber es geht um den Client im Netz der FB und nicht um den Server. Beim Server (RIP) kann ich dir bzgl. IPv6 nicht helfen.

EDIT:

BTW: Für den Portscan verwendet man "neutrale" tools und nicht den ssh-/http-Client. Z. B.:

<i>
</i>nc -zv <IP-Adresse> 80
nc -zv <IP-Adresse> 443
nc -zv <IP-Adresse> 22

oder nmap oder nping oder gleichwertig.

 

[thomas_lange]

Danke für dein Feedback.

- Und für die Ports 80 und 443 kommt was an? Dann hast Du einen Konfigurationfehler, evtl. auch im Client, ... eine Firewall?

iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Das denke ich nicht. Aus dem Internet kommt auf alle Dienste die ich konfiguriert habe:
nc -zv <domainname>.biz 22
<domainname>.biz [XXX.XXX.XXX.62] 22 (ssh) open

Beide Clients sind identisch konfiguriert, stehen nur in unteschiedlichen RZ jeweils mit UM Anbindung

Aus meinem FB Netz (192.168.10.0/24) kommt bei 80 443 21 open und bei 22 Connection timed out.
Aus anderen Netzen kommt open.

Ich denke die FW der Fritz ist nicht ausgereift, nicht umsonst gibt es von AVM einige neuere Versionen, aber bei UM mit "Miet"-FB kann man ja nichts einspielen. Das würde auch erklären warum die FB die Konfig nach Reboot ab und zu verliert..

- Ja, IPv6-Firewall in der FB.

Und wenn du mir nun noch sagst wo die ist ?

Ich tippe hier eher auf ein Netzproblem, die FB wurde ja schon getauscht, dass IPv6 Adressen nicht erreichbar sind, ist seit einem Netzausfall so.

 

[tq1199]

Aus meinem FB Netz (192.168.10.0/24) kommt bei 80 443 21 open und bei 22 Connection timed out.

Ein "time out" ist noch kein Beweis, dass die Anfrage mit dem syn-Flag, auf dem Server nicht ankommt. Der Server wird nicht antworten, weil die nc-Anfrage ja keine Anfrage von einem (richtig) konfiguriertem ssh-Client ist.

Deshalb mein Vorschlag, auf dem Server mit tcpdump (oder gleichwertig) zu sniffen:

<i>
</i>tcpdump -c 40 -vvven tcp port 22

 

[thomas_lange]

Viel Spaß beim analysieren :

<i>
</i>19:50:00.088153 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 190: (tos 0x10, ttl 64, id 53826, offset 0, flags [DF], proto TCP (6), length 176) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41930: Flags [P.], cksum 0xc019 (incorrect -> 0xac89), seq 3440771948:3440772072, ack 1070659236, win 316, options [nop,nop,TS val 102855399 ecr 136334041], length 124
19:50:00.088526 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 41, id 27500, offset 0, flags [DF], proto TCP (6), length 104) XXX.XXX.XXX.XXX.11701 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0xba75 (correct), seq 2025123238:2025123290, ack 1571307036, win 262, options [nop,nop,TS val 2852606 ecr 102854846], length 52
19:50:00.088541 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 22991, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.11701: Flags [.], cksum 0x8c06 (incorrect -> 0xb995), seq 1, ack 52, win 247, options [nop,nop,TS val 102855399 ecr 2852606], length 0
19:50:00.088608 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 64, id 22992, offset 0, flags [DF], proto TCP (6), length 104) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.11701: Flags [P.], cksum 0x8c3a (incorrect -> 0xa998), seq 1:53, ack 52, win 247, options [nop,nop,TS val 102855399 ecr 2852606], length 52
19:50:00.114659 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 49, id 29671, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.XXX.41930 > XXX.XXX.XXX.62.22: Flags [.], cksum 0x3a3b (correct), seq 1, ack 124, win 1444, options [nop,nop,TS val 136334058 ecr 102855399], length 0
19:50:00.333135 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 41, id 27501, offset 0, flags [DF], proto TCP (6), length 120) XXX.XXX.XXX.XXX.11701 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0x2d6c (correct), seq 52:120, ack 53, win 262, options [nop,nop,TS val 2852667 ecr 102855399], length 68
19:50:00.334138 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 64, id 22993, offset 0, flags [DF], proto TCP (6), length 120) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.11701: Flags [P.], cksum 0x8c4a (incorrect -> 0xa78a), seq 53:121, ack 120, win 247, options [nop,nop,TS val 102855460 ecr 2852667], length 68
19:50:00.923783 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 64, id 22994, offset 0, flags [DF], proto TCP (6), length 120) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.11701: Flags [P.], cksum 0x8c4a (incorrect -> 0xa6f6), seq 53:121, ack 120, win 247, options [nop,nop,TS val 102855608 ecr 2852667], length 68
19:50:01.531795 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 64, id 22995, offset 0, flags [DF], proto TCP (6), length 120) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.11701: Flags [P.], cksum 0x8c4a (incorrect -> 0xa65e), seq 53:121, ack 120, win 247, options [nop,nop,TS val 102855760 ecr 2852667], length 68
19:50:01.693140 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 49, id 52690, offset 0, flags [DF], proto TCP (6), length 60) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [S], cksum 0x81cf (correct), seq 445153702, win 29200, options [mss 1460,sackOK,TS val 136334452 ecr 0,nop,wscale 7], length 0
19:50:01.693168 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [S.], cksum 0xbfa5 (incorrect -> 0x8c8d), seq 3831600933, ack 445153703, win 28960, options [mss 1460,sackOK,TS val 102855800 ecr 136334452,nop,wscale 7], length 0
19:50:01.725823 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 49, id 52691, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [.], cksum 0x2b8d (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 136334460 ecr 102855800], length 0
19:50:01.730140 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 106: (tos 0x0, ttl 49, id 52692, offset 0, flags [DF], proto TCP (6), length 92) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0x91bc (correct), seq 1:41, ack 1, win 229, options [nop,nop,TS val 136334460 ecr 102855800], length 40
19:50:01.730171 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 58278, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [.], cksum 0xbf9d (incorrect -> 0x2b5e), seq 1, ack 41, win 227, options [nop,nop,TS val 102855809 ecr 136334460], length 0
19:50:01.731014 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 105: (tos 0x0, ttl 64, id 58279, offset 0, flags [DF], proto TCP (6), length 91) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [P.], cksum 0xbfc4 (incorrect -> 0x9498), seq 1:40, ack 41, win 227, options [nop,nop,TS val 102855809 ecr 136334460], length 39
19:50:01.784420 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 49, id 52693, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [.], cksum 0x2b26 (correct), seq 41, ack 40, win 229, options [nop,nop,TS val 136334475 ecr 102855809], length 0
19:50:01.784450 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 1146: (tos 0x0, ttl 64, id 58280, offset 0, flags [DF], proto TCP (6), length 1132) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [P.], cksum 0xc3d5 (incorrect -> 0x9ca9), seq 40:1120, ack 41, win 227, options [nop,nop,TS val 102855823 ecr 136334475], length 1080
19:50:01.838801 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 1498: (tos 0x0, ttl 49, id 52694, offset 0, flags [DF], proto TCP (6), length 1484) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0xb5f1 (correct), seq 41:1473, ack 40, win 229, options [nop,nop,TS val 136334476 ecr 102855809], length 1432
19:50:01.879558 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 49, id 52695, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [.], cksum 0x2121 (correct), seq 1473, ack 1120, win 245, options [nop,nop,TS val 136334498 ecr 102855823], length 0
19:50:01.879590 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 58281, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [.], cksum 0xbf9d (incorrect -> 0x211c), seq 1120, ack 1473, win 249, options [nop,nop,TS val 102855846 ecr 136334476], length 0
19:50:01.914113 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 114: (tos 0x0, ttl 49, id 52696, offset 0, flags [DF], proto TCP (6), length 100) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0x75c6 (correct), seq 1473:1521, ack 1120, win 245, options [nop,nop,TS val 136334508 ecr 102855846], length 48
19:50:01.919228 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 486: (tos 0x0, ttl 64, id 58282, offset 0, flags [DF], proto TCP (6), length 472) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [P.], cksum 0xc141 (incorrect -> 0x1957), seq 1120:1540, ack 1521, win 249, options [nop,nop,TS val 102855856 ecr 136334508], length 420
19:50:01.951914 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 49, id 52697, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [.], cksum 0x1f08 (correct), seq 1521, ack 1540, win 262, options [nop,nop,TS val 136334517 ecr 102855856], length 0
19:50:01.957088 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 49, id 52698, offset 0, flags [DF], proto TCP (6), length 68) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0x14cd (correct), seq 1521:1537, ack 1540, win 262, options [nop,nop,TS val 136334519 ecr 102855856], length 16
19:50:01.999795 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 58283, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [.], cksum 0xbf9d (incorrect -> 0x1eee), seq 1540, ack 1537, win 249, options [nop,nop,TS val 102855877 ecr 136334519], length 0
19:50:02.041131 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 110: (tos 0x0, ttl 49, id 52699, offset 0, flags [DF], proto TCP (6), length 96) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0x45f2 (correct), seq 1537:1581, ack 1540, win 262, options [nop,nop,TS val 136334538 ecr 102855877], length 44
19:50:02.041148 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 58284, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [.], cksum 0xbf9d (incorrect -> 0x1ea5), seq 1540, ack 1581, win 249, options [nop,nop,TS val 102855887 ecr 136334538], length 0
19:50:02.041222 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 110: (tos 0x0, ttl 64, id 58285, offset 0, flags [DF], proto TCP (6), length 96) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [P.], cksum 0xbfc9 (incorrect -> 0x3bad), seq 1540:1584, ack 1581, win 249, options [nop,nop,TS val 102855887 ecr 136334538], length 44
19:50:02.073874 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 49, id 52700, offset 0, flags [DF], proto TCP (6), length 112) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0x48df (correct), seq 1581:1641, ack 1584, win 262, options [nop,nop,TS val 136334546 ecr 102855887], length 60
19:50:02.074612 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 64, id 58286, offset 0, flags [DF], proto TCP (6), length 104) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [P.], cksum 0xbfd1 (incorrect -> 0x14a5), seq 1584:1636, ack 1641, win 249, options [nop,nop,TS val 102855895 ecr 136334546], length 52
19:50:02.110751 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 430: (tos 0x0, ttl 49, id 52701, offset 0, flags [DF], proto TCP (6), length 416) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0xd96b (correct), seq 1641:2005, ack 1636, win 262, options [nop,nop,TS val 136334555 ecr 102855895], length 364
19:50:02.111014 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 390: (tos 0x0, ttl 64, id 58287, offset 0, flags [DF], proto TCP (6), length 376) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [P.], cksum 0xc0e1 (incorrect -> 0x74e8), seq 1636:1960, ack 2005, win 272, options [nop,nop,TS val 102855904 ecr 136334555], length 324
19:50:02.119881 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 64, id 60327, offset 0, flags [DF], proto TCP (6), length 120) XXX.XXX.XXX.62.22 > 58.242.83.24.18808: Flags [P.], cksum 0xcd11 (incorrect -> 0xe529), seq 1930336417:1930336485, ack 3541415307, win 247, options [nop,nop,TS val 102855907 ecr 654958796], length 68
19:50:02.152168 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 702: (tos 0x0, ttl 49, id 52702, offset 0, flags [DF], proto TCP (6), length 688) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0x352e (correct), seq 2005:2641, ack 1960, win 279, options [nop,nop,TS val 136334565 ecr 102855904], length 636
19:50:02.152681 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 58288, offset 0, flags [DF], proto TCP (6), length 80) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [P.], cksum 0xbfb9 (incorrect -> 0x44e5), seq 1960:1988, ack 2641, win 294, options [nop,nop,TS val 102855915 ecr 136334565], length 28
19:50:02.194809 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 178: (tos 0x0, ttl 49, id 52703, offset 0, flags [DF], proto TCP (6), length 164) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [P.], cksum 0x8f88 (correct), seq 2641:2753, ack 1988, win 279, options [nop,nop,TS val 136334576 ecr 102855915], length 112
19:50:02.194827 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 1006: (tos 0x0, ttl 64, id 58289, offset 0, flags [DF], proto TCP (6), length 992) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [P.], cksum 0xc349 (incorrect -> 0x3c7c), seq 1988:2928, ack 2753, win 294, options [nop,nop,TS val 102855925 ecr 136334576], length 940
19:50:02.270128 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 49, id 52704, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [.], cksum 0x1415 (correct), seq 2753, ack 2928, win 296, options [nop,nop,TS val 136334597 ecr 102855925], length 0
19:50:02.270139 XX:XX:XX:XX:XX:XX > cc:ce:1e:a5:15:bd, ethertype IPv4 (0x0800), length 110: (tos 0x0, ttl 64, id 58290, offset 0, flags [DF], proto TCP (6), length 96) XXX.XXX.XXX.62.22 > XXX.XXX.XXX.XXX.41936: Flags [P.], cksum 0xbfc9 (incorrect -> 0x2ad4), seq 2928:2972, ack 2753, win 294, options [nop,nop,TS val 102855944 ecr 136334597], length 44
19:50:02.305377 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 49, id 52705, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.XXX.41936 > XXX.XXX.XXX.62.22: Flags [.], cksum 0x13d0 (correct), seq 2753, ack 2972, win 296, options [nop,nop,TS val 136334603 ecr 102855944], length 0

 

[johnripper]

Hä?

Welche IPv4 bekommt der Server? Wohl eine Private aus dem 192.168.1/24 Netz sonst wäre kein exposted host nötig.

Das ist natürlich völliger quatsch und statisch ist die IPv4 nicht.

Gesendet von meinem SM-G935F mit Tapatalk

 

[tq1199]

Viel Spaß beim analysieren :

<i>
</i>19:50:00.114659 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 49, id 29671, offset 0, flags [DF], proto TCP (6), length 52) XXX.XXX.XXX.XXX.41930 > XXX.XXX.XXX.62.22: Flags [.], cksum 0x3a3b (correct), seq 1, ack 124, win 1444, options [nop,nop,TS val 136334058 ecr 102855399], length 0

Lt. tcpdump wird der Port 22 erreicht:

<i>
</i>XXX.XXX.XXX.XXX.41930 > XXX.XXX.XXX.62.22

 

[thomas_lange]

Ja wie ich ja schreibe, von extern aus auf den Server mit statischer IP geht SSH. Nur sobald ich aus dem LAN der FB auf die statische IP will geht es nicht.

Es kommt mir so vor, als wäre SSH auf die statische IP vom FB LAN aus in der FB geblockt... ... bloß wo? Jedenfalls nicht von meinem Server.