RCS with iOS18

Question

Hi All, Anyone else having issues with iOS18 devices connect to Sophos FW with Web Filtering set to 'Default Policy' and unable to send RCS messages to Android devices? 
 As soon as i turn off Wifi and force cell service, RCS works 
 As soon as i disable Web Policy, RCS works. 
 I am unable to see anything being blocked in LogViewer 'Web Filter' 
 Any suggestions? 
 
 Thanks 
 Mike

Michael Dunn · Accepted Answer

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.

Michael Dunn · Answer

Please read this KB article for the full information and final version of the steps to enable RCS for iPhones. support.sophos.com/.../KBA-000010020

Michael Dunn · Answer

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.

rfcat_vk · Answer

More than likely the application does not like MITM scanning. 
 Ian

Vishal_R · Answer

Hi Mike Richter One such instance investigation is ongoing with the Dev team with ID NC-143148 and I will keep you posted on the conclusion/summary around this based on the progress.

If you are switching to DPI from a Web proxy in the rule ID that is serving this traffic it should work fine as per current observations! Why it is failing with a web proxy that is still under investigation?

RCS with iOS18

Top Replies