Troubleshooting Tip: Troubleshooting PPPoE connection failed

[kcheng]

Description	This article describes how to troubleshoot PPPoE connection failure when FortiGate is configured as the PPPoE client.
Scope	FortiGate.
Solution	Verify that the username and password are correctly configured. Validate if PPOED process is correctly running:       diag sys top | grep pppoed If the PPPoE interface is correctly configured, it would be required to capture the following information from FortiGate: diag netlink interface list <pppoe> diag debug reset diag debug disable diag debug app pppoed -1 diag debug enable To stop: diag debug disable If there is no result in the debug, restart the pppoed process. diag sys process pidof pppoed  --> list all the processes with the PID for pppoed. fnsysctl killall pppoed fnsysctl ps -a --> Verify the PID is different. If it is the same, run the following command to force the reboot of the process. diag sys kill 9 #PID_number fnsysctl cat /proc/net/pppoe --> Validate PPPoE interface. It is recommended to perform packet capture on the physical interface where PPPoE is configured: diag sniffer packet <physical_interface> '' 6 0 a Note: Trying to capture PPPoE negotiation packets on the dynamically created PPPoE interface will not show any packets, as the PPPoE session is not yet established. Verify if the PPPoE negotiation is successful: Client to server: Initiation (PADI) -> Server to client: Offer (PADO) -> Client to server: request (PADR) -> Server to client: session confirmation (PADS). PPPoE consists of two phases: Active Discovery Phase. PPP Session Phase. Active Discovery Phase: The client sends a broadcast Initiation (PADI). The server responds with unicast Offer (PADO). The client sends a unicast Request (PADR). The server responds with a unicast Session (PADS). PPP Session Phase: Link Control Protocol (LCP). PPP Authentication (PAP / CHAP). Network Control Protocol (NCP) -> IPCP. A graphical representation would look like this: To capture packets at each stage, simply use the sniffer below: diag sniff packet <interface name> "ether proto 0x8863" 6 0 a <----- Discovery Stage. diag sniff packet <interface name> "ether proto 0x8864" 6 0 a <----- Session Stage. For the Discovery stage, a sample packet capture might look like this: For the Session stage, a sample packet capture might look like this: If the transaction is valid, it will be possible to see the transactional information in the Wireshark: If there is only broadcast (PADI) information noticed, it may be due to incorrect physical wiring or the ISP router not responding to the request. To help isolate the issue,  use the Windows machine to determine if it does not respond to broadcast. Similar to the image below. In these cases, it is required to check on the physical layer and/or logs on the ISP router to see if it received the broadcast packet and responded accordingly. PPPoE connection failure when FortiGate is configured as the PPPoE client not working in the HA cluster If issues are faced with FortiGate as a PPPoE client not working in a High Availability (HA) cluster with the default group ID 0, refer to the following articles for steps to resolve the problem: Technical Tip: Troubleshooting PPPoE connection failed Technical Tip: HA Cluster virtual MAC addresses In the HA cluster with default HA group ID 0, it is recommended to change the HA cluster default group ID 0. The default HA MAC (group 0) is the source of the problem. The reason the PPPoE server does not respond properly to the default HA MAC address is because if several HA clusters are on the same broadcast domain with default HA group ID 0, they generate the same virtual MAC address. Formula: 00-09-0f-09-<group-id_hex>-<vcluster_integer><idx>. Where <group-id_hex> is the HA group ID for the cluster converted to hexadecimal. Related articles: Technical Tip: pppoe-interface configuration. Technical Tip: How to import 'diagnose sniffer packet' data to WireShark.