XMPP Service Operators - 2025-09-04

icebound.dev, The secret is that I don't have native IPv6.

However IPv6 is required nowadays and is so much better then IPv4.

my WAN connection is a shared L2 segment across an entire apartment complex. The provider is shady af and only provide IPv4 cgnat, but you wouldn't want to even use that directly as they hijack all UDP/53 and not only that but they for some illegitimate reason strip dnssec signatures from all dns responses.

What we do is setup IPSEC tunnels to a VPS somewhere with a publicly reachable IPv4 address and a IPv6 range and route v6 ranges over the IPsec established tunnels.

We can also setup low latency direct routes by setting up ipsec tunnels through the L2 segment via fe80:: link-local addressing

the legacy compatibility it served by nat64 on the cloud router/firewall and a reverse proxy

This has the added benefit of also being able to do traffic shaping such as FQ_Codel on the downlink for both sides of the connection.

Then, ounce that is setup all we have to worry about for the server and consumer side is setting up our IPv6-only network

The biggest concern is configuring our firewall/routers to prevent egressing anything unprotected or unencrypted onto the shady megacorp ISP's network

From the scummy megacorp ISP trying to tamper with traffic this is all they see:

``` 12:07:55.445748 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0xaaf43867 seq 3853796 len 504 [tos 0x4] 11:07:55.445873 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0xaaf43867 seq 3853797 len 504 [tos 0x4] 11:07:55.446019 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0xaaf43867 seq 3853798 len 504 [tos 0x4] 11:07:55.446140 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0xaaf43867 seq 3853799 len 504 [tos 0x4] 11:07:55.448769 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0x2aaddd65 seq 1585303 len 104 11:07:55.449071 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0xaaf43867 seq 3853800 len 632 [tos 0x4] 11:07:55.449189 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0xaaf43867 seq 3853801 len 632 [tos 0x4] 11:07:55.456632 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0x2aaddd65 seq 1585304 len 104 11:07:55.456936 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0xaaf43867 seq 3853802 len 632 [tos 0x4] 11:07:55.457037 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0xaaf43867 seq 3853803 len 632 [tos 0x4] 11:07:55.464692 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0x2aaddd65 seq 1585305 len 112 11:07:55.464812 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0x2aaddd65 seq 1585306 len 104 11:07:55.464813 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0x2aaddd65 seq 1585307 len 104 11:07:55.464815 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0x2aaddd65 seq 1585308 len 104 11:07:55.464817 172.red.act.ed.4500 > 172.red.act.ed.4500: udpencap: esp spi 0x2aaddd65 seq 1585309 len 104 ```

The great thing about using IPsec over Wireguard is that you'll notice TOS bits are preserved in the headers for classification of timing sensitive packets, this also means ECN should continue to work through a tunnel, ability to use standard encryption such as AES256GCM12+ECP384 which is what the NSA recommends to their own network engineers to secure their networks which means you can get a very high level of security while also using low power hardware by taking advantage of hardware acceleration such as AES-NI, and lower overhead then WireGuard. This also means (depending on your ipsec implementation and version) that every packet transiting the shady ISP's network is not only encrypted but also authenticated, has replay protection, and is using ephemeral keys for perfect forward secrecy.

If you used to use IPsec in the past but haven't in a while it is really worth taking another look. So much has changed since the original and second versions in the 90s. We are on ipsecv3 and IKEv2 now. The AH header has been completely deprecated and we only use ESP now. That only existing because of US export laws on strong cryptography. IPsecv3 with ipsec is built into the specification of IPv6 and uses the IPv6 extension headers! It was originally planned that IPsec would be a MUST be implemented part of the IPv6 spec but was later changed to SHOULD. This means great support. The standards even worked out standard ways to solving problems for less then ideal networks such as cg-NAT transition, MOBIKE, and special extensions for dealing with tunnels over legacy networks that do not handle fragments properly.

IPSec ? god have I time traveled to the ancient past?

The only big thing is that you have to have a router that is capable of enforcing policy based maximum MSS per route as unlike Wireguard that isn't handled by IPsec itself.

are there reasons not to just use wireguard ?

Yes

all the reasons above

also IPsec now even has multihoming and mobility transitioning. The killer-feature ounce only coveted by WireGuard

https://datatracker.ietf.org/doc/html/rfc4555

You can use IPsec on your road warriors too.

secondly, Wireguard can only offer a 128-bit equivalent encryption level.

your claim that IPSec is faster or lower power is probably wrong

moparisthebest, a hardware ASIC implementation is always going to be better then a software implementation. If you have AES-NI, you can use it and less uncore needs to be spent on the general purpose regions of your cpu

The only thing that seems possibly true is the difference in TOS bits, which for sure wouldn't be worth all the footguns and downsides

moparisthebest, how about a larger MTU?

inside the tunnel

> moparisthebest, a hardware ASIC implementation is always going to be better then a software implementation. completely untrue generally, even more so with totally different algorithms

your welcome to do your own testing, but with use of standard encryption algorithms you can then make purchasing decisions for the performance of it's AESNI or SHA2 performance.

https://www.wireguard.com/performance/ are benchmarks where AES-NI was used and it's still much slower, over 20%

Also if your targeting a more the minimum-required security level, DJB's crypto just usn't going to cut it

what? lol djb's crypto is literally state of the art, everything is migrating to 25519 etc because it's so much better and more trustworthy

moparisthebest, That testing configuration is with a third generation intel laptop cpu, not a modern embedded cpu

cool well I'll wait for your benchmarks then, or can you link any at all yet?

curve25519 only targets a minimum 128-bit equivalent security level. It's literally pointless to use it with aes-256 in any counter mode.

also your trusting all your information security to one guy

rather then NIST, NSA, and DOD

yes one proven cryptographer proven by many others to be consistently right always, vs shady govt orgs who's literal job is to subvert encryption

who have been caught subverting encryption over and over

which, if you want to target the minimum required security level, that's uh... legally speaking fine and probably won't hold you negligent for anything, but time has shown us that again and again that the minimum required security level is usually not enough to withstand the advertised lifetime of secrecy

the NSA publicly releases what they recommend for their own internal federal use as a standard, and it's higher then the minimum security spec recommended by NIST and the department of commerce for ""industry"" use.

the NSA isn't going to sh*t where they eat.

the biggest concern I think over the use of ECP384 instead of a djb 25519 based curve is what happens when you run out of entropy. But that's manageable and most modern hardware included embedded cpus include a built in TRNG or RRDRAND function and if yours doesn't you can always supplement it with an external entropy source

but modern IPsec implementations can also utilize ephemeral keys for perfect forward secrecy so the risk of that is reduced.

https://media.defense.gov/2020/Jul/02/2002355501/-1/-1/0/Configuring_IPsec_VPN_UOO148260_20_V1_2..PDF

https://www.nist.gov/publications/guide-ipsec-vpns

Feel free to read between this lines between these two.

their using more or less the same algos but at different minimum security levels.

the NSA retracted suite B and it shows that they are targeting a 256 level rather then nist's 128 recommendation.

If your implementation allows it, maybe you could use GCM-12 mode instead of CCM

or even OCB mode

https://soatok.blog was a useful resource in understanding the implications of each choice of cryptographic primitive, their application, and use in combination with each other.

specifically this page https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/

And I didn't want to use any RSA in this design in favor of modern ECC

While the Edward curves do offer more sidechannel protection, it is my understanding that targeting a 256 bit security level also mitigates effects of side channel attacks to a degree such that if one is found and used and lets say for example 40 bits of security are able to be defeated or bypassed, there's a lot of bits left to break before such a side channel exploit can be meaningfully used to cause any damage.

I would be more interested in taking a look at usage of Edward curves again ounce Ed448 becomes more widely available and battle-tested. At the time Ed448 was not implemented in the software I use.

It would be easy for me to regenerate my root identities based on Ed448 instead of P-384 ounce availability and testing becomes more widespread. Until then, while P- curves were scary in the early days (when Windows XP was relevant) that's no longer the case as much. So much so that the Electronic Frontier Foundation has adopted P-384 for their root identities as well for their IRSG root and subordinate identities: source: https://letsencrypt.org/certificates/ ✏

There has also been recent work on proving the parameter choice safety of P-384 and similar. Even if some of this turns out not to be the case I'm not using the bare minimum required security level so there's headroom for mistakes.

Regarding encipherment itself rather then signatures I don't see a real benefit to using chacha20 over AES in galois counter w/ a 12 bit IV or offset codebook mode. My understanding is the only reason we don't see more widespread adoption of OCB mode is due to some patent issues in 2011 which are no longer the case.

Especially when a hardware accelerator is built into every modern CPU that is there to use for free.

There's a lot less interrupts and context switches on the CPU when hardware offload is there.

So much so that the Electronic Frontier Foundation has adopted P-384 for their root identities as well for their IRSG root and subordinate identities: > source: https://letsencrypt.org/certificates/ If it's good enough for the Electronic Frontier Foundation and the NSA, DOD, NIST, and the federal government it's probably good enough for me.

I'm trying to protect myself from shady megacorporate internet service providers, random hackers on the internet, local/state level lea, and every joker who wants to tap a cable. Not special forces and blacksite operatives. ✏

The craziest thing is that ounce I deployed IPsecv3 in tunnel mode my average latency went down instead of up by a significant amount which suggests the shady ISP was doing something nefarious to the line that their aren't doing to ESP packets. ✏

All the more reason to protect packets traversing 'unprotected networks' which is what the public internet is!

ISPs, as well as routers, do QoS these days, which likely explains your latency phenomena.

https://soatok.blog author is super wrong on everything, I'd do the opposite of whatever is written there

> The craziest thing is that ounce I deployed IPsecv3 in tunnel mode my average latency went down instead of up by a significant amount which suggests the shady ISP was doing something nefarious to the line that their aren't doing to ESP packets. https://en.wikipedia.org/wiki/Net_neutrality ↺

マリウス, what do you think their specifically to do?

tom: exactly what based posted

why would ipsec-nat-t udpencap be prioritized over ICMP or other udp based traffic by the isp? ✏

also, technically it isnt QoS, as QoS is requested by the client, this is probably traffic shaping (https://en.wikipedia.org/wiki/Traffic_shaping)

QoS would be like a VOIP application requesting priority over normal traffic like downloads for a smoother experience

> https://soatok.blog author is super wrong on everything, I'd do the opposite of whatever is written there doubt, where's your source or anything backing up this argument?

some ISPs use IPsec connections to the router/modem hardware in your home, for example. In many regions they hence block the common ports from being port-forwarded, as they require them for doing remote admin on the subscribers' devices.

soatok is kind of an idiot tho, he basically claimed in his omemo thing that larger keys are better in every case, when in reality theres a point of diminishing returns

>> https://soatok.blog author is super wrong on everything, I'd do the opposite of whatever is written there > doubt, where's your source or anything backing up this argument? tom: https://www.moparisthebest.com/against-silos-signal/ ↺

It might be that they want these connections to have preference over anything else, so tgat even when your line goes titanic they still have a chance to connect

the blue furry just gets excited over big numbers ✏

> > https://soatok.blog author is super wrong on everything, I'd do the opposite of whatever is written there > doubt, where's your source or anything backing up this argument? their blog isn't proof enough? Jurisdiction isn't important for example? Are you kidding me? ↺

マリウス, so if I understand what your saying, you think the ISP is intending to prioritize their own ipsec tunnels for remote administration purposes but my traffic also happens to blend in enough to have that same prioritization applied to my tunnels?

https://soatok.blog/2025/08/27/its-a-cold-day-in-developer-hell-so-i-must-roll-my-own-crypto/

biggest piece of proof he is stupid

> the blue furry just gets excited over big numbers The section on P-521 seems to contradict that.

wireguard's author said before that rolling your own crypto is a bad idea without a massive team of cryptographers and security experts

tom: it is an explanation, correct. It might be something completely other, though. Hard to tell as ISPs aren't forced to disclose any shaping (yup, QoS was probably the wrong term here based).

Plus omemo does kinda suck for the use cases it's intending to protect against. Most implementations provide no way to delete your device key material should you suspect a key compromise, but that's a seperate issue.

gajim lets you delete them iirc

マリウス, I looked up the hardware vendor of the gateway router on the ISP's network and that router's marketing material boasts about having lots of ""lawful intercept"" capabilities ✏

lol

tom: not sure what to make of that. Everything an ISP is running can be used by law enforcement to intercept. It's literary designed that way.

yeah, you should use a second router behind the isp provided one in dmz, or your own (if possible)

that is, if you want them to not be able to do that

The router manufacturer's intended customer is hotel chains and operators in countries with facist internet surveillance laws

Unless they picked up that router by chance, it seems like they've gone out of their way to pick a vendor that makes it easy to spy on their tenants. ✏

with options like 'record every 500th packet to disk'

anyone who recommends Signal over XMPP isn't worth listening to, full stop

> your claim that IPSec is faster or lower power is probably wrong indeed both is wrong, wireguard trumps ipsec considerably ↺

ipsec however is more feature rich, but on the other hand, don't configure it properly, you are open to attack

wireguard is simple and hard to fuck up

moparisthebest, were you reelected as council member?

XSF member sorry

wireguard is small, simple, faster and more secure than IPSec, and trustworthy and can't be misconfigured unlike IPSec... but I ain't your mom do what you want

I'm not running my routers on a third generation Intel laptop cpu, and I'm not targeting the 128 bit security level so those benchmarks are irrelevant to me.

Using a End Of Life (EOL) cpu that isn't even remotely close to being supported by the vendor for microcode updates is also questionable

all of my devices run wireguard 24/7: phones, OpenWRT routers, rpis, desktops, laptops, and servers. It's many times faster than even lan speeds on all of them

Your not listening to anything I'm saying.

> Using a End Of Life (EOL) cpu that isn't even remotely close to being supported by the vendor for microcode updates is also questionable most, if not all, security implications of EOL CPUs are mitigated on an OS basis ↺

also trusting the hardware is not the greatest idea either, you have no clue what the hardware is doing, so don't trust its keeping you secure.

obviously running EOL should be avoided, but its not like you are instantly pwned if you do...

Wireguard only protects to the 128 bit security level using cryptographic algorithms that have no secure hardware implementations drafted up by a single guy. Should anything be found wrong with any constituents of this configuration an entire incompatible protocol revision would have to be re-implemented across all OS and hardware vendors at the same time before the issue can be fixed.

Wireguard also has more packet overhead then IPsec can be configured for. That means less efficient network traversal

wireguard is not simply one guy anymore, in development it was, but now it has many *many* eyes on it, it has kernel support in Linux, FreeBSD and OpenBSD and maybe more which I am not aware of

anyways this is noisy and OT

The public internet often limits you to 1500 bytes or less. Commonly much less. You have to make the most out of that as you can. ✏

icebound.dev, I'm talking about Daniel J Bernstein

Which, bless him for his incredible work but he's still just one guy.

And we are not living in the iron curtain of the 1990s cryptography export regulation anymore.

But to round this back to the original point, You too can have IPv6 at least internally for a very small cost. It should not longer be considered a privilege to deploy IPv6 only networks. IPv6 native sure, and only because of the incumbent providers who don't have to compete as much. But modern networks like Starlink are IPv6 native first with IPv4 only available as a fallback via legacy transition technologies if at all. ✏

On meager hardware too securely, if your hardware has hardware offload.

> Wireguard only protects to the 128 bit security level using cryptographic algorithms that have no secure hardware implementations drafted up by a single guy. Should anything be found wrong with any constituents of this configuration an entire incompatible protocol revision would have to be re-implemented across all OS and hardware vendors at the same time before the issue can be fixed. Right, no negotiation, full replacement. ie the correct way to design security critical protocols after decades of doing it the wrong way with TLS and IPSec and friends. ↺

you'll notice TLS 1.3 is the same, removed *countless* knobs and choices that even 1.2 had that make 1.2 insecure now.

well yeah when it comes to security, less is more

No it does not. TLS1.3 includes three ciphersuites as they recognize the need for fallback ciphers and implements new knobs for 0-RTT and ESNI

and IKEv2 is different from oakley IKEv1

so is ipsecv3 different from 2 and 1

As TLS versions are a big topic the last days: The latest development version of https://xmpp-dns.mdosch.de prints the used TLS version. :)

> As TLS versions are a big topic the last days: The latest development version of https://xmpp-dns.mdosch.de prints the used TLS version. :) cool! ↺

https://files.mdosch.de/upload/068b9f3b-8719-74b4-b508-cec483f0a414/2025-09-04-221639_grim.png

BTW, MattJ is it possible that tls11.badxmpp.eu and tls1.badxmpp.eu are not operational? > SEND: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> > RECV: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>( > 2025-09-04 22:18:59 connect: failed to connect to server: starttls handshake: EOF ✏

Oh, RECV: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>*(*

> As TLS versions are a big topic the last days: The latest development version of https://xmpp-dns.mdosch.de prints the used TLS version. :) works well, thanks ↺

testssl.sh is also a great way to go more in-depth when auditing your server's TLS. the latest versions support xmpp starttls

it is available in the devuan and FreeBSD repositories