Verschil tussen inkomend en uitgaand verkeer bij firewall-instellingen KPN modem

Dat begrijp je verkeerd. Alle inkomende verkeer word toch al tegen gehouden. Daar heb je geen firewall instellingen voor nodig. Het gaat echt om uitgaande ftp verbindingen. Verbindingen vanaf jouw pc of laptop naar een server op internet dus. Die worden tegen gehouden bij de firewall op "midden".

Met de firewall instellingen zit je dus je eigen te pesten. Er is geen hacker die er door tegen gehouden word.

​@Marlon92 ok, dank je voor de verduidelijking.

Blijft mijn 2e vraag over. Op dit moment heb. ik alle regels (IP4 en IP6) van het ‘High’ level gekopieerd in mijn ‘Custom’ level en ‘Block all’ actief. Dit levert bij activering van ‘Custom’ level niet hetzelfde gedrag op als van ‘High’ level. Ik merk dat sommige apps op ‘High’ level wel werken en niet in ‘Custom’ level.

Wat mis ik?

Vriendelijke groet, 

Peter

Heb je de Mode wel op "Alles blokkeren" staan?

​@Marlon92 zeker… zie image…

​@Marlon92  zeker… ‘Block all’ in mijn geval.

En heb je ipv6 uitstaan? Of hoe zit dat met ipv6?

​@Marlon92  Ik vermoed van niet, maar de instellingen van IPv6 en IPv4 zijn identiek.

(ik weet ook even niet OF ik IPv6 moet deactiveren)

Na instellen:

• Regels waarbij de schuif naar links staat, dus niet groen, kunnen als niet aanwezig beschouwd worden.
• Bij groene regels bepaalt het symbool rechts wat er gebeurt: X=blokkeren, >>is doorlaten.

Evemtueel een screenshot? Welke app werkt niet?

​@hmmsjan_2 de schuifjes en symbolen snap ik 😏.

Hieronder 2  screenshots

1. de regels van mijn ‘Custom’ level die ik uit  het ‘High’ level heb overgenomen (met onder andere als extra poort 80, en maar 1 keer poort 53) . Er zijn nog meer ‘groene >>’ regels (die niet in de image staan) maar meer toelatings-regels lijkt me geen reden voor apps om niet te werken…
2. de settings van het ‘High’ level (waarin 2 keer poort 53 dns voorkomt met een andere keus voor protocol??)

ik heb aangenomen dat de id/naam van het protocol geen invloed heeft…

Apps die (onder andere) niet werken (op mijn telefoon):

• mijnkpn (komt niet eens tot inloggen) 
• live video stream van de ‘Ring’ app

ps: ik kom er net achter dat de video stream van Ring ook niet werkt op het ‘High’ level… wel op ‘Standard’ en ‘Medium’

Dat ziet er goed uit, dus “firewall level high” plus de mogelijkheid extra regels toe te voegen. 

DNS loopt in principe via UDP maar kan overschakelen naar TCP, dus beide moet. Dat DNS er twee keer in staat in “hoog” is wat vreemd, en dat HTTP er niet is staat is misschien wat te streng. Maar het overgrote deel van de websites is https. De video loopt dus blijkbaar via een andere poort en werkt dus niet via “hoog” en “aangepast/alles blokkeren”. De KPN app is vreemd, ik zou verwachten dat die gewoon via HTTPS werkt. Als die wel werkt in “hoog” en niet in “aangepast” klopt er iets niet.

https zou eigenlijk TCP/UDP moeten zijn i.v.m. HTTP/3+QUIC, zo loopt communicatie met bijv. google tegenwoordig, maar de browser valt wel terug naar TCP als dat niet lukt, neem ik aan.  In de “hoog” instelling staat dat ook niet. 

​@hmmsjan_2 Ik probeer met Wireshark te kijken wat er zoal vanaf mijn iPhone naar buiten gestuurd wordt als ik MijnKPN start en de instellingen van het modem ‘High’ level zijn. Nog niet met veel succes… Van wat ik te zien krijg lijkt er weinig zinnigs van het IPv4 adres te vertrekken en meer verkeer via IPv6 te verlopen, waar ik overigens nog geen kaas van kan maken...

Ik krijg helaas de KPN app niet aan de praat, dus ik kan het niet testen. Inloggen op een KPN telefoon en twee-factor authenticatie op een Kruidvat Nokia is blijkbaar te dol. Maar hoe doe je dat met Wireshark? 

​@hmmsjan_2 Ik monitor mijn wireless lan (in promiscuous mode op mijn Mac) en start dan de mijnkpn app. Daarna stop ik de capture en pas filters toe op de gecapturede packets.

Filteren op het ip4 adres van mijn iPhone levert weinig op. Filteren op de (3) ipv6 adressen die zijn toegewezen levert veel meer packets, maar daar zie ik niet zo 123 poortnummers in (in elk geval niet zoals in de ipv4 packets).

Maar dat kan toch niet?  Op de Mac komt alleen het verkeer voor het MAC adres van de Mac en van de telefoon zijn alleen IPv4 ARP’s en  de multicast van IPv6 neighbor discovery/router advertisements  e.d. te zien, wellicht nog wat MDNS en bonjour. Normaal IPv6 dataverkeer heeft dezelfde poortnummers als IPv4. Promiscuous kan volgens mij  niet overrulen dat Wifi associaties en ethernet switch poorten alleen relevant verkeer doorgeven, hooguit vroeger met onversleutelde WiFi. 

  Ik zat te denken aan VPN van telefoon naar Linux wireguard server en het verkeer op de wireguard interface te bekijken of een Wifi access punt te maken en door te sluizen naar een ander systeem. Maar goed, ik strand bij het eerste gebruik van de app...

​@hmmsjan_2 https://nl.m.wikipedia.org/wiki/Promiscue_modus

Dat zou dus alle verkeer op de wifi zichtbaar moeten maken op mijn mac.

(en ik zie ook meer dan alleen verkeer van/naar de mac)

Dat is correct, maar goldt dat niet in de tijd van ouderwets ethernet en  “cheapernet”, waarbij een coaxkabel van PC naar PC liep, i.p.v. de huidige structuur met ethernet switches die ervoor zorgen dat alleen relevant verkeer bij een host aankomt?  Hetzelfde voor Wifi. En als dat af te tappen is, is versleuteling overbodig….  

 En er altijd wel wat aan de hand op het netwerk, broadcast, multicast, IGMP, enz.

Filter eens in Wireshark op poort 443  en  browse flink op de telefoon.  Ik denk dat er niet veel van te zien zal zijn… 

​@hmmsjan_2 Hmmm, ik denk dat je gelijk hebt. Ondertussen heb ik wel gevonden hoe ik het kan doem (https://developer.apple.com/documentation/Network/recording-a-packet-trace) en gezien dat (indien ik de custom level rules gebruik) er aardig wat misgaat op een serie oplopende poorten.

als ik een regel toevoeg die voor het betreffende ip adres alles toelaat (poort 1-65535) dan werkt het wel, dus er IS een poort die geblokkeerd wordt...

Dat is het betere debugging werk, inbreken met een USB kabel in de telefoon netwerk omgeving. 

Een handige truc om 1-65535 door te laten. Je kunt dan ook nog kijken of TCP of UDP de boosdoener is.

Als het TCP is dan moet het met wireshark toch vrij gemakkelijk zijn om erachter te komen: Het is een uitgaande firewall, dus de bron is telefoon IP, en een TCP dialoog begint met SYN, gevolgd door SYN+ACK terug.Dit geeft als filter: 

(ip.addr==192.168.2.5) && ((tcp.flags==0x0012) ||(tcp.flags==0x0002))

Een doorgelaten verbinding naar een FTP server geeft dan:

332    125.573654653    192.168.2.5    145.220.21.40    TCP    74    50314 → 21 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=1051490794 TSecr=0 WS=128

333    125.580821530    145.220.21.40    192.168.2.5    TCP    74    21 → 50314 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=3663676467 TSecr=1051490794 WS=128

Na blokkeren van poort 21:

11    3.858786965    192.168.2.5    145.220.21.40    TCP    74    51516 → 21 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=1051678946 TSecr=0 WS=128

15    4.906345082    192.168.2.5    145.220.21.40    TCP    74    [TCP Retransmission] 51516 → 21 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=1051679994 TSecr=0 WS=128

In het rood een nieuwe SYN als TCP Retransmission. 

Mocht er een probleem met UDP zijn is het lastiger, dat is dan een UDP pakket zonder antwoord, dus dan rest niets anders dan “ip.addr==192.168.2.5 && udp” en kijken of er een pakket vertrekt zonder antwoord. 

​@hmmsjan_2 De truc om alles door te laten voor 1 ip adres heb ik al toegepast  😏

Volgens de test zit het probleem in TCP (zie de image, wat een deel is van de trace gesorteerd op destination). Veel retransmissions, variërend in source poort.

Een andere test (het openzetten van mijn iPhone ip voor poorten 32767-65535 blokkeert ook de mijnkpn app, wat ik enigszins vreemd vind omdat de source poorten uit de trace allemaal in die range zitten (en poort 443 ook toegestaan is, alhoewel ik niet weet of die er wel toe doet)

nog een testje met

werkt wel… hmm… het lijkt er op dat ik de rules niet begrijp…

Dat laat onveranderd dat als ik ‘high’ level rules kopieer naar ‘custom’ en de ene werkt wel en de andere niet, dat er wat ingesteld is in ‘high’ wat niet gedocumenteerd is…

Wat je laat zien zijn TCP verbindingen die opgezet worden van een willekeurige bronpoort naar poort 443. Dat zou dus ook web browsen moeten beïnvloeden. Bronpoorten doen er niet toe, alleen het NAT/connection tracking systeem moet netjes bijhouden welke inkomende poort even opengehouden moet worden om het antwoord van 443 naar die bronpoort door te laten.. 

Poort 443 zou dus zeker open moeten staan. Hier is alleen maar uit te komen door iemand die diep onder de motorkap kan kijken, of stand “hoog” op een of andere manier de firewall door elkaar gooit. Er mag geen verschil zijn tussen hoog en aangepast/alles blokkeren met de nodige regels gekopieerd.  

Port forwarding van 32767-65535 naar de iphone mag ook niet uitmaken, anders zou je nooit een systeem in DMZ (= alle poorten) kunnen zetten.

Dit is zonder toegang tot de systeem software van de router niet op te lossen.

​@hmmsjan_2 ok, alvast dank voor het meedenken. de poorten (32767-65535) was overigens geen port forwarding naar de iphone, maar de setting van een van de outgoing firewall regels. Anyway, ik kijk of ik een ‘router programmeur’ kan bereiken

vriendelijke groet,

peter

Tof topic, dank jullie beiden, ​@Peter Peters en ​@hmmsjan_2!

Paar opmerkingen van mijn kant:

• De poort 53 DNS die er twee keer instaat dat is een weergavedingetje. De 53 met alleen TCP zou er niet moeten zijn, maar deze doet ook niet daadwerkelijk iets, onder water.
• De nieuwe MijnKPN app werkt encrypted op een eigen poort, en wel nummer 8443. Dat is een bewuste keuze om het apart te houden van de webinterface. Maar dat is nog niet verwerkt in de firewall profielen. Dus dan zou je die poort expliciet moeten vrijgeven.
• QUIC hadden we er al in willen hebben, maar dat is nog niet gelukt. Gelukkig heeft dat protocol inderdaad fallback.

Deze dingen wordt aan gewerkt om dat in een/de volgende versie te verhelpen.

Poort 80 is eruit gehouden omdat we vinden dat dit ook niet echt bij een Hoog profiel hoort. Maar die kun je dan dus inderdaad zelf toevoegen.

En verder in het algemeen raden we ook aan om te doen wat jij al doet als je echt met Hoog als basis wilt gaan werken binnen het niveau Aangepast en tegen problemen aanloopt. Om dan dus met Wireshark en dergelijke te gaan uitvogelen wat er blijft hangen en wat je dan nog eventueel apart zou moeten vrijgeven. Dat is zo afhankelijk van welke programma's en diensten je gebruikt.

Die 8443 had dus in Wireshark moeten staan. Web browsen werkt, dus met de kennis van nu had  poort 443 weggefilterd moeten worden uit het Wireshark display. Waarschijnlijk geeft de server geen antwoord zolang de authenticatie via 8443 niet rond is??

Testen met Wireshark is natuurlijk prachtig, maar voor de gebruiker lijkt het me gemakkelijker als er een textbox  onder de firewall komt met de laatste nn   namen, adressen en poortnummers  die in het zwarte gat verdwenen zijn.  Ik neem aan dat dit wel ergens in de planning staat. 

KPN speedtest werkt ook niet in de stand hoog.

​@Erik van KPN Mijnkpn is niet de enige app die faalt helaas. Ik had ook last van b.v. dat mijn airco niet met WiFi wilde ‘connecten’ via de “AC cloud” app, en dat de video stream van mijn Ring deurbel niet werkt (zegt dat er geen verbinding is...). Die zijn wat lastiger met Wireshark te ‘debuggen’, of jij moet weten hoe dat mogelijk is.

Is er een overzicht van wat er in “High” allowed is, maar niet in de getoonde lijst op het modem staat? of is die lijst compleet? (en zo ja, waarom werken dan dingen niet in “Custom” als daarin dezelfde regels staan...)

Alvast dank voor het meedenken zover!

Gewoon de firewall op "Standaard" zetten. Ben je overal vanaf. Anders blijf je gezeur houden. Je moet zowat netwerkgeleerde zijn om de regels op "Aangepast" goed in te stellen. Vooral als je wat slimme apparaten in huis hebt enzo. Het is geen doen.

Ik snap wat dat betreft niet waarom KPN er überhaupt met gekomen is. Ik heb volgens mij de afgelopen jaren nooit vragen van klanten hiernaar op het het forum voorbij zien komen. Niemand heeft hier behoefte aan. Andere providers hebben het ook niet voor zover ik weet.

Denk het niet. Je zit zo aan de vele 100en regels in een paar minuten tijd. En het roept meer vragen op dan dat het ergens antwoord op geeft.