01-02-2025 11:11 AM
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?
01-09-2025 11:52 AM
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
01-05-2025 06:26 PM - edited 01-05-2025 06:49 PM
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.
01-07-2025 11:12 AM
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.
01-09-2025 11:52 AM
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
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
