Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Nytro
New Contributor

FortiAuthenticator FTM push notifications not working

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

Cheers! Noel
1 Solution
xsilver_FTNT

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

View solution in original post

7 REPLIES 7
xsilver_FTNT
Staff
Staff

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

Nytro

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

Cheers! Noel
xsilver_FTNT

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

Nytro

Thank you very much Tomas!

Cheers!

Noel

Cheers! Noel
baker_gt
New Contributor

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 :(

Nytro
New Contributor

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

Cheers! Noel
baker_gt
New Contributor

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

Labels
Top Kudoed Authors