Configure and verify a PPPoE WAN on Sophos Firewall

PPPoE belongs on Sophos Firewall when an upstream modem or ONT transparently passes through the connection in bridge or passthrough mode. The firewall then establishes the provider connection and receives the assigned WAN address.

If the provider device establishes the PPPoE session, the Sophos Firewall behind it normally receives a static or DHCP-assigned WAN address. If both devices perform NAT, this creates double NAT. An additional PPPoE dial-in on the firewall is usually unnecessary in this setup and may be rejected as a second session.

⚠️ Before making the change, it must be clear which device establishes the PPPoE session. Simultaneous dial-in from the provider device and firewall only makes sense if the provider explicitly supports multiple sessions. Local or independent administrator access is required for the change because an incorrect setting immediately disconnects the internet connection.

Gather the provider details before starting

The following values should be available before the maintenance window:

• PPPoE username and password, or the provider’s exact authentication requirement
• Bridge or passthrough mode of the modem or ONT
• Optional provider VLAN ID
• Optional access concentrator or service name
• Requirement for a dynamic, fixed, or preferred IP address
• DNS requirements and known MTU or reconnect specifics
• Number of permitted PPPoE sessions and information about CGNAT

Sophos Help specifies the PPPoE account username and password. Confirm any different provider requirement before the maintenance window; do not assume that a blank password is supported. WebAdmin accepts a maximum of 50 characters for the username. If the provider login is longer, clarify this with Sophos Support before making the change.

Preparation should also include a current configuration backup, a maintenance window, and a rollback plan. When making a remote change, the only management access must not use the same WAN port that is being reconfigured.

Configure the PPPoE interface

The following example uses Port2 for a connection with a bridge ONT. The provider requires a username, password, and VLAN 7, but no Preferred IP or service name. VLAN 7 is only an example and must not be applied to a real connection without verification.

1. Open Network > Interfaces.
2. Open the menu for the intended WAN port and select Edit interface.
3. Set a clear name such as WAN-PPPoE and the zone to WAN.
4. Enable IPv4 and select PPPoE as the IP assignment.
5. Under Username, enter a value such as firma@example.net, and enter the corresponding provider value under Password. Do not copy real credentials into screenshots or tickets.
6. Leave Preferred IP empty if the provider has not specified a fixed PPPoE address.
7. Assign a clear Gateway name such as gw-pppoe, and enter the provider’s required Gateway IP address for a physical PPPoE interface. On a PPPoE VLAN, this field instead displays the configured gateway address.
8. Leave Access concentrator/service name empty unless the provider requires an exact name.
9. Keep LCP echo interval at 20 seconds and LCP failure at 3.
10. Only enable a scheduled reconnect if the provider or operational requirements call for it.
11. If the provider requires a VLAN for PPPoE, choose one of the options described in the next section.
12. Save the configuration, then verify the interface, gateway, DNS, and real client traffic.

A Preferred IP is only a request to the provider. Even if an address is entered, the PPPoE server may assign a different IP. The provider must offer the appropriate service for a guaranteed fixed address.

An access concentrator or service name restricts dial-in to a matching endpoint. An invented or misspelled value can prevent the connection during the discovery phase. Therefore, leave the field empty unless the provider explicitly supplies a value.

Implement the provider VLAN correctly

A provider VLAN can be configured in two ways. Both methods are valid, but they must not be combined for the same connection.

Option 1: VDSL setting on the physical PPPoE port

Configure PPPoE directly on the physical WAN port. Under DSL settings, enable VDSL and enter the provider VLAN ID. SFOS then performs the required VLAN processing for the PPPoE session.

The term VDSL does not mean that the firewall replaces a DSL modem or ONT. The upstream device remains responsible for the physical line and synchronization.

In this example, VLAN 7 is set on the PPPoE port. Do not then create an additional manual VLAN 7 with a second PPPoE configuration on the same connection.

Option 2: PPPoE on a manual WAN VLAN

Under Network > Interfaces > Add interface > Add VLAN, first create a VLAN on the physical provider port. Assign this VLAN to the WAN zone, enter the provider VLAN ID, and select PPPoE as its IPv4 assignment. Enter the credentials on this VLAN interface.

This setup is useful when the VLAN interface should be explicitly visible and named separately in the interface design. Configure VLANs on Sophos Firewall explains the basics of the parent interface and VLAN tagging.

If a VLAN is already configured on a physical interface, SFOS cannot simply change the IP assignment of that physical interface from Static to PPPoE or DHCP. In that case, review the existing interface and VLAN design first. Interface changes can also affect dependent DNS, gateway, SD-WAN, interface host, VLAN, and dynamic DNS configurations. Off preserves the interface configuration, whereas deleting a virtual interface can also remove dependent rules and objects.

Understand LCP and reconnects

LCP echoes check whether the PPP peer is still responding. With the default values, the firewall sends a check every 20 seconds and considers the session unreachable after 3 missed responses.

These values are a sensible starting point. A shorter interval detects failures earlier but may trigger unnecessary reconnections on an unstable line. Therefore, only adjust LCP based on a provider requirement or a documented fault pattern. Clearing the setting does not disable LCP; it restores the default values.

Schedule time for reconnect disconnects and re-establishes the PPPoE session at a specified time. This can help with a provider’s regular forced disconnection, but it is not a general repair function. Active connections are interrupted, and with dynamic assignment the public IP address may change. A required reconnect should therefore be scheduled outside production hours.

Validate the complete connection

An assigned WAN address alone does not prove that clients can access the internet. After saving, verify the involved layers in the following order.

Interface and gateway

Under Network > Interfaces, the PPPoE interface must show Connected and an assigned address. Connecting means that it is still obtaining an address; Disconnected means that the address has been released. The associated physical WAN gateway appears automatically under Network > WAN link manager.

A new WAN gateway is Active by default. With multiple internet connections, it may therefore immediately participate in load balancing. If the new PPPoE connection should only serve as a standby, configure the gateway directly as Backup and then test it in a controlled manner. The full procedure is described in Configure and test WAN failover.

DNS

Under Network > DNS, either use Obtain DNS from PPPoE or deliberately configure static DNS. Use Test name lookup to verify name resolution directly.

With multiple PPPoE connections, do not assume an undocumented order for the received DNS servers. Deliberately selected DNS servers and separate tests provide a predictable multi-WAN design.

Firewall rule, NAT, and client test

LAN-to-WAN traffic requires a matching firewall rule and usually masquerading or SNAT. Understand NAT on Sophos Firewall explains how these components work together.

Then test at least the following functions from a client:

1. Reachability of an external IP address.
2. Resolution of a DNS name.
3. Access to an HTTPS page.
4. An application that is important for operations.
5. A log entry showing the expected firewall rule and WAN interface.

A successful ping is not sufficient. DNS, HTTPS, NAT, or an application may still fail even though small ICMP packets work.

If Log Viewer does not clearly show where the path ends, apply a narrow client IP and protocol filter under Diagnostics > Packet capture. For forwarded packets, In interface, Out interface, Rule ID, NAT ID, Status, and Gateway ID must match the intended path. The view only proves what was captured; the capture buffer is limited to 2048 KB and stops when full unless buffer wrapping is enabled.

Roll back a failed change

If no PPPoE session is established, use the independent administrator access to restore the documented previous state. For an additional PPPoE VLAN, first set it to Off so its configuration remains available for analysis. Then restore the provider device and reactivate the previous static or DHCP WAN path, gateway, and DNS. If the physical port itself was changed, restore its recorded values. Do not hastily delete a PPPoE VLAN: deleting a virtual interface can remove dependent firewall rules and other configuration. Continue only after the old path passes the interface, gateway, DNS, and real-client checks again.

Troubleshoot PPPoE errors systematically

Check the line and configuration first, followed by MTU or other special values:

1. Check link status, modem or ONT synchronization, cabling, and bridge/passthrough mode.
2. Compare the provider VLAN with the contract details and ensure it has not been set through both the VDSL option and a manual VLAN.
3. Verify the username, optional password, and capitalization exactly.
4. Clear Preferred IP and the access concentrator/service name if the provider has not explicitly specified these values.
5. Save and check whether the interface receives an IP address and gateway.
6. Test DNS first with Test name lookup and then from a client.
7. Check the firewall rule, NAT, and Log Viewer.

For deeper diagnostics in 5. Device Management > 3. Advanced Shell, first monitor the interface events:

tail -f /log/networkd.log

networkd.log shows events for physical and virtual interfaces. The WAN gateway and possible failover events are recorded in dgd.log:

tail -f /log/dgd.log

Stop each live output with Ctrl+C. Additional system messages can be displayed in 4. Device Console using a read-only command:

system diagnostics show syslog

The official log mapping assigns networkd.log to physical and virtual interfaces and dgd.log to WAN link, gateway, and failover events. system diagnostics show syslog shows additional system messages, but does not automatically provide a complete PPPoE root cause. Record the exact message with the time, interface, firmware version, and a fresh connection attempt. If these sources do not identify the cause, capture the reproducible test with a narrow packet filter; Sophos Firewall service logs explains the other files.

Typical patterns:

• No PPPoE peer found: Check the link, bridge/passthrough mode, provider VLAN, and optional service name.
• Authentication rejected: Check the credentials, character length, provider account, and permitted session count.
• Session is established and then drops: Review the line, provider events, LCP, and scheduled reconnect.
• WAN address is present but there is no internet access: Check the gateway, DNS, firewall rule, NAT, and routing.
• Only large packets or VPN traffic fail: Investigate MTU/MSS only after a reproducible test.

Do not change MTU and MSS across the board

PPPoE adds overhead. However, this does not mean that every connection must be manually set to an MTU of 1492 or an MSS of 1452. Default values work in many environments, and additional VLANs, VPNs, or provider technologies change the actual path.

An adjustment is only useful if, for example, small packets work, large HTTPS transfers stall, or packet captures repeatedly show fragmentation problems. Check MTU and MSS on Sophos Firewall explains the measurement and calculation.

Multi-WAN, Dynamic DNS, and HA

An established PPPoE connection behaves like another physical WAN gateway in WAN Link Manager. During a reconnect or failover, however, the public address and all associated connections may change. This particularly affects IPsec, DNAT, external allowlists, and Remote Access. For dynamic addresses, Dynamic DNS on Sophos Firewall helps, but it does not replace testing inbound services.

If the provider assigns only a private or shared CGNAT address, the firewall is normally not directly reachable from the internet. Dynamic DNS only updates the name and does not remove CGNAT. Inbound services require a public address or an address forwarded by the provider.

PPPoE is permitted in an Active-Passive HA cluster, but Sophos states that session failover does not occur. The new Primary must therefore establish the provider connection again. The dedicated HA link and both administration ports require static addresses. Active-Active requires static IP addresses on all interfaces and therefore does not support a PPPoE WAN. The physical provider design must also ensure that both appliances can reach the connection after a role change. Sophos Firewall HA variants explains additional limitations.

IPv6 is a separate provider decision. If the connection provides Prefix Delegation, IPv6 Prefix Delegation on Sophos Firewall shows the separate configuration.

Rule out version-specific issues

SFOS 22.0 MR1 Build 490 resolves several specifically identified PPPoE issues: NC-174437 for Policy Test over PPPoE, NC-173201 for license synchronization in Active-Passive HA with PPPoE, and NC-167806 for packet loss and poor upload performance with a TX queue length of 3. Sophos Known Issues also lists NC-181526 as resolved in MR2 Build 546: on XGS Appliance other than XGS 88/88w, 108/108w, 118/118w, and 128/128w, IPsec tunnels using an alias IP on a PPPoE WAN could establish in GA and MR1 but fail to pass traffic when IPsec acceleration was enabled.

If one of these symptoms occurs on an older SFOS 22 version, first plan a controlled update to a currently supported Maintenance Release. SFOS 22 upgrade check describes the preparation. Old workarounds such as disabling IPsec acceleration across the board do not belong in a new standard configuration.

FAQ