on 30-12-2025 21:40
VS EE CGNAT
Not that I expect this to change just posting this out there for all to read if O2 allows it
Here is why tracetcp is unless on O2 CGNAT
C:\tracetcp_v1.0.3>tracetcp grc.com:443
Tracing route to 4.79.142.200 [grc.com] on port 443
Over a maximum of 30 hops.
1 2 ms 2 ms 10 ms 192.168.255.247
2 3 ms 2 ms 5 ms 10.70.143.1
3 40 ms 30 ms 38 ms 10.182.21.3
4 48 ms 47 ms 52 ms 172.16.155.90
5 42 ms 39 ms 54 ms 172.25.254.163
6 Destination Reached in 44 ms. Connection established to 4.79.142.200
Trace Complete.
Whats wrong with that you say? It reached the Destination? Hold my beer!🍺
No in truth it did not so now your thinking but we can get to GRC right? Yes ...err so whats wrong? In no way can you get to GRC with that many hops let alone in 44ms!
So O2 CGNAT works like this its a proxy vs EE CGNAT that only changes the SNAT your IP and source port along with MSS which of course I'm fine with but O2 you just just had go one step more didn’t you! Not only do you change SNAT your IP and source port along with MSS but the TCP timestamp and sequence number alone with how it works which is I send a SYN but that SYN never makes it to me then I get a SYN ack which I never sent because I didn't get a SYN I send a ACK then the O2 CGNAT proxy sends a SYN to do the handshake so that data flows under the CGNAT proxy session that was made.
Terrible
And yes I get why you might be doing this to stop SYN floods in a simple way but does not really work.
on 30-12-2025 21:45
If I remember you brought up something similar two years ago.
I'm wondering why you have stuck with O2 if that's the case.
on 30-12-2025 21:58
So I did guess my mind is slipping.
I use it as a backup
I'm not sure how many other providers do this or if its unique to O2 the reason I brought up again was a idea I had to do with SYN floods at cloud servers to which a device uses a unique TCP timestamp as Authentication that the cloud has a database of .... but O2 CGNAT would brake this.