Technical Tip: Instability of IPsec VPN Tunnels terminated on PPPoE interfaces

[alif]

Description	This article describes the instability of IPsec VPN tunnels terminated on PPPoE interfaces.
Scope	FortiGate.
Solution	Consider an IPsec VPN tunnel configured on FortiGate where FGT-I utilizes a PPPoE connection on the WAN interface. config vpn ipsec phase1-interface     edit "IPsec-VPN"         set interface "wan1"         set peertype any         set proposal aes128-sha1         set dpd on-idle         set remote-gw x.x.x.x         set psksecret xxxxx     next end config system interface     edit "wan1"         set vdom "root"         set mode pppoe         set distance 10         set allowaccess ping https ssh         set type physical         set role wan         set snmp-index 1         set username "xxxxxxxxxxxx"         set password xxxxxxxx     next end It has been observed in several TAC cases that whenever the WAN connection (PPPoE) flaps or there is a short interruption, the IPsec VPN tunnels get affected and do not get reestablished. The reason is that the pppoe connection flap/restart creates a new pppoe session ID. The frames sent by FortiGate-I and received on FortiGate-II use different PPPoE session IDs resulting in IPsec VPN failure. The PPPoE session ID can be found out by running a sniffer (packet capture) on the WAN interface. diagnose sniffer packet wan1 " " 6 0 l An example of a PPPoE session ID (Session ID: 0x1c7f) can be shown in the below screenshot of the Wireshark capture. On CLI, the below command will provide the PPPoE session ID. Fortigate-I # fnsysctl cat /proc/net/pppoe Id Address Device 00007f1c 20:e0:9c:xx:xx:xx wan1 The session ID shown in CLI is in host order and the one shown on Wireshark is in network order. Hence, the session ID matches if the order is switched (1c7f <--> 7f1c). In such scenarios when the IPsec VPN is not getting reestablished after the PPPoE connection flap, the IPsec tunnel interface utilizing the PPPoE connection should be shut down for a few minutes. This causes the old PPPoE session ID to be removed from the ISP side. Once the IPsec tunnel interface is brought up again after a few minutes, both FortiGate-I and FortiGate-II will share the same PPPoE session ID after which the IPsec tunnel will get re-established. This is not an issue on FortiGate but rather an issue on the PPPoE server side (ISP) which retains the old PPPoE session ID.