RCS with iOS18

I do not have the equipment to test this myself so I am asking those who have this problem to attempt and reply back.


RCS uses both port :443 and :5223.

This problem is only observed when using the web proxy.  One possible cause is pharming protection, which can change the destination ip address.  In the sample log that I have seen the :443 and :5223 connections ended up going to different servers due to pharming protection.



Solution 1) NOT CONFIRMED
Go to Webadmin > Web > General Settings > Advanced Settings
Turn off Pharming Protection.
Make sure the phone is fully closed all connections.  For example turn off cell data plan, disconnect from the wifi, exit the messaging application, turn on wifi.
Then try RCS messaging again.  Please report findings here.
If it does not help please return the setting before Solution 2.


Solution 2)
Go to Webadmin > Hosts and services > FQDN host.
Add a FQDN wildcard host for *.telephony.goog
Note that FQDN wildcards watch for DNS requests to fill up the list of IPs.  This can take 5-15 minutes depending on the clients dns caching.  In order to give maximum time, disconnect and reconnect the phone now.

Make sure the phone is fully closed all connections.  For example turn off cell data plan, disconnect from the wifi, exit the messaging application, turn on wifi.

Create a high level firewall rule. Source LAN Destination WAN with that *.telephony.goog network.
Don't set anything in Web. It should go to DPI mode.

Try again.

Verify that the connection is now going through the new firewall rule and that it works.

Note:  You may be able to go to Log Viewer > Web Filter. Find the the log for telephony.goog. Look at what fwid is to see if it used the new firewall rule.  If the IP is not caught by the *.telephony.goog FQDN Host you can try waiting, or you could add an additional FQDN host for the specific phone carrier FQDN.

If it is using the correct rule and is going through DPI mode without working, and you have HTTPS decryption, add telephony.goog to your local TLS exclusion list.

I do not have the equipment to test this myself so I am asking those who have this problem to attempt and reply back.


RCS uses both port :443 and :5223.

This problem is only observed when using the web proxy.  One possible cause is pharming protection, which can change the destination ip address.  In the sample log that I have seen the :443 and :5223 connections ended up going to different servers due to pharming protection.



Solution 1) NOT CONFIRMED
Go to Webadmin > Web > General Settings > Advanced Settings
Turn off Pharming Protection.
Make sure the phone is fully closed all connections.  For example turn off cell data plan, disconnect from the wifi, exit the messaging application, turn on wifi.
Then try RCS messaging again.  Please report findings here.
If it does not help please return the setting before Solution 2.


Solution 2)
Go to Webadmin > Hosts and services > FQDN host.
Add a FQDN wildcard host for *.telephony.goog
Note that FQDN wildcards watch for DNS requests to fill up the list of IPs.  This can take 5-15 minutes depending on the clients dns caching.  In order to give maximum time, disconnect and reconnect the phone now.

Make sure the phone is fully closed all connections.  For example turn off cell data plan, disconnect from the wifi, exit the messaging application, turn on wifi.

Create a high level firewall rule. Source LAN Destination WAN with that *.telephony.goog network.
Don't set anything in Web. It should go to DPI mode.

Try again.

Verify that the connection is now going through the new firewall rule and that it works.

Note:  You may be able to go to Log Viewer > Web Filter. Find the the log for telephony.goog. Look at what fwid is to see if it used the new firewall rule.  If the IP is not caught by the *.telephony.goog FQDN Host you can try waiting, or you could add an additional FQDN host for the specific phone carrier FQDN.

If it is using the correct rule and is going through DPI mode without working, and you have HTTPS decryption, add telephony.goog to your local TLS exclusion list.

Hi Michael,

Thanks for the reply

Solution 1 - Solved the issue.

Solution 2 - Force all traffic using new rule, but didn't help.  It actually prevented RCS on Android devices. 
here is what the FW Rule looks like

I have confirmation from others that Solution 2 works.

As there is a lot of issues with DNS propagation time, Solution 2 might take a while before it works.

You could speed it up by looking in the Web Filter logs for telephony.goog.  Find out the specific FQDNs that the phone is using and create FQDN hosts (not wildcard) for those.  Add those to the rule.  But that won't be generic to all phones/carriers.


Root cause:

The problem with RCS is that some traffic is HTTPS on port :443 and uses the web proxy that has pharming protection.  Some traffic uses port :5223 that does not use the web proxy or have pharming protection.  Therefore some of the traffic the pharming protection is applied and changes the server while other traffic the server is not changed.

Most traffic (eg from a browser) only uses port 80 and 443.  Therefore the pharming protection is applied evenly.  But in this case because RCS also uses another port the pharming protection is uneven.

Some applications may not care if the traffic is split between two servers.  It appears that RCS cares.

I also have the issue and use DPI only, no web proxy. Just saying.

If someone has a phone they know works fine when not connected to wifi, but does not work behind the XG with DPI mode, and is willing to help test please DM me.  I'd like to look at config and capture debug logs.

I ended up decommissioning my sophos and went with Unifi Cloud Gateway Max. If you can't find someone, I could plug it back in for some testing for you.