IPsec Tunnel to FortiAnalyzer with private IP

[oheigl]

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!

[oheigl]

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?

[emnoc]

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.

[oheigl]

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?

[oheigl]

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? 

[emnoc]

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

[oheigl]

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 

[emnoc]

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

[oheigl]

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

[scao_FTNT]

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

[scao_FTNT]

sorry, same for Azure in this ticket case, other FAZs only support manually configured IP

Thanks

Simon