- Anzeige -

Seit neuem keine Portfreigabe mehr möglich.

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Wichtig:
  • Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
  • Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon SpaceRat » 24.06.2014, 01:51

phil402 hat geschrieben:
tq1199 hat geschrieben:Wie sind die ersten 3 Zeichen der IPv4-Adresse aus dem TC7200?

Sagt das irgendwas aus?

Nicht das Geringste.
Zuletzt geändert von SpaceRat am 24.06.2014, 09:25, insgesamt 1-mal geändert.
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2614
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon tq1199 » 24.06.2014, 09:08

phil402 hat geschrieben:Die Ip Adresse lautet:

178.202.xxx.xx

Sagt das irgendwas aus?

Ja, dass Du eine IPv4-Adresse hast, die über das Internet geroutet wird.
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note
tq1199
Glasfaserstrecke
 
Beiträge: 1265
Registriert: 07.02.2014, 10:05

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon SpaceRat » 24.06.2014, 09:24

tq1199 hat geschrieben:
phil402 hat geschrieben:Sagt das irgendwas aus?
Ja, dass Du eine IPv4-Adresse hast, die über das Internet geroutet wird.

Ok, das stimmt.
Bringt ihn aber nicht weiter.

Die entscheidende Information wäre nämlich, ob er evtl. doch DS-lite hat.
Bei einer IP mit 178 am Anfang ist das weniger wahrscheinlich, aber nicht ausgeschlossen.

Der Nummernbereich der verwendeten IPv4 ist so oder so aus dem öffentlichen Bereich und wird dementsprechend auch immer über das Internet geroutet -> Nullinformation.
Die bisher geposteten IPv4-Adressen von DS-lite-Kunden stammten zwar alle oder fast alle aus dem Bereich 37.x.y.z, allerdings bekommen auch IPv4-only-Kunden durchaus IP-Adressen aus diesem Bereich zugewiesen¹, es hat also keine Aussagekraft.
Umgekehrt kann Unitymedia/KBW jederzeit ein AFTR-Gateway mit Adressen aus irgendeinem anderen Bereich füttern oder hat es vielleicht sogar schon getan. Immerhin ist das Thema DS-lite weitgehend durch und wird daher hier erstens weniger und zweitens auf einer völlig anderen Ebene diskutiert als noch vor 1 Jahr, aktuelle "Sammlungen" von IPv4-Adressen von DS-lite-Kunden haben wir also nicht. Also hat auch eine IPv4 != 37.x.y.z keinerlei Aussagekraft mehr.

Die einzige Methode, wie man einen DS-lite-Anschluß zuverlässig erkennen kann, ist und bleibt ein Hinweis auf die Verwendung eines AFTR-Gateways in der Oberfläche des DK7200, des Cisco EPC3208G oder der Fritz!Box 63x0.


¹Meine aktuelle IPv4 z.B.:
Internet, IPv4 verbunden seit 23.06.2014, 09:34 Uhr, Unitymedia, IP-Adresse: 37.201.xxx.230
Und ja, ich wüßte definitiv, wenn das DS-lite wäre :)
Receiver/TV:
  • Vu+ Duo² 4xS2 / OpenATV 5.3@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2 / OpenATV 6.0@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.0
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Mega HD, Brazzers, XXL, HD-, Sky
Fon: VF Komfort-Classic (ISDN), Siemens S79H+S1+Telekom Modula+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2614
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon phil402 » 24.06.2014, 12:10

Okay, besten Dank für die Infos.
Ich könnte zwar schwören, dass ich früher Ports getestet habe, ohne das Fenster zu öffnen, aber scheinbar liege ich da falsch oder ich hatte zufällig immer den Dienst am Laufen.

Ich habe kein DS-Lite und nach mehrmaligem resetten des DK7200 können Leute auch wieder durch mein Fenster schauen, wenn ich dem Router sage, dass die Rolladen oben sein sollen. Ich denke, dass die Funktionalität des DMZ-Hosts beeinträchtigt war.
(Die derzeitige Konfiguration überbrückt den DK7200 mit der DMZ-Funktionalität, sodass der TP-Link dahinter für alles weitere zuständig ist)

Nichts desto trotz kommt heute ein Techniker, da irgendetwas mit meinen Modemwerten nicht zu stimmen scheint. (Eigentlich habe ich zu jeder Tageszeit den max. Down und Upstream und einen guten ping). Mal abwarten, was der gute Herr gleich sagt.

Eine Frage an Spacerat noch: Deiner Erklärung nach gehört die Windowsfirewall dann auch zu den unnützten Consumerfirewalls, richtig? Kann ich die ruhigen Gewissens abschalten und den Router die Arbeit machen lassen? (Im Router habe ich eine SPI-Firewall aktiviert)
phil402
Kabelneuling
 
Beiträge: 23
Registriert: 27.10.2011, 21:58

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon tq1199 » 24.06.2014, 12:46

phil402 hat geschrieben:Ich könnte zwar schwören, dass ich früher Ports getestet habe, ohne das Fenster zu öffnen, ...

Mit den entsprechenden tools ist das auch möglich. Z. B. mit tcpdump (oder gleichwertig) kann man feststellen ob z. B. eine FB6360 den dort konfigurierten Port 3333 korrekt weiterleitet, obwohl auf dem Port 3333 (... am Gerät hinter der FB6360, wo tcpdump aktiv ist) nicht gelauscht wird. Im Internet sehe ich das aber nicht:
Im Internet:
~ $ sudo nmap -sS 37.###.###.### -p3333,3334

Starting Nmap 6.00 ( http://nmap.org ) at 2014-06-24 12:27 CEST
Nmap scan report for HSI-KBW-37-###-###-###.hsi14.kabel-badenwuerttemberg.de (37.###.###.###)
Host is up (0.021s latency).
PORT STATE SERVICE
3333/tcp filtered dec-notes
3334/tcp filtered directv-web

Gerät hinter der FB6360:
:~$ sudo tcpdump -vvveni any port 3333 or port 3334

12:27:22.259905 In 9c:##:##:##:##:## ethertype IPv4 (0x0800), length 60: (tos 0x3,CE, ttl 57, id 25062, offset 0, flags [none], proto TCP (6), length 44)
46.###.###.###.40697 > 192.168.178.21.3333: Flags [S], cksum 0x75cd (correct), seq 1060094683, win 1024, options [mss 1460], length 0
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note
tq1199
Glasfaserstrecke
 
Beiträge: 1265
Registriert: 07.02.2014, 10:05

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon phil402 » 24.06.2014, 16:39

Okay, dann hatte ich noch weniger Ahnung davon als ich dachte :D

Nochmal die Frage: Brauche ich die Windows Firewall, wenn im Router SPI-Firewall aktiv ist?
phil402
Kabelneuling
 
Beiträge: 23
Registriert: 27.10.2011, 21:58

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon failure404 » 24.06.2014, 20:31

phil402 hat geschrieben:Nochmal die Frage: Brauche ich die Windows Firewall, wenn im Router SPI-Firewall aktiv ist?

Besser ist das.
SPI Firewall = First line of defense
Win Firewall = Second line of defense
Man kann die beiden auch nicht wirklich miteinander vergleichen, da beide völlig unterschiedlich arbeiten.
failure404
Kabelneuling
 
Beiträge: 29
Registriert: 18.06.2014, 21:21

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon magentis » 24.06.2014, 20:34

failure404 hat geschrieben:
phil402 hat geschrieben:Nochmal die Frage: Brauche ich die Windows Firewall, wenn im Router SPI-Firewall aktiv ist?

Besser ist das.
SPI Firewall = First line of defense
Win Firewall = Second line of defense
Man kann die beiden auch nicht wirklich miteinander vergleichen, da beide völlig unterschiedlich arbeiten.


Vorallem kann die Windows Firewall auch den I-Net Verkehr nach draussen unterbinden wenn man möchte. Ist zwar auch kein 100%iger Schutz, aber besser als wenn alles ungehindert von drinnen nach draussen kann.
3Play Premium 100
DigitalTV Allstars + HD Option
Echostar Recorder
Cisco EPC 3208
Firmwarename: e3200-E10-5-v302r125562-130611c_upc.bin Jun 19 17:34:31 2013
Config-File: generic_100000_5000_ipv4_ncs_wifi-on.bin
Asus RT-N66U
Samsung UE40F6500
Sky Buli + Sport HD auf Sky Recorder
Synology DS213+

Die Moral von der Geschicht, traue keinen Versprechungen der UM-Hotliner.
magentis
Übergeordneter Verstärkerpunkt
 
Beiträge: 586
Registriert: 15.03.2013, 10:00

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon tq1199 » 24.06.2014, 22:10

phil402 hat geschrieben:Nochmal die Frage: Brauche ich die Windows Firewall, wenn im Router SPI-Firewall aktiv ist?

Ich benutze den Paketfilter nur für das (W)LAN, um z. B. den Rechner vor der FritzBox und die FritzBox aus dem bzw. via (W)LAN zu schützen. Z. B. versucht meine FB6360, sporadisch mit der Notfall-IP 169.254.1.1 und dem Port 8181 auf meinen Rechner zuzugreifen. Keine Ahnung warum das so ist:
Code: Alles auswählen
...
13:26:14.695186  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.56311: Flags [S.], cksum 0x1dc7 (incorrect -> 0x1184), seq 2087414202, ack 1102117100, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
13:26:31.328437  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.56360: Flags [S.], cksum 0x5ce9 (incorrect -> 0x50a6), seq 2357294800, ack 3206946551, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
13:29:16.105914  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.56510: Flags [S.], cksum 0x568f (incorrect -> 0x4a4c), seq 653474412, ack 2774392950, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:07:02.669128  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 77, id 30131, offset 0, flags [DF], proto UDP (17), length 62)
    127.0.0.1.8181 > 127.0.0.1.53: [bad udp cksum 0xfe3d -> 0x7e9f!] 57199+ A? forum.kabelbw.de. (34)
15:07:02.669179  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 54694, offset 0, flags [none], proto UDP (17), length 78)
    127.0.0.1.53 > 127.0.0.1.8181: [udp sum ok] 57199 q: A? forum.kabelbw.de. 1/0/0 forum.kabelbw.de. [1m] A 82.212.63.100 (50)
15:07:02.669353  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 77, id 30132, offset 0, flags [DF], proto UDP (17), length 78)
    127.0.0.1.53 > 127.0.0.1.8181: [bad udp cksum 0xfe4d -> 0xaa4e!] 57199 q: A? forum.kabelbw.de. 1/0/0 forum.kabelbw.de. [5m56s] A 82.212.63.100 (50)
15:09:46.633685  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34302: Flags [S.], cksum 0x2677 (incorrect -> 0x1a34), seq 718329851, ack 2923281666, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:09:46.849976  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32200, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 718332772:718334129, ack 2923282054, win 432, length 1357
15:09:47.267977  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32201, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:09:48.107792  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32202, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:09:49.788423  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32203, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:09:53.147742  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32204, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:09:59.198478  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34322: Flags [S.], cksum 0xb23c (incorrect -> 0xa5f9), seq 921080337, ack 1121834589, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:09:59.418345  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15675, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 921081798:921083258, ack 1121834951, win 432, length 1460
15:09:59.838315  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15676, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:09:59.869596  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32205, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:10:00.679146  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15677, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:02.358169  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15678, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:05.717800  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15679, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:12.440530  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15680, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:13.309065  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32206, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:10:25.879117  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15681, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:40.190271  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32207, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:10:40.503277  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34336: Flags [S.], cksum 0x6e60 (incorrect -> 0x621d), seq 1570755660, ack 1650954669, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:10:40.729071  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27402, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 1570759938, ack 1650955031, win 432, length 0
15:10:41.147866  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27403, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:41.987881  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27404, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:43.666929  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27405, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:45.292026  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34348: Flags [S.], cksum 0x18e2 (incorrect -> 0x0c9f), seq 1645834109, ack 311007059, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:10:45.507776  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44636, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 1645835570:1645837030, ack 311007421, win 432, length 1460
15:10:45.928551  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44637, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:46.768380  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44638, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:47.027392  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27406, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:48.448250  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44639, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:51.809242  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44640, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:52.757870  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15682, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:53.747382  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27407, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:58.531243  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44641, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:05.598760  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34365: Flags [S.], cksum 0x9825 (incorrect -> 0x8be2), seq 1961667940, ack 577222502, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:11:07.193288  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27408, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:11:11.969374  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44642, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:13.637075  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34381: Flags [S.], cksum 0x88cf (incorrect -> 0x7c8c), seq 2080486648, ack 3192003624, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:11:13.848121  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30920, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 2080488109:2080489569, ack 3192003986, win 432, length 1460
15:11:14.268812  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30921, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:15.110595  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30922, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:16.787787  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30923, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:20.150693  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30924, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:26.869144  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30925, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:34.067444  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27409, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:11:38.847858  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44643, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:40.311270  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30926, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:12:07.188105  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30927, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
...
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note
tq1199
Glasfaserstrecke
 
Beiträge: 1265
Registriert: 07.02.2014, 10:05

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitragvon SpaceRat » 25.06.2014, 03:12

phil402 hat geschrieben:Eine Frage an Spacerat noch: Deiner Erklärung nach gehört die Windowsfirewall dann auch zu den unnützten Consumerfirewalls, richtig? Kann ich die ruhigen Gewissens abschalten und den Router die Arbeit machen lassen? (Im Router habe ich eine SPI-Firewall aktiviert)

Ich würde sie anlassen.

Wenn irgendwann doch mal etwas passiert, dann schützt Dich eine aktuelle Firewall und ein aktueller Virenscanner zumindest vor deutschen Amtsrichterlein, die ihr Computer-Fachwissen aus der Computer BLÖD beziehen und dem Benutzer abverlangen, eine "aktuelle Firewall und einen aktuellen Virenscanner" zu benutzen.
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2614
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

VorherigeNächste

Zurück zu Internet und Telefon über das TV-Kabelnetz

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 34 Gäste