Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 44 subscribers
  • Views 1493 views
  • Users 0 members are here
Options
Suggested

RCS with iOS18

Mike Richter

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



Edited TAGs
[edited by: Erick Jan at 3:31 AM (GMT -7) on 3 Oct 2024]
Parents
  • +1

    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.

  • 0 in reply to Michael Dunn

    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

  • 0 in reply to Mike Richter

    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.

Reply
  • 0 in reply to Mike Richter

    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.

Children
Unfiltered HTML