FortiGate does not send Two-Factor activation code

[shaheryar_akhter]

Hi,

Our Foritgate appliance is configured to send email alerts, which are being received for all the desired events. However, when using FortiToken, we do not get our activation code via email. While the firewall shows that the email has been sent successfully. 

Is there a way to track outgoing email from our FortiGate appliance? 

Version: 6.0

[Alivo__FTNT]

Hi, for debugging you can use following: diag debug reset

diag debug enable

diag debug console timestamp enable

diag debug application alertmail -1

send the activation mail, then disable debug by:

diag debug disable

diag debug reset

Best Regards,

Alivo

[davepartridge]

Useful command line info but where do you find the debug information? I have the same issue when trying to send either email or SMS for a 2FA verification code.

[abeauchamp]

davepartridge wrote:

Useful command line info but where do you find the debug information? I have the same issue when trying to send either email or SMS for a 2FA verification code.

Leave the CLI open.  The output displays to the console.  (Just minimize it while you send the test/activation email or connect with a 3rd party SSH client like Putty so you can do both and not lose your console output).

[ffossard]

thks !

When the sending of email fails, the fortigate falls back on notification.fortinet.net (which leads to an SPF problem)

Examples:

[pminarik]

Can you please clarify where in the debug does it show that the FortiGate is supposedly falling back to notification.fortinet.com? The FQDN is not mentioned anywhere in the debugs, and the IP used doesn't match that server either. (the IP shown is some Google server.

[SJFriedl]

Late to this game, but I ran into this tonight.

When Fortinet sends the email with the activation code, it sends it from the user who is also the recipient, and there are plenty of email systems - including mine and that of my customer - who reject emails *from* a user who is part of the receiving domain but not properly authenticated to that domain.

Figured this out tonight with an outstanding Fortinet tech (hi Jai!) while watching my mailserver logs, and this is clearly a bug that is unaware of anti-spam countermeasures in the last 10 years.

I'm about to open a defect ticket.

[AbeyMarquez]

@SJFriedl You are absolutely right! I just checked my email headers and it is indeed sending it from FortiGuard servers as myself! This is unbelieveable! Anyone with SPF set up correctly will fail this email. It goes to show how inept the ones who wrote this routine were when they wrote it about email security and that nobody has cared enough to fix it, like you well put "in the last 10 years" or more.

I'm gonna follow suit and open a ticket as well.

EDIT: Wait, it seems to be more complicated that it first appeared. The activation code email actually originated from the firewall, not from the FortiGuard servers. So technically, it is originating from inside your network and SPF should be ok. However, at some point, the notifications.fortinet.net server takes over the message as if it has sent it itself and the next hop does indeed complain about an SPF error.

[Toshi_Esumi]

I'm almost sure FGT picks email address under System->Settings->Email Service->Default Reply-to for the source address of any self-originated email. Or "config system email-server/set reply-to" in CLI.

Have to set it up? If not set, it might use the destination address because no other immediate options.

Toshi

[AbeyMarquez]

Yeah, I just checked and I have it blank on mine. I didnt want to change a default setting without knowing what it did. That's good to know. However, this does not solve the SPF problem since these messages are being relayed through notifications.fortinet.net and any mail gateway obeying SPF will reject them. It seems the only solution is to designate notifications.fortinet.net as a permitted sender in the SPF config line.