Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 4 subscribers
  • Views 18071 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mobile Device Issues

DavidRojas

Hey all,

I'm fairly new to Sophos and firewalls in general (not my forte), and I've been scratching my head over something. 

Everything is set to pretty much default, plus a few URL filtering and Application Control tweaks, but I'm having trouble with an iPhone receiving gmail via the Apple Mail app. When the user switches to LTE, it works fine. On WiFi, it's not working.

For kicks, I created a firewall rule Any (Source) – Any (Service) – Any (Destination) – Allow (Action) but this did nothing. The phone still won't receive anything.

Thoughts? Point me in the right direction?

Thanks for taking the time to answer my newbie question!



This thread was automatically locked due to age.
Parents
  • 0

    So, by opening up your Firewall with Any - Any - Any you've ruled out that it's not the packet filter. 

    Though, it might be worth keeping a Firewall Port for Apples Push Service in there anyway:

    Name: Apple
    Type: TCP 
    Destination port: 5223 
    Source port: 1:65535

    Firewall Rule: 

    Sources: Internal (Network) 
    Services: Apple
    Destination: Any 
    Action: Allow 
    Comment: Apple  Rule 

    Moving onto the Proxy, if you add your iPhone's IP address into the "Skip Transparent Source" list under Web Protection --> Web Filtering --> Misc does it then work? If not, then the problem is likely not with the UTM. If it does, try creating an Exception skipping everything for that FQDN.

    courier.push.apple.com Is a known issue, not with the UTM but with itself. Lots of other Firewalls/Proxies have issues with that address because it simply is not resolvable. There's a lot to how Apple works in terms of DNS, it uses Akami. 

    "The applepushserviced first does a DNS TXT query for "push.apple.com" [ nslookup -query=txt push.apple.com] . This will return "count=50" or some number XX. The daemon then creates a name using a number between 1..XX and creates DNS name X-courier.push.apple.com. This DNS name is then handle by Akamai DNS to return an ipaddress in the 17.X netblock that belongs to Apple.

    Then, applepushserviced connects to a host on port 5223. These present a certificate for courier.push.apple.com, and only accept connections which present a client side certificate (retrieved in the previous step).

    Contrary to what port 5223 might imply, it uses a binary protocol which bears no resemblance to XMPP."

  • 0 in reply to itsfruity

    No luck...

    It doesn't seem to be Web Protection related, as I entered the device IP to be completely whitelisted (bypass blocking). One thing I noticed though, is if I use the Policy Helpdesk and hit say, "imap.google.com" it comes back as "Blocked" per the Base Policy. Reason: Host not found. 

    Would that have anything to do with it?

  • 0 in reply to DavidRojas

    If you've already skipped your Client IP from the proxy entirely than any Blocks based on policies wont matter.

    Are these devices using the UTM as their proxy as well? If so, you will need to setup a request route.

    If you change the devices to use Googles 8.8.8.8 DNS server instead does it then work? Google should be able to resolve the CNAME for courier.push.apple.com 

Reply
  • 0 in reply to DavidRojas

    If you've already skipped your Client IP from the proxy entirely than any Blocks based on policies wont matter.

    Are these devices using the UTM as their proxy as well? If so, you will need to setup a request route.

    If you change the devices to use Googles 8.8.8.8 DNS server instead does it then work? Google should be able to resolve the CNAME for courier.push.apple.com 

Children
  • 0 in reply to itsfruity

    I confess, I'm lost at "proxy." I don't recall configuring any sort of proxy setup in the firewall during installation or afterwards. So I'm not sure how to respond when you ask if the iPhones are using the UTM as their proxy as well... or how I would setup a request route. I seem to recall reading something about a request route from the DNS Best Practice post, but I don't have my own internal DNS, so I didn't know how to make that relevant. 

    I did setup DNS Forwarders to Google's 8.8.8.8 + 8.8.4.4 DNS Servers, but that didn't change anything. 

    This setup is basically default configuration with a few minor tweaks (adding specific web protection categories, etc). 

    My setup is the following, maybe this can help shed light on the issues:

    Comcast Cable | > Arris Cable Modem > Sophos UTM 9 Firewall > Arris Cable Modem/Router combo (set to use a routed connection w/DHCP disabled). 

    The router is broadcasting a 2.4 GHz and 5 GHz connection for WiFi.

    The Firewall's DHCP server is issuing IPs from 192.168.2.101 - 192.168.2.254 | The router's IP is 192.168.0.1 (would this be a problem at all? It doesn't seem to be since laptops and other devices get an internet connection).

    I'm new to networking, so forgive me if I've just demonstrated severe ignorance and stupidity ^ =)

  • 0 in reply to itsfruity

    Our UTM has an Availability group for Forwarders that lists 8.8.4.4, then 8.8.8.8 - yet courier.push.apple.com doesn't resolve.  Do you mean another FQDN?  That his real problem would be seen a line or two earlier in the log?

    Cheers - Bob

  • 0 in reply to DavidRojas

    The line from the Web Filtering (httpproxy) shows that the installation wizard configured Web Filtering based on your response during the initial setup.  It's certainly in Transparent mode, so the iPhones are also going via the proxy.

    "Comcast Cable | > Arris Cable Modem > Sophos UTM 9 Firewall > Arris Cable Modem/Router combo (set to use a routed connection w/DHCP disabled). " - This is certainly part of your problem.  If you can't put this in bridge mode, disconnect the Ethernet cable from its WAN port and connect one of its LAN ports to the UTM.

    Cheers - Bob