I like the last one, I think having the status code in the body could help clarify where the error is coming from when traversing a reverse proxy.

You can call this ‘anticonservative’ all you want, but the hard truth is the ruling was only made possible because of who conservatives voted for in the first place.

A lot of negativity around Ubiquity in here, which is surprising to me, honestly. I had their USG for years and loved it, recently swapped it out for the Dream Machine and love it. Really don’t understand the complaints about linking it to the cloud. I just didn’t bother, everything works fine. Additionally, I managed to get a Debian container running on it and installed ntopng, it’s been awesome for getting realtime visibility into my network traffic.

E. I should add I have 6 of their switches and 3 access points, one of which is at least 7 years old and still receiving updates.

Seems like Twisted Metal meets Mario Kart.

Full tunnel would not mitigate this attack because smaller routes are preferred over larger ones. So, sure, 0.0.0.0/0 is routed over the tunnel, but a route for 8.8.8.8/32 pointing to somewhere layer2 adjacent, pushed via DHCP option 121, would supercede that due to being more specific.

The Killswitch only checks that VPN is up, not whether traffic is correctly routed over it.

You aren’t wrong, per se, I think you just don’t fully grasp the attack vector. This is related to DHCP option 121, which allows routes to be fed to the client when issuing the ip address required for VPN connectivity. Using this option, they can send you a preferred default route as part of the DHCP response that causes the client to route traffic out of the tunnel without them knowing.

E. It would likely only be select traffic routing out of the tunnel. I could, for example, send you routes so that all traffic destined for Chase Bank ip addresses comes back to me instead of traversing the tunnel. Much harder to detect.

Engineering is engineering. You design it, you build it, you test it. Engineering. We shouldn’t gatekeep words.

With that said, I recognize that certain engineering disciplines have overlap with public safety, and should come with some qualifications to back it up.

It probably has to do with being native ipv6 and needing to ride a 6to4 nat to reach the broader internet.

Start at 1400 and walk the MTU down by ~50 until you find stability, then id creep it back up by 10 to find the ‘perfect’ size, but that part isn’t really needed if you’re impatient. :)

E. I found 1290 was needed for reliable VPN over an ATT nighthawk hotspot.

Your VPN doesn’t have the ability to strip user agent strings on HTTPS requests, this doesn’t seem VPN related imo.

For what it’s worth, I did specifically say ecosystem because the TPM is just one component, which is required to authenticate the remote wipe. Also the drivers are installed automatically with most modern operating systems, it’s not like you install your own south bridge driver, for example. Linux of course notwithstanding.

I’ve seen it used successfully numerous times. Someone steals one of our laptops, rips the drive out, installs vanilla windows, and boom it reboots and performs a wipe.

Regardless, system-on-a-chip are just that, systems; they can absolutely make remote calls without user interaction, just as intimated by the comment you originally replied to.

That really isn’t entirely true anymore since the TPM ecosystem came into existence. I can remotely wipe any pc at my company even if it’s stolen and reformatted because a hardware chip will phone home the second a compatible os is installed and internet access is available.

deleted by creator

That makes sense! Believe it or not it’s actually easier for an ISP to block a whole country than select websites and services. We actually null route all Russian public IP space where I work, that would absolutely be plausible on a national scale as well.

It’s imperfect, you can get around it, but it catches 99% of normal users, which is the goal.

You are absolutely correct, I should have lead with that. Encrypted client handshake means no one can see what certificate you are trying to request from the remote end of your connection, even your ISP.

However, It’s worth noting though that if I am your ISP and I see you connecting to say public IP 8.8.8.8 over https (443) I don’t need to see the SNI flag to know you’re accessing something at Google.

First, I have a list of IP addresses of known blocked sites, I will just drop any traffic destined to that address, no other magic needed.

Second, if you target an IP that isn’t blocked outright, and I can’t see your SNI flag, I can still try to reverse lookup the IP myself and perform a block on your connection if the returned record matches a restricted pattern, say google.com.

VPN gets around all of these problems, provided you egress somewhere less restrictive.

Hope that helps clarify.

Yeah, even if they miss your DNS request, the ISP can still do a reverse lookup on the destination IP you’re attempting to connect to and just drop the traffic silently. That is pretty rare though, at least in US, mainly because It costs money to enforce restrictions like that at scale, which means blocking things isn’t profitable. However, slurping up your DNS requests can allow them to feed you false error pages, littered with profitable ads, all under the guies of enforcing copyright protections.

Most ISP blocking is pretty superficial, usually just at the DNS level, you should be fine in the vast majority of cases. While parsing for the SNI flag on the client hello is technically possible, it’s computationally expensive at scale, and generally avoided outside of enterprise networks.

With that siad, When in doubt, VPN out. ;)

Legit read this as ‘Dicktogram’.

QSFP and SFP are different physical connectors, they are not interoperable.

You will still be able to use them completely offline after you complete the setup process, it’s in the article. Regardless, I only have a couple devices, so it’ll be pretty painless for me to rip em out.