topic Re: RCS Chats from iPhone (IOS 18) broken in Next-Generation Firewall Discussions

RCS Chats from iPhone (IOS 18) broken

DrewNumberTwo — Thu, 02 Jan 2025 19:11:02 GMT

A fun problem got brought up that now that Apple surprisingly supports RCS (Google's SMS replacement) and for some reason it does not function on our networks.

I can see in our internet firewall that there is a TCP 5223 session to us.verizon.rcs.telephony.goog (216.239.36.131) from our test client. That session is valid, I have a 3way handshake, I can see the Server/Client Hello and it would appear from every piece of info I can see this should be working - yet it seems to not be able to send or receive RCS messages. There is no SSL decryption at play here.

Anyone seem this or dealt with it previously to have any clues about why this might be failing?

Re: RCS Chats from iPhone (IOS 18) broken

NeilG — Mon, 06 Jan 2025 02:49:33 GMT

Yep, i'm seeing this as well. Its being denied ( interzone-default) The RCS is indeed on TCP 5223 SSL for Iphone but appears only for initial handshake or something. Once rcs communication is successful, it then uses 443 for all communication thereafter. i'm going to assume you have a basic rule for internet outgoing with "application default" I believe this will block 5223 on ssl. Create a new rule allow tcp 5223 / ssl going to the noted IP. ((216.239.36.131) and for the devices required. I've tested this on my 440 and confirmed working.

Re: RCS Chats from iPhone (IOS 18) broken

DrewNumberTwo — Tue, 07 Jan 2025 19:12:15 GMT

We have a proxy in play which complicates things. We know there is SSL on 5223 and on 443 but are unsure which happens first. I theorize that the fact that the two ports would exit our network as two different public NATs may be the root of the issue at present.

Re: RCS Chats from iPhone (IOS 18) broken

DrewNumberTwo — Thu, 09 Jan 2025 19:52:07 GMT

In the event that anyone stumbles on this post here is what you need to know:
RCS uses 5223 than 443. If your internet data is going straight out the firewall that's fine you can get it working with SSL on those ports. If your org has some sort of proxy or other internet filtering service or split NATing that will send the data out for TCP 5223 via one Public IP and then something (like a proxy) grabs the TCP 443 and send it out a different way via different public IP it breaks. Solution is to fully bypass anything that makes these who data streams from the iPhone appear different.

destinations are *.rcs.telephony.goog & 216.239.36.131 - 134