Hello fellas,
Trying to verify if the reason push notifications from FAC (5.3.0 232) using FortiTokens (mobile) is not working is because the FAC interface is a private address and only gets NATed outbound with a PAT? Does it require a static 1 to 1 NAT so it can be reached from the internet? As no inbound connection can be initiated from the internet in its current configuration. I can't find any info on this regarding the FAC, but the instructions for Fortitoken mobile configured directly on a Fortigate says the outbound interface needs to be 'reachable from the internet.'
Any help would be greatly appreciated.
Thanks in Advance
Noel
Cheers!
Noel
Solved! Go to Solution.
Hi Noel,
not sure about Android, I do not own any, but for Apple iOS devices paired with FortiToken Mobile, there all starts with DNS query from FAC for A record of gateway.push.apple.com. Where result shows ~8 IP addresses in my case, but I do guess the Apple will load balance that and for the purpose it seems to be done via Akamai network (as original name is CNAM to gateway.push-apple.com.akadns.net).
Port on FAC is always 443.
But in FAC GUI : System / Administration / System Access / you can set "Public IP/FQDN for FortiToken Mobile:" to outer IP and port. This is NOT a port/IP on FAC itself, but it allows you to define IP:port on outer NAT router which is capable to do DNAT/VIP to translate this publicly accessible IP:port to IP on FAC and port 443.
VIP/DNAT destination IP on the FAC side should be one on interface (like port1) where you do have "FortiToken Mobile API (/api/v1/pushauthresp, /api/v1/transfertoken)" turned on in FAC GUI : System / Network / Interfaces / Interface Status / Access Rights / Services.
Because, FAC sends message to push notification service on Appple/Android side, with data whom to notify and where to send response! This is the place from where your mobile platform get idea where/how to respond when you Approve/Deny push request. That's that "Public IP/FQDN for FortiToken Mobile:" !
Communication (Approval/Deny) between FortiToken Mobile app on mobile device and FAC is also encrypted with TLS 1.2 (at the moment).
I'm not sure I do understand the question about SSL, but .. 1. FAC queries DNS who is notification server gateway.push.apple.com 2. FAC get some responses and choose first A record for gateway.push.apple.com
3. TCP TLS ver 1.2 handshake starts with that server and FAC is sending Client Hello
4. TLS handshake continues as usual with Server Hello, Certificate, Cert Request and Server Hello Done
5. FAC follows to complete build of certificate signed channel and when Change Cipher Specs are exchange the tunnel is built 6. notification data sent to Apple, which makes them popping-up on your mobile device display
... So, yes, communication with notification center IS signed by certificates and TLS encrypted.
EDIT: 2019-07-30 - to add details about port 443 on FAC
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
Hello Noel.
Have a look into System/Administration/SystemAccess/Public IP/"FQDN for FortiToken Mobile".
Also to Authentication/RADIUS Service/Clients/<your client definition/<profile>/"Enable FortiToken Mobile push notifications authentication".
Push notification is sent to Apple/Android notification centers and if you tap to approve authentication, then FAC needs to know that back. So DNAT like VIP (Virtual IP) pairing some IP:port (port preferably 443) and allowing access from outside to FAC and push service there will help.
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
Thank you xsilver! I was assuming that field also needed to be filled (Public IP) and i did previously but since it only has outbound PAT that public PAT address wouldn't suffice.
I do have one follow up question- I will need to allow this traffic inbound on the edge FW in the data center. Does the Apple/Android notification centers have a defined set of IP addresses/subnets that can be configured as the source? I could not find this info in the admin guides. My company, and myself, prefer not to have inbound rules from the internet with the source as 'any'. Also, you mention port 443 is preferred, but really any TCP should work right? There is no SSL Certificate info being traded correct?
Thanks again!
Noel
Cheers!
Noel
Hi Noel,
not sure about Android, I do not own any, but for Apple iOS devices paired with FortiToken Mobile, there all starts with DNS query from FAC for A record of gateway.push.apple.com. Where result shows ~8 IP addresses in my case, but I do guess the Apple will load balance that and for the purpose it seems to be done via Akamai network (as original name is CNAM to gateway.push-apple.com.akadns.net).
Port on FAC is always 443.
But in FAC GUI : System / Administration / System Access / you can set "Public IP/FQDN for FortiToken Mobile:" to outer IP and port. This is NOT a port/IP on FAC itself, but it allows you to define IP:port on outer NAT router which is capable to do DNAT/VIP to translate this publicly accessible IP:port to IP on FAC and port 443.
VIP/DNAT destination IP on the FAC side should be one on interface (like port1) where you do have "FortiToken Mobile API (/api/v1/pushauthresp, /api/v1/transfertoken)" turned on in FAC GUI : System / Network / Interfaces / Interface Status / Access Rights / Services.
Because, FAC sends message to push notification service on Appple/Android side, with data whom to notify and where to send response! This is the place from where your mobile platform get idea where/how to respond when you Approve/Deny push request. That's that "Public IP/FQDN for FortiToken Mobile:" !
Communication (Approval/Deny) between FortiToken Mobile app on mobile device and FAC is also encrypted with TLS 1.2 (at the moment).
I'm not sure I do understand the question about SSL, but .. 1. FAC queries DNS who is notification server gateway.push.apple.com 2. FAC get some responses and choose first A record for gateway.push.apple.com
3. TCP TLS ver 1.2 handshake starts with that server and FAC is sending Client Hello
4. TLS handshake continues as usual with Server Hello, Certificate, Cert Request and Server Hello Done
5. FAC follows to complete build of certificate signed channel and when Change Cipher Specs are exchange the tunnel is built 6. notification data sent to Apple, which makes them popping-up on your mobile device display
... So, yes, communication with notification center IS signed by certificates and TLS encrypted.
EDIT: 2019-07-30 - to add details about port 443 on FAC
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
Thank you very much Tomas!
Cheers!
Noel
So what was your issue?
I have a problem on my dev device i am setting, up.
Mobile gets the token, but as soon as the request gets to it, the FortiClient times out :(
I'm not sure I understand what your actual issue is? I have no issue with the FortiClient or Fortitoken mobile, I can log on successfully all day long. But there is a feature that is for ease-of-use, not required, by implementing the push notification to your phone so you don't have to unlock your phone, open the app and click on the eyeball to get your token. You just hit 'Accept' in the notification and it automatically generates the token and sends it home. The fix for that was to give the FAC a static 1 to 1 NAT for inbound connectivity whereas previously it only had outbound connectivity to the internet with an interface overload NAT on the edge FW.
Cheers!
Noel
Noel,
Thats where my issue is.
I can enter the token code when logging in, but if i hit "push" then the request hits the app, but it crashes out.
TAC are working on it, as everything is setup as it should be
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1737 | |
1107 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.