Skip to content

Latest commit

 

History

History
73 lines (43 loc) · 5.17 KB

faq-ipsec-connectivity.md

File metadata and controls

73 lines (43 loc) · 5.17 KB
Raw

FAQ - IPSEC VPN connectivity and troubleshooting for FortiGate running in Microsoft Azure

Introduction

IPSEC is a group of protocols that can be challenging to get right. There are multiple parameters to take into account. Microsoft Azure networking and the FortiGate NGFW deployment in it, has some specific design and limitations to take into account.

In this FAQ there are 2 sections: configuration and troubleshooting. The configuration will cover the different Azure and FortiGate components to establish a tunnel from an on-premises device.

Configuration

Active/Passive High Available FortiGate pair with external and internal Azure Standard Load Balancer

More information about this deployment type can be found here.

ipsec

Microsoft Azure

  • The external Azure Load Balancer requires 2 load balancer rules to pass IPSEC traffic to the active FortiGate. The rules need to configured to pass ports UDP/500 and UDP/4500 as explained in this link

  • The Floating IP options should not be enabled on the IPSEC VPN LB rules (UDP 500 and UDP 4500). When Floating IP is enabled, Azure Load Balancer doesn't DNAT the packets to the private IP configured on the FortiGate. The FortiGate VM in Azure doesn't have the public IPs configured and as such local processes like IPSEC do not listen on this public IP address.

More information on when to enable floating IP or not on a load balancing rule towards the FortiGate can be found here. More information on the floating ip options can be found here.

floating floating

FortiGate

  • Firewall policy referencing the VPN is required for the IPSEC tunnel to be enabled

  • Microsoft Azure requires NAT between public IP and the FortiGate VM with or without the Azure Load Balancer. To establish an IPSEC tunnel across NAT the NAT Traversal options needs to be set to Enable or Forced on both the FortiGate in Azure and on the remote peer

    natt

  • If the tunnel is failing with the error message "received notify type AUTHENTICATION_FAILED" or "RETRANSMIT_AUTH" it is likely that the local-id set by the FortiGate does not match the local id expected by the peer. To resolve this issue you can configure the FortiGate to set a specific localid-type and value. Ensure that the vpn peer is configured to match this value in the peer-id field.

The example below shows local-id type and value set to fqdn. The localid-type and value can be set to fqdn, a string or auto, for more information please consult the CLI guide here

localid

> Do not set the localid value to the private ip address of the FortiGate nic, since upon failover the ip address of the new primay FortiGate will be a different one.

Troubleshooting

Azure

  • For FortiGate A/P LB sandwich, ensure that UDP500 and UDP4500 Load balancing rules are functionnal

    1. In Azure, go to the Azure external load balancer, click on Insights and verify that the primary FortiGate is marked as healthy (answering health probes). The other FortiGate is secondary so should be marked as unhealthy

      lbinsights

    2. Check on the FortiGate if udp 500 and udp 4500 are reaching the FortiGate from the on-premise device. Use the command diagnose sniffer packet any 'port 500 or port 4500' 4 0 a or the following command if you want to only capture traffic coming from your peer. Replace x.x.x.x with the actual peer ip diagnose sniffer packet any '(port 500 or port 4500) and host x.x.x.x' 4 0 a

      tcpdump

    3. If the tcpdump does not show any packet. Please check your NSG rules. nsg

FortiGate

  • To check log relating to vpn events on the FortiGate go to Log & Report, Events and then clickk on VPN events vpnevents

  • Click on the error message to view further details vpnevents2

  • For advanced troubleshooting, use the commands below

diagnose vpn ike filter name <phase1 name>
diagnose debug application ike -1
diagnose debug enabled