Hey Guys,
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 1.2.3.4.500 -> 10.10.10.10.500: udp 512 351.109211 port1 out 10.10.10.10 -> 1.2.3.4: 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?
Many thanks!
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
I think you didn't read my last update I guess, because it's not an issue with the configuration of the VPN settings, the FAZ never even comes that far. The ID and PSK settings are never exchanged, because the FAZ doesn't answer the IKE packet because the service is not listening. It doesn't even get that far to check the PSK or IDs, that's also the reason because the IKE debug doesn't generate any output.
Does anybody know why there is no IPsec logging support in the 5.4 FortiGate OS?
try from cli FGT rom ipsec is a available logging field in a FortiOS 5.4.x
execute log filter category 1
execute log filter field vpntunnel < actual fgt2faztunnel name>
execute log display
Btw , I have 3 fgt runing to 5.4.1 FAZ on 5.2.x and 5.4.x with zero problems.
How did you validate that 1 > ipsec daemon is not listing 2> did run by-directional diag sniffers packets on the FGT and FAZ appliance s 3> have you validate no other items are restricting IKE traffic between peers.
PCNSE
NSE
StrongSwan
Thanks Simon, looking forward to your results!
@emnoc:
1) I used the the following command, there I can see that there is no listening port on 500 with my interface ip or 0.0.0.0, therefore, no connection is possible:
diagnose fmnetwork netstat list
2) Yeah I did a sniffer trace on both FGT and FAZ, and I can see the incoming packet on the FAZ, and the outgoing ICMP port blocked message on the FAZ
3) There isn't anything in between which blocks packets, because in both sniffer traces I can see the same packets, so not a configuration nor a connection issue
I have another question for you please: How are you connecting a FGT with 5.4.x to the Analyzer with IPsec Tunnel? This isn't even in the firmware anymore?
Okay after reinstalling the FAZ image it worked for 20 minutes, then it stopped working for several hours, and worked again suddenly in the middle of the night. Today the FAZ was rebooted and now the appliance isn't listening on the IKE ports anymore, so no solution other then reinstalling FAZ. Can you verify this Simon?
Qs: What method are you using determine IPSEC is not working on the fortianalzyer.
You mention netstat output
I believe if your coming thru a NAT device at the FAZ end and ike NAT-T is required due to this nat, you nat-t device might be a cause. I do't recall any means for enabling a NAT-T keep alive function on the FAZ directly. Do you have a topology map of ALL of the devices in the path from FGT ----------------> FAZ @ AWS
Does the firewall that send packets to the FAZ, does it have a up lifetime setting that you can modify? if yes, can you set the session lifetime to a extreme lifetime
When the ipse-tunnel drop, did you run any dig sniffer packet <interfacename> "port 500 or 4500" and see if anything is being sent between FGT<>FAZ?
My apices tunnels which are direct with no nat works fine. I don't believe the DHCP is the issue btw. You could set a static reservation for the FAZ if your concern on address lease/renewals
PCNSE
NSE
StrongSwan
emnoc wrote:Qs: What method are you using determine IPSEC is not working on the fortianalzyer.
You mention netstat output
Yes exactly, first I did a sniffer trace, and there I saw the that the IKE packets are not answered, then I tried to find the reason for this, and the netstat confirmed it:
interfaces=[any]
filters=[port 500 or port 4500]
8.975055 port1 in 1.2.3.4.500 -> 10.10.10.10.500: udp 512
14.979074 port1 in 1.2.3.4.500 -> 10.10.10.10.500: udp 512
26.975922 port1 in 1.2.3.4.500 -> 10.10.10.10.500: udp 512
Output of the netstat:
udp 0 0 0.0.0.0:162 0.0.0.0:*
udp 0 0 127.0.0.1:500 0.0.0.0:*
udp 0 0 0.0.0.0:59581 0.0.0.0:*
udp 0 0 127.0.0.1:4500 0.0.0.0:*
udp 0 0 127.0.0.1:6001 0.0.0.0:*
So as you can see, no private IP (it's just a snippet but usually the local ip socket should be right under or above the loopack socket)
I believe if your coming thru a NAT device at the FAZ end and ike NAT-T is required due to this nat, you nat-t device might be a cause. I do't recall any means for enabling a NAT-T keep alive function on the FAZ directly. Do you have a topology map of ALL of the devices in the path from FGT ----------------> FAZ @ AWS
You are right about that, when the tunnel worked for a short period of time, the first packets were done via port 500, and then it switched to port 4500, like it should, because NAT is detected. I'm not sure about the topology, the FGT is directly connected to the internet - the FAZ only has a private IP and is NATed to a public IP via Azure settings, but it's a 1:1 NAT.
Does the firewall that send packets to the FAZ, does it have a up lifetime setting that you can modify? if yes, can you set the session lifetime to a extreme lifetime
I can't find anything regarding a life time for the IPsec tunnel, neither in the FAZ CLI reference nor in the FGT CLI reference.
When the ipse-tunnel drop, did you run any dig sniffer packet "port 500 or 4500" and see if anything is being sent between FGT<>FAZ?
Yes like the one I posted above, I only see the packets from the FGT, there are no packets in the other direction.
My apices tunnels which are direct with no nat works fine. I don't believe the DHCP is the issue btw. You could set a static reservation for the FAZ if your concern on address lease/renewals
I don't think the issue in general is with DHCP too, but it's just the problem that the service is not correctly binding the address to the port if DHCP is set. That's why it's not listening after the reboot of the appliance
Try this
{FAZ}
diag debug application ipsec -1
diag debug enable
{ FGT }
diag vpn tunnel flush name <VPNtunnel name for the dynamic ipsec>
on the the lifetimes you can do this ;
phase ipsec-SA
1: execute the above command and immediately execute diag vpn tunnel list name <VPNtunnel name for the dynamic ipsec>
You will see the SA lifetime is counting down at 1800sec which matches the FAZ diag debug app ipsec output. Now for the IKE phase1 the lifetime is the industry std 28800
IKE-SA
e.g for determining that value for the FGT---FAZ ipsec tunnel at phase1
FG3K2C3Z13800237 (root) $ diag vpn ike gateway list name FGh_FtiLog1 | grep time IKE SA: created 1/1 established 1/1 time 20/20/20 ms IPsec SA: created 1/5 established 1/5 time 10/44/60 ms lifetime/rekey: 28800/27777 <------HERE the value for the lifetime
Hope that helps but your problems some more than just any SA lifetime values, Have you try or considered
1: downgrading FAZ
2: rebooting
3: dropping the ipsec config and re-enabling it
4: grep on the "diag system process list" output for any PID that's associated to raccoon or check the ipsec status "diag ipsec status"
5: if you find that pid ( item#4) kill
6: try a different FGT appliance ( we had a issue with a earlier 5.2.1 and ipsec to a FAZ but it was aproblem with just that one FGT1500 )
Either way keep us updated if you run into the fix, but I see in your crystal ball that you will need a FTNT support case.
Ken
PCNSE
NSE
StrongSwan
Hey Guys,
just for information, as I guessed this is a bug in the firmware of the FAZ, it will be fixed in the next release 5.4.2 and 5.6.0
The bug ID is 0390795.
Greetings
The interface of the FAZ is set to DHCP, and there is no local listening port
-- FAZVM-AWS is special for interface config, which is DHCP, we will double check this case on AWS
Thanks
Simon
sorry, same for Azure in this ticket case, other FAZs only support manually configured IP
Thanks
Simon
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 |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
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.