Hoeveel TCP/UDP connecties gebruikt de gemiddelde telefoon?

[knutsel smurf]

Mijn vraag is redelijk subjectief maar ik ben op zoek naar een veilige methode om te berekenen hoeveel devices ik achter 1 publiek IP kan zetten met NAT.

Ik heb maximaal 65K aan TCP/UDP connecties per publiek IP. Wat dan de vraag doet opkomen hoeveel connecties gebruikt de gemiddelde telefoon of tablet?

Nu heb ikzelf eens gekeken bij mijn eigen telefoon en kom ergens rond de 150 connecties die hij opzet als ik een beetje actief ben. Hierbij moet je denken aan 10 tot 15 actieve applicaties op mijn S7. Voor een PC is dit ongetwijfeld hoger, echter in mijn situatie komen er vrijwel alleen Iphones en androids op het netwerk.

Maar of ik nu de maat staaf ben voor de gemiddelde gebruiker vraag ik me af dus op dit moment ga ik er vanuit dat als ik reken met 100 actieve connecties per device dat ik redelijk safe zit. Echter ik kan nergens vinden of deze aanname eigenlijk ook wel goed is.

Als iemand hiervoor een richtlijn heeft of een website weet waar ik kan opzoeken hoeveel connecties bepaalde applicaties gebruiken dan zou dat zeer welkom zijn.

Hoor graag hoe jullie dit vraagstuk zouden berekenen.

[ik222]

Sowieso kun je veel meer dan 65k NAT sessies per publiek IP hebben. Dit omdat het destination IP meegenomen wordt in de NAT hash. Enkel de combinatie tussen source en destination moet uniek zijn. Dus ja er is wel ergens een limiet maar die zal in de praktijk veel groter zijn dan 65k connecties per publiek IP als het gaat om standaard internettoegang.

Voor wat betreft aantal connecties hangt dat inderdaad echt heel erg af van het gebruik. Een CGN opstelling met huisaansluitingen is heel wat anders dan een evenement opstelling waar enkel smartphones en een wat laptops gebruik maken van de WiFi.

Als het voor een grooot project is dan lijkt een pilot me de beste optie. Daarin kan je dit soort dingen goed monitoren.

[ Voor 3% gewijzigd door ik222 op 29-05-2017 20:51 ]

[knutsel smurf]

Het is idd voor een groot project met meerdere evenementen op 27 verschillende locaties waarvan er waarschijnlijk 3 of 4 maximaal tegelijk zullen zijn.

Mijn centrale fortinet firewall geeft aan dat er een limiet is van 65k sessions per publiek IP. Nu is het geen probleem om een groot subnet te regelen maar ik moet wel een logische beredenering kunnen maken met hoeveel ip adressen ik per locatie nodig heb. En dus mijn vraag, waar ik rekening mee moet gaan houden.

Helaas kan ik niet zomaar pilot doen want ik kan nergens 120k users/devices vinden om dit goed te kunnen testen.

[CyBeR]

Ja daar is geen peil op te trekken natuurlijk. Als ik idle ben heeft mijn iPhone 4 connecties open, maar zodra ik een refresh op nu.nl doe 54. Het ligt dus alleen maar aan hoe actief je gebruikers gaan zijn.

Als je fortinets niet fatsoenlijk op schaal kunnen NATten is 't tijd om ze te vervangen door iets wat dat wel kan imo. 65k sessies per IP is jaren '90 werk.

[TommyboyNL]

Ik weet niet wat voor Fortigate jij hebt draaien, en met welke software versie, maar 5.4 kan gewoon meer dan 65k sessies hiden achter 1 IP: http://help.fortinet.com/... sessions when NATing.htm , zie onderaan "Calculations for possible session numbers".

[knutsel smurf]

CyBeR schreef op dinsdag 30 mei 2017 @ 00:12:
Ja daar is geen peil op te trekken natuurlijk. Als ik idle ben heeft mijn iPhone 4 connecties open, maar zodra ik een refresh op nu.nl doe 54. Het ligt dus alleen maar aan hoe actief je gebruikers gaan zijn.

Als je fortinets niet fatsoenlijk op schaal kunnen NATten is 't tijd om ze te vervangen door iets wat dat wel kan imo. 65k sessies per IP is jaren '90 werk.

Klopt er is idd geen pijl op te trekken dus dat is ook een beetje de reden dat ik op zoek ben naar een veilige methode om het te berekenen. Ik wil niet een /25 aanvragen en dan tot de conculsie komen dat ik een groter subnet nodig heb.

Ik plan de FG-3000 te gebruiken hiervoor en die support in principe voldoende sessies in totaal. Echter het advies van de consultant hier is niet meer dan 65.500 sessies per publiek IP te gebruiken.

De vraag is dus zit ik safe met bijvoorbeeld 50 sessies.

"@TommyboyNL Ik heb even gekeken naar de berekening daar maar die laat mijns inziens alleen maar zien wat het verwachtte aantal sessies kan zijn. Zowiezoo kan ik niet met 1 IP alles doen omdat ik op verschillende locaties tegelijkertijd devices actief ga hebben. En de overheid hier in Ierland geeft aan dat ik per locatie minimaal 1 public IP nodig heb.

[ Voor 24% gewijzigd door knutsel smurf op 30-05-2017 11:40 . Reden: miste de post van TommyboyNL ]

[ik222]

knutsel smurf schreef op dinsdag 30 mei 2017 @ 11:20:
[...]


Klopt er is idd geen pijl op te trekken dus dat is ook een beetje de reden dat ik op zoek ben naar een veilige methode om het te berekenen. Ik wil niet een /25 aanvragen en dan tot de conculsie komen dat ik een groter subnet nodig heb.
Ik plan de FG-3000 te gebruiken hiervoor en die support in principe voldoende sessies in totaal. Echter het advies van de consultant hier is niet meer dan 65.500 sessies per publiek IP te gebruiken.

Dat is alleen een zinnig advies als het realistisch is dat alle aangesloten clients tegelijk dezelfde website of service gaan gebruiken. Ik kan me namelijk absoluut niet voorstellen dat deze Fortigate echt de limiet van 65k sessies per publiek IP heeft, die kan echt wel zinnig NAT met een destination ip / poort in de hash.

De vraag is dus zit ik safe met bijvoorbeeld 50 sessies.

"@TommyboyNL Ik heb even gekeken naar de berekening daar maar die laat mijns inziens alleen maar zien wat het verwachtte aantal sessies kan zijn. Zowiezoo kan ik niet met 1 IP alles doen omdat ik op verschillende locaties tegelijkertijd devices actief ga hebben. En de overheid hier in Ierland geeft aan dat ik per locatie minimaal 1 public IP nodig heb.

Je gaat dat echt alleen weten door te meten, maar om wat te roepen zou ik zelf bij een evenement opstelling denk ik rekenen met 100. Ook omdat steeds een deel van de clients idle zal zijn.

[knutsel smurf]

@ik222 je hebt een goed punt, het is inderdaad de verwachting dat veel bezoekers veel dezelfde sites gaan bezoeken. Ik zal eens nagaan bij deze sites wat hun limiet is als er veel bezoekers vanaf 1 IP komen.

[Verwijderd]

Even los van hoeveel IP's je precies nodig hebt raad ik je aan de IP reeks ruim van te voren te regelen en de WHOIS zodanig aan te passen dat het daadwerkelijk als een aparte reeks wordt gezien. (En niet als een subnetje van een veel grotere reeks.)

Waar ik zelf regelmatig tegenaanloop met kleine IP reeksen is dat Google of andere websites ze blokkeren en/of achter captcha's stoppen omdat iemand anders in de grotere reeks (waar mijn reeks binnen valt) heeft lopen spammen of op andere manier oneigenlijk gebruikt heeft gemaakt van z'n IP adressen. Niet iets wat je last-minute tijdens een festival wilt oplossen.

Wat aantal sessies betreft: ik zou de hoeveelheid sessies per client beperken. Je kunt de effecten daarvan vrij eenvoudig testen. Waarschijnlijk heb je aan 1 Android en 1 iOS client voldoende. Vervolgens kun je met dat getal gaan rekenen. Die beperking zorgt er ook meteen voor dat een enkele client met malware niet je hele sessie-tabel vult of een firewall van Google/Facebook/etc. triggered.

Last but not least: Google, Facebook, Netflix, etc. gaan bij voorkeur over IPv6. Er zou je eigenlijk niets in de weg moeten staan om elke festival bezoeker een uniek IPv6 adres te geven. Daarmee vermijd je voor deze bekende apps/sites in elk geval eventuele limieten.

[ik222]

knutsel smurf schreef op dinsdag 30 mei 2017 @ 15:54:
@ik222 je hebt een goed punt, het is inderdaad de verwachting dat veel bezoekers veel dezelfde sites gaan bezoeken. Ik zal eens nagaan bij deze sites wat hun limiet is als er veel bezoekers vanaf 1 IP komen.

Los van de sites zelf is dat dan ook technisch aan jou kant een valide reden om het aantal clients per publiek IP te beperken. Want je kan wel maximaal 65k sessies naar poort 80 van hetzelfde IP opzetten vanaf het zelfde (publieke) source IP, immers destination IP en poort is dan overal hetzelfde dus kan je enkel nog met de source poort een unieke hash genereren.

En inderdaad wat tweatbook zegt, IPv6 kan je veel NAT sessies schelen als je ISP dat kan aanleveren.

[johnkeates]

Je kan de software wissen en pfSense installeren, dan kan je zo veel sessies draaien als je maar wil tot het geheugen op is... Of zelfs met OpenWRT kan dat nog.

[ Voor 12% gewijzigd door johnkeates op 30-05-2017 16:39 ]

[jvanhambelgium]

knutsel smurf schreef op dinsdag 30 mei 2017 @ 11:20:
[...]
"@TommyboyNL Ik heb even gekeken naar de berekening daar maar die laat mijns inziens alleen maar zien wat het verwachtte aantal sessies kan zijn. Zowiezoo kan ik niet met 1 IP alles doen omdat ik op verschillende locaties tegelijkertijd devices actief ga hebben. En de overheid hier in Ierland geeft aan dat ik per locatie minimaal 1 public IP nodig heb.

En hebben die verschillende sites dan *elk* een eigen breakout ? Of aggregeer je ergens en kom je wel degelijk slechts op fysieke plek via een Fortinet naar buiten ? Daar zou je dan een kleine pool publieke IP's kunnen voorzien.
Ik zie geen probleem, die link geeft aan dat het best schaalbaar is en kan je wat berekenen.
Mischien eerder zorgen maken over de algemen performantie van al je clients ten velde (wireless)

Indien je denk dat veel bezoekers naar dezelfde site(s) gaan eventueel iets van reverse-proxy voorzien ?
(vb nginx maar nog héél wat andere opties) want die kan ook een enorme boost geven. Je kan de Fortinet ook als Reverse Proxy overwegen, maar dat is mogelijks niet optimaal...

[knutsel smurf]

@jvanhambelgium De site geeft idd aan dat het schaal baar is en dat ik een fortinet firewall heb die alle sessies aan kan.
Het plan is nu dat we een publiek /25 aan vragen die als pool op de centrale locatie komt. Ik heb gister gesproken met 3 van de 6 site beheerders welke veel bezocht gaan worden en die ook apps hebben. en die geven aan dat ik beter met 100 sessies kan rekenen, de reden is dat er veel real time data verstuurd kan worden en dus de sessies niet afgebroken worden als de data geladen is.

En wellicht is een reverse proxy geen slecht idee mocht in de toekomst blijken dat dit nodig is.