RCS with iOS18

More than likely the application does not like MITM scanning.

Ian

Anyway to find out which part and how to exclude? 

Create a firewall rule with web allow all, application allow all and ips lan to wan. Enable logging. With the web tick use web proxy to start, then try using dpi instead. Restrict access to your test pc.

the logviewer - web will alow you to see all parts of the access.

ian

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?

I have the same problem. Commenting so I get updated when this is resolved

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

Different person here, but I see the same issue: RCS works on cell, not on the firewall. I do not use the web proxy -- DPI only -- and am on v21 beta. Poking around, it does look like it wants to use QUIC and I block that.

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.