following problem: I have a FAZ VM set up in the azure cloud, and I want to send the logs from the FortiGate to it via IPsec encryption. I configured everything accordingly, but the FAZ drops the IPsec packets from the FortiGate. The azure network settings forward all packets from on ip to the FAZ via destination NAT to it's internal private ip:
351.109183 port1 in 184.108.40.206.500 -> 10.10.10.10.500: udp 512
351.109211 port1 out 10.10.10.10 -> 220.127.116.11: icmp: 10.10.10.10 udp port 500 unreachable
The ike application debug doesn't output anything, I just see the unreachable ICMP packets in the sniffer. Is this situation even supported, or anyway I could debug the problem?
Well that's easier said then done, it's a FAZ, it doesn't have any rules? Or am I missing something here? The trace I posted is directly from the FortiAnalzyer, so the packets arrive at the appliance, it just doesn't answer them, although I configured the device to use IPsec
Yes exactly, I copy pasted everything, but if I missed something there should be at least an output in the ike debug, but nothing, it's just not answering the packets, can I provide any debug logs that may help?
Hey guys, thanks for the replies so far. So regarding the command "config log device ...", this isn't available anymore in the 5.4.1 FAZ. Nonetheless, I think I found the issue, it seems to be a bug in the firmware. The interface of the FAZ is set to DHCP, and there is no local listening port, which results in the ICMP message. If I look at the netstat of the FAZ, the only listening port for the IPsec is on the loopback interface:
udp 0 0 127.0.0.1:500 0.0.0.0:*
There is no listening port on the actual interface IP, I guess the VPN daemon starts up before the FAZ acquires an IP from the DHCP. Anybody know how I could restart the process handling the VPN service? I couldn't find a name in the process lists which could have something to do with it, otherwise I would try to kill it and see if it works after that.
Another thing I recognized during the troubleshooting: Why the hell did they remove the IPsec logging in the 5.4 FGT release? How can I be sure that nobody checks on my logs with the usual SSL encryption, there are no options which SSL certificate is used or which certificate the FGT should trust. Are there any options to configure peer certificates?
yes that was figuratively speaking the cmd are in a DB format but the principle stays the same.
here's my cfg 5.2.x to 5.4.1
config log fortianalyzer setting
set status enable
set server 10.x.x.x <-FAZ target
set encrypt enable
set psksecret ENC JF+HMvPmEbkzK3H77B6ys0ZXh240s+0JXWbJUTrrRdXaJRNDuHpzmQX08FkTAn5uUxO0HNRlS42YgkKj5WF9FD4VdfA9tZJBhos7tFHn4OCJ6vIlTakPB+OAAjX42fgF+u8S2h8/xh+HgKAfA78egDNA8x/2QfDBFMqmjC/rx2+QxwenZz3sHIrbd4mfssQgDrApYg==
set localid "FG3Kxxxxxxxxx" ( match the FAZ )
set source-ip 10.1.1.1 <---FGT peer-ipv4 address, very importtant to set to the correct peer address
set reliable enable
See screen shot of the FAZ , you can run a diag sniffer packet any " host <FAZ> and proto 14 or 50 > to validate the ipsec tunnel is up. You should see tons of ESP packets if you have any serious logging rate from the fortigate.
It's really that easy ;)
be advise my 5.4.1 diagnostic vpn tunnel list does not show the ipsec tunne but you can diag vpn tunnel flush-SAD and see the phase1 re-establishing. I believe this is a bug in the cli.
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.