How to Configure PPPoE Client on MikroTik RouterOS 7: Interface, VLAN Tag, MTU 1492 and the WAN List

If you are searching for how to configure PPPoE client on MikroTik, the whole job is one /interface pppoe-client add line. What goes wrong is everything around it: the DHCP client the default config left on ether1, the 802.1Q tag the ISP forgot to mention, an MTU that quietly lands at 1460, and a new pppoe-out1 interface no firewall rule knows about. RouterOS 7 on a hEX, RB5009 or CCR is assumed; the commands are the same in v6.

Before you touch the CLI

Collect four things from the ISP: username, password, whether a service name is required (usually not), and whether the session must ride a tagged VLAN. Then look at what the router already does on the WAN port. The default configuration puts ether1 in the WAN interface list with a DHCP client on it, per Building Advanced Firewall. That client sits in “searching” forever once PPPoE owns the port, so disable it, and confirm ether1 is not a bridge member: PPPoE discovery is Layer 2 broadcast, and a bridge owns that traffic, not the port.

/ip dhcp-client disable [find interface=ether1]
/interface bridge port print where interface=ether1

Then ask who is listening:

/interface pppoe-client scan ether1

The scanner returns every access concentrator that answers a PADI, with its MAC, ac-name and service name, per the PPPoE documentation. An empty result on a fibre circuit usually means a missing VLAN tag.

The PPPoE client itself

/interface pppoe-client add name=pppoe-out1 interface=ether1 user=ISP_USER password=ISP_PASS add-default-route=yes default-route-distance=1 use-peer-dns=yes max-mtu=1492 max-mru=1492 disabled=no

Property by property, against the documented defaults:

• interface: the physical port, or a VLAN interface. Never the bridge.
• add-default-route=yes: defaults to no, and a client with no default route connects perfectly and passes nothing. default-route-distance (default 1) is the failover knob: give an LTE or second-WAN route a higher distance and it stays inactive until the PPPoE route disappears.
• use-peer-dns=yes: defaults to no. Leave it off if the LAN resolves through Pi-hole or AdGuard and set /ip dns statically instead.
• max-mtu / max-mru: documented default 1460. Set both to 1492, the ceiling the same page derives for standard Ethernet: 1500 minus a 6-byte PPPoE header minus a 2-byte PPP protocol field. RFC 2516 section 7 makes that a MUST NOT exceed. The concentrator can negotiate lower; you cannot push it higher than the ISP allows.
• service-name and ac-name: blank matches anything. Fill them in only if the ISP gives you a value or the scan shows several.
• allow: default mschap2,mschap1,chap,pap. Leave it; the ISP picks.
• dial-on-demand: default no. Keep it no on a router that hosts anything reachable from outside.
• profile=default: matters more than it looks, see MSS below.

Then check:

/interface pppoe-client monitor pppoe-out1 once

The target is status: connected, a local-address, an ac-name and mtu: 1492.

When the ISP wants an 802.1Q tag

FTTP and many DSL providers terminate PPPoE inside a specific VLAN, and the tag is the most common reason the scan comes back empty. Create the VLAN interface on the WAN port and bind the client to it, following the VLAN documentation syntax; the ID is whatever the ISP specifies.

/interface vlan add name=vlan-wan vlan-id=100 interface=ether1
/interface pppoe-client set pppoe-out1 interface=vlan-wan

A January 2025 forum thread on an Australian NBN provider using VLAN 100 is the canonical failure: session up, throughput a fraction of the plan, fixed by adding both the VLAN and PPPoE interfaces to the WAN list and masquerading on the list. Community report, not vendor guidance, but it matches how the defconf firewall is built.

Keep the WAN VLAN off the bridge. A VLAN interface on a bare ether1 and a bridge VLAN table are separate mechanisms, and mixing them is how people lose management access; VLAN filtering on RouterOS bridges covers the bridge side.

Firewall, NAT and the WAN interface list

The defconf firewall never names ether1. NAT is action=masquerade chain=srcnat out-interface-list=WAN, and the forward-chain rule “drop all from WAN not DSTNATed” matches in-interface-list=WAN, per Building Advanced Firewall. A new pppoe-out1 is in no list, so NAT ignores it and the forward drop does not cover it. One line fixes both:

/interface list member add list=WAN interface=pppoe-out1

Add vlan-wan too if the client sits on a VLAN. The input chain is safer by construction: its final rule is drop ... in-interface-list=!LAN, so an unlisted PPPoE interface still cannot reach the router’s own services. The forward chain is where the gap lives. For how first-match, connection state and FastTrack interact with these rules, see RouterOS firewall rules explained.

Hand-built firewalls without lists: masquerade on out-interface=pppoe-out1, not ether1. Routed traffic leaves through the PPP interface; the physical port only carries the encapsulated session. The out-interface=ether1 example in First Time Configuration is for a DHCP WAN.

MTU 1492 and MSS

Two mechanisms clamp TCP MSS on a PPPoE WAN, and most guides tell you to add the second without mentioning the first. The built-in default PPP profile ships with change-tcp-mss=yes, per PPP AAA, so RouterOS already rewrites the MSS on connections through pppoe-out1 to fit the negotiated MTU. That is why a stock configuration works without a mangle rule.

The mangle rule earns its place when the client uses a custom profile with the setting off, or when a tunnel (WireGuard at RouterOS’s default 1420, IPsec) rides over the PPPoE link. The Mangle documentation example pins a fixed new-mss=1300 against tcp-mss=1301-65535 for a low-MTU hop; for a plain 1492 link the arithmetic is 1492 minus 40 bytes of TCP and IP headers:

/ip firewall mangle add chain=forward out-interface=pppoe-out1 protocol=tcp tcp-flags=syn tcp-mss=1453-65535 action=change-mss new-mss=1452

new-mss=clamp-to-pmtu does that subtraction from the outgoing interface’s MTU for you, which a 2024 forum thread recommends over a hard number when MTU differs per WAN. Do not clamp lower than needed; every byte shaved is throughput lost on every TCP session.

Full 1500 through PPPoE exists on paper. RFC 4638 adds a PPP-Max-Payload tag to PADI and PADR and requires baby-jumbo frames on the Ethernet path. In a 2016 thread, forum users reported it working with the Ethernet MTU raised to 1598 and max-mtu=1500 against one ISP’s Juniper BNG, and falling back to 1480 against others. Treat it as an experiment you verify with the pings below, not a default.

IPv6 on the same session

The IPv6 PD over PPP page runs a DHCPv6 client directly on the PPPoE interface and drops the delegated prefix into a pool:

/ipv6 dhcp-client add interface=pppoe-out1 request=prefix pool-name=isp6 pool-prefix-length=64 add-default-route=yes
/ipv6 address add interface=bridge from-pool=isp6 address=::1/64 advertise=yes

The defconf IPv6 input chain accepts dst-port=546 protocol=udp src-address=fe80::/10 under the comment “accept DHCPv6-Client prefix delegation” (Building Advanced Firewall). A hand-written IPv6 firewall needs that rule or the delegation never arrives.

Running pfSense on the same circuit instead? PPPoE there has its own throughput trap, covered in pfSense slow speeds: finding the bottleneck.

Things to test before you call it done

/interface pppoe-client monitor pppoe-out1 once
/ip route print where dst-address=0.0.0.0/0
/interface list member print where list=WAN
/ping 1.1.1.1 size=1492 do-not-fragment
/ping 1.1.1.1 size=1493 do-not-fragment
/tool traceroute 1.1.1.1

The 1492 ping should pass and 1493 should fail. If 1492 fails, the concentrator negotiated lower and monitor shows the real number; clamp to that. For a session that will not come up, turn on the topic and watch it:

/system logging add topics=pppoe,debug action=memory
/log print follow where topics~"pppoe"

The Log documentation lists pppoe as “PPPoE server/client related messages”. PADI with no PADO means nothing answered: wrong port, missing tag, or a dead line. PADO then an authentication failure means credentials or allow methods. Remove the logging rule afterwards; debug on a busy link is noise.

Related across the network

• Best Homelab Firewall in 2026: OPNsense, pfSense, UniFi, MikroTik — firewallcompare.com
• pfSense Alternatives: 7 Platforms Compared for 2026 — firewallcompare.com
• WireGuard Explained: Keys, AllowedIPs, and NAT Traversal — wireguardlab.com
• WireGuard MTU Calculator and Fragmentation Fix — wireguardlab.com
• WireGuard Setup on Ubuntu: Server and Client — wireguardlab.com