No internet access, but working PPPoE on Fritz!Box 7520

Dear OpenWrt Forum,

with the following issue I would like to reach out to you hoping someone has a hint for me.

Issue
I successfully flashed OpenWrt onto my Fritz!Box 7520 and have a synced VDSL connection. My issue is that with my current configuration I have no access to the internet.

Context
Currently I have a contract with 1&1 (Germany) and I get a public IPv4. Therefore I left out the paragraph in OpenWrt ISP Config for DS_Lite. (Also with my ISP Router every traceroute -A is within AS3320 = Deutsche Telekom).

service dsl_control dslstat excerpt
service dsl_control dslstat | grep 'state"\|mode"\|data_rate\|snr' | grep -v ra_mode
	"state": "Showtime with TC-Layer sync",
	"power_state": "L0 - Synchronized",
	"mode": "G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)",
		"data_rate": 37000000,
		"snr": 9.600000,
		"data_rate": 79990000,
		"snr": 10.000000,
ping and nslookup diagnostics (using ISP DNS for now)
nslookup openwrt.org
Server:		127.0.0.1
Address:	127.0.0.1:53

Non-authoritative answer:
Name:	openwrt.org
Address: 64.226.122.113

Non-authoritative answer:
Name:	openwrt.org
Address: 2a03:b0c0:3:d0::1a51:c001
ping -c 5 openwrt.org
PING openwrt.org (2a03:b0c0:3:d0::1a51:c001): 56 data bytes

--- openwrt.org ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

ping -c 5 -4 openwrt.org
PING openwrt.org (64.226.122.113): 56 data bytes

--- openwrt.org ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Forum Search
I already did search for similar forum questions, but it seems they all have a different problems:
Issue with DSL modem/DSL
1
2
3
4
Issue with Supervectoring
5
Issue with ADSL
6

I would be glad if someone could provide a hint and hopefully I am not overlooking something completely stupid.
Thanks in advance,
Cheers Daniel

Config Details:

/etc/config/firewall
config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option mtu_fix '1'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'
/etc/config/network
config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd3e:cbe5:802c::/48'

config atm-bridge 'atm'
	option vpi '1'
	option vci '32'
	option encaps 'llc'
	option payload 'bridged'
	option nameprefix 'dsl'

config dsl 'dsl'
	option annex 'j'
	option tone 'bv'
	option ds_snr_offset '0'
	option firmware '/lib/firmware/vdsl.bin'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config device
	option name 'dsl0'
	option macaddr '1C:ED:6F:41:AE:38'

config interface 'wan'
	option device 'dsl0.7'
	option proto 'pppoe'
	option username '1und1/<redacted>@online.de'
	option password '<redacted>'
	option ipv6 '1'

config interface 'wan6'
	option device '@wan'
	option proto 'dhcpv6'

config device
	option type '8021ad'
	option ifname 'dsl0'
	option vid '7'
	option name 'dsl0.7'

As i don't have this stanza in my Telekom-VDSL configuration, i'd suggest to remove it.

Thanks for your reply.
I changed the device dsl0.7 to unconfigured, but unfortunately this did not help. It also broke the DSL sync.

I wonder how this part has to be changed then when the VLAN7 reference is missing:

config interface 'wan'
	option device 'dsl0.7'
	option proto 'pppoe'
	option username '1und1/<redacted>@online.de'
	option password '<redacted>'
	option ipv6 '1'

I would have expected that this is needed in order to establish a connection over PPPoE.

Yes, you need VLAN7, the only question is how you need to define it...

Please change the pppoe deamon to be more verbose:
Edit /etc/ppp/options to make sure it says debug and not #debug
then re-initiate a PPPoE reconnection and then post the output of:
logread | grep -e ppp
(please check for information like MAC or IP addresses you might want to redact before posting...)

I would have expected that I am fine regarding the PPPoE side.
So the status is always Showtime which should be a good sign.

Nevertheless, here is my .log excerpt:

logread | grep -e ppp
Wed Jan  1 20:38:58 2025 daemon.info pppd[9486]: Plugin pppoe.so loaded.
Wed Jan  1 20:38:58 2025 daemon.info pppd[9486]: PPPoE plugin from pppd 2.4.9
Wed Jan  1 20:38:58 2025 daemon.notice pppd[9486]: pppd 2.4.9 started by root, uid 0
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]:  dst ff:ff:ff:ff:ff:ff  src 1c:ed:6f:41:ae:38
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]:  [service-name] [host-uniq  0e 25 00 00]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 42
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]:  dst 1c:ed:6f:41:ae:38  src <redacted>
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]:  [AC-name EIHJ01] [host-uniq  0e 25 00 00] [service-name] [AC-cookie  ed aa 82 e9 45 4b 55 8f fb 84 28 f0 a0 c7 84 01]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: Send PPPOE Discovery V1T1 PADR session 0x0 length 32
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]:  dst <redacted>  src 1c:ed:6f:41:ae:38
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]:  [service-name] [host-uniq  0e 25 00 00] [AC-cookie  ed aa 82 e9 45 4b 55 8f fb 84 28 f0 a0 c7 84 01]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: Recv PPPOE Discovery V1T1 PADS session 0x30 length 42
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]:  dst 1c:ed:6f:41:ae:38  src <redacted>
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]:  [service-name] [host-uniq  0e 25 00 00] [AC-name EIHJ01] [AC-cookie  ed aa 82 e9 45 4b 55 8f fb 84 28 f0 a0 c7 84 01]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: PADS: Service-Name: ''
Wed Jan  1 20:38:58 2025 daemon.info pppd[9486]: PPP session is 48
Wed Jan  1 20:38:58 2025 daemon.warn pppd[9486]: Connected to <redacted> via interface dsl0.7
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: using channel 2
Wed Jan  1 20:38:58 2025 kern.info kernel: [ 6473.438948] pppoe-wan: renamed from ppp0
Wed Jan  1 20:38:58 2025 daemon.info pppd[9486]: Renamed interface ppp0 to pppoe-wan
Wed Jan  1 20:38:58 2025 daemon.info pppd[9486]: Using interface pppoe-wan
Wed Jan  1 20:38:58 2025 daemon.notice pppd[9486]: Connect: pppoe-wan <--> dsl0.7
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xe1cf94a3>]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: rcvd [LCP ConfReq id=0x33 <mru 1492> <auth pap> <magic 0x21930b9>]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: sent [LCP ConfAck id=0x33 <mru 1492> <auth pap> <magic 0x21930b9>]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xe1cf94a3>]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: sent [LCP EchoReq id=0x0 magic=0xe1cf94a3]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: sent [PAP AuthReq id=0x1 user="1und1/<redacted>@online.de" password=<hidden>]
Wed Jan  1 20:38:58 2025 daemon.debug pppd[9486]: rcvd [LCP EchoRep id=0x0 magic=0x21930b9]
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: rcvd [PAP AuthAck id=0x1 ""]
Wed Jan  1 20:38:59 2025 daemon.notice pppd[9486]: PAP authentication succeeded
Wed Jan  1 20:38:59 2025 daemon.notice pppd[9486]: peer from calling number <redacted> authorized
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: sent [IPV6CP ConfReq id=0x1 <addr fe80::8c27:144a:ce2f:4a7d>]
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: rcvd [IPCP ConfReq id=0x9a <addr 62.155.243.253>]
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: sent [IPCP ConfAck id=0x9a <addr 62.155.243.253>]
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: rcvd [IPCP ConfNak id=0x1 <addr 79.254.125.161> <ms-dns1 217.237.148.102> <ms-dns2 217.237.151.115>]
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: sent [IPCP ConfReq id=0x2 <addr 79.254.125.161> <ms-dns1 217.237.148.102> <ms-dns2 217.237.151.115>]
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: rcvd [IPV6CP ConfReq id=0x58 <addr fe80::2aa2:4bff:fef2:0dfe>]
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: sent [IPV6CP ConfAck id=0x58 <addr fe80::2aa2:4bff:fef2:0dfe>]
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: rcvd [IPCP ConfAck id=0x2 <addr 79.254.125.161> <ms-dns1 217.237.148.102> <ms-dns2 217.237.151.115>]
Wed Jan  1 20:38:59 2025 daemon.notice pppd[9486]: local  IP address 79.254.125.161
Wed Jan  1 20:38:59 2025 daemon.notice pppd[9486]: remote IP address 62.155.243.253
Wed Jan  1 20:38:59 2025 daemon.notice pppd[9486]: primary   DNS address 217.237.148.102
Wed Jan  1 20:38:59 2025 daemon.notice pppd[9486]: secondary DNS address 217.237.151.115
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: Script /lib/netifd/ppp-up started (pid 9535)
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::8c27:144a:ce2f:4a7d>]
Wed Jan  1 20:38:59 2025 daemon.notice pppd[9486]: local  LL address fe80::8c27:144a:ce2f:4a7d
Wed Jan  1 20:38:59 2025 daemon.notice pppd[9486]: remote LL address fe80::2aa2:4bff:fef2:0dfe
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: Script /lib/netifd/ppp6-up started (pid 9536)
Wed Jan  1 20:38:59 2025 daemon.notice netifd: Network device 'pppoe-wan' link is up
Wed Jan  1 20:38:59 2025 daemon.notice netifd: Network alias 'pppoe-wan' link is up
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: Script /lib/netifd/ppp6-up finished (pid 9536), status = 0x0
Wed Jan  1 20:38:59 2025 daemon.debug pppd[9486]: Script /lib/netifd/ppp-up finished (pid 9535), status = 0x1
Wed Jan  1 20:38:59 2025 user.notice firewall: Reloading firewall due to ifup of wan (pppoe-wan)
Wed Jan  1 20:39:00 2025 user.notice firewall: Reloading firewall due to ifupdate of wan (pppoe-wan)
Wed Jan  1 20:39:02 2025 user.notice firewall: Reloading firewall due to ifup of wan6 (pppoe-wan)
Wed Jan  1 20:39:05 2025 user.notice firewall: Reloading firewall due to ifup of wan6 (pppoe-wan)

EDIT: Attached Screenshot Interfaces

According to whois that is a Telekom IP address

Mmmh, that looks like 1&1 is using Telekom Wholesale Internet Access here (WIA) that is that is a telekom link that is operated by telekom and 1& just sends you the bill... (which essentially means ds-lite is out for sure)

Let's check IPv4 and IPv6 (will likely fail)

# you can run these on the router, but you might need to install the following packets, which might get tricky over your non working access link:
opkg update , opkg install iputils-tracepath mtr-json
# these will take a bit
tracepath -b -4 one.one.one.one
tracepath -b -6 one.one.one.one
# these will take each over 100 seconds...
mtr -ezb4w -c 100 -o LSNBAWVJMXI one.one.one.one
mtr -ezb6w -c 100 -o LSNBAWVJMXI one.one.one.one

Thanks for your patience, just needed a bit time to collect all the dependencies and install the packages offline.

Here is the result, unfortunately this lead me not really far...

tracepath
root@danieldmz:~# tracepath -b -4 one.one.one.one
 1?: [LOCALHOST]                      pmtu 1492
 1:  no reply
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1492
     Resume: pmtu 1492 
root@danieldmz:~# tracepath -b -6 one.one.one.one
 1?: [LOCALHOST]                       72.000ms pmtu 1492
 1:  no reply
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1492
     Resume: pmtu 1492
mtr
root@danieldmz:~# mtr -ezb4w -c 100 -o LSNBAWVJMXI one.one.one.one
Start: 2025-01-03T15:05:32+0100
HOST: danieldmz          Loss%   Snt  Last  Best   Avg  Wrst StDev Jttr Javg Jmax Jint
root@danieldmz:~# mtr -ezb6w -c 100 -o LSNBAWVJMXI one.one.one.one
Start: 2025-01-03T15:09:40+0100
HOST: danieldmz          Loss%   Snt  Last  Best   Avg  Wrst StDev Jttr Javg Jmax Jint

Interestingly enough DNS resolution seems to work, as already stated in my initial question:

root@danieldmz:~# nslookup one.one.one.one
Server:		127.0.0.1
Address:	127.0.0.1:53

Non-authoritative answer:
Name:	one.one.one.one
Address: 1.1.1.1
Name:	one.one.one.one
Address: 1.0.0.1

Non-authoritative answer:
Name:	one.one.one.one
Address: 2606:4700:4700::1001
Name:	one.one.one.one
Address: 2606:4700:4700::1111

That is indeed all you need...since 1und1 are using the Telekom lines.

Try to follow this advise and change the PPPoE Username be adding an H to the front:
option username 'H1und1/<redacted>@online.de'
as that seems required for VDSL links, according to the 1&1 docs.

I tried the following, hope this is what you mean:

└─▶ $ diff -u network_old network 
--- network_old	2025-01-03 16:21:13.145271344 +0100
+++ network	2025-01-03 16:21:13.145271344 +0100
@@ -51,9 +51,3 @@
 	option device '@wan'
 	option proto 'dhcpv6'
 
-config device
-	option type '8021ad'
-	option ifname 'dsl0'
-	option vid '7'
-	option name 'dsl0.7'
-

But as I mentioned above it seems that this is a step back, because unfortunately no connection could be established over PPPoE anymore :sob:

I corrected that, authorization works:

Fri Jan  3 16:01:22 2025 daemon.debug pppd[2622]: sent [PAP AuthReq id=0x1 user="H1und1/<redacted>@online.de" password=<hidden>]
Fri Jan  3 16:01:22 2025 daemon.debug pppd[2622]: rcvd [LCP EchoRep id=0x0 magic=0x56b31ec1]
Fri Jan  3 16:01:22 2025 daemon.debug pppd[2622]: rcvd [PAP AuthAck id=0x1 ""]
Fri Jan  3 16:01:22 2025 daemon.notice pppd[2622]: PAP authentication succeeded

Unfortunately this does not help with my ping/traceroute issues.

Please repost your current network config.

Network config without dsl0.7 looks like this:

network without dsl0.7 device
root@danieldmz:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd3e:cbe5:802c::/48'

config atm-bridge 'atm'
	option vpi '1'
	option vci '32'
	option encaps 'llc'
	option payload 'bridged'
	option nameprefix 'dsl'

config dsl 'dsl'
	option annex 'j'
	option tone 'bv'
	option ds_snr_offset '0'
	option firmware '/lib/firmware/vdsl.bin'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config device
	option name 'dsl0'
	option macaddr '1C:ED:6F:41:AE:38'

config interface 'wan'
	option device 'dsl0.7'
	option proto 'pppoe'
	option username 'H1und1/<redacted>@online.de'
	option password '<redacted>'
	option ipv6 '1'

config interface 'wan6'
	option device '@wan'
	option proto 'dhcpv6'


So here are the relevant nuggets from my /etc/config/network on my TF7520 (which acts as bridged-modem):

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdcd:4cf3:765d::/48'

config atm-bridge 'atm'
	option vpi '1'
	option vci '32'
	option encaps 'llc'
	option payload 'bridged'
	option nameprefix 'dsl'

config dsl 'dsl'
	option tone 'b'
	option annex 'b'
	option ds_snr_offset '0'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option proto 'static'
	option ip6assign '60'
	option device 'br-lan.42'
	list ipaddr '192.168.100.1/24'

config device
	option name 'dsl0'
	option macaddr '98:9B:CB:C0:F5:BB'

config interface 'wan'
	option device 'dsl0'
	option proto 'none'

config interface 'wan6'
	option device '@wan'
	option proto 'dhcpv6'

config bridge-vlan
	option device 'br-lan'
	option vlan '42'
	list ports 'lan1:t'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config bridge-vlan
	option device 'br-lan'
	option vlan '7'
	list ports 'lan1:t*'

config device
	option type '8021q'
	option ifname 'dsl0'
	option vid '7'
	option name 'dsl0.7'

config device
	option type 'bridge'
	option name 'br-dsl'
	list ports 'br-lan.7'
	list ports 'dsl0.7'
	option bridge_empty '1'

config interface 'MODEM'
	option proto 'none'
	option device 'br-dsl'

and here what I use on my router (telekom dsl link resold via O2, which uses L3-BSA):

config interface 'wan'
	option hostname 'turris'
	option ipv6 '1'
	option proto 'pppoe'
	option username 'USER@s93.bbi-o2.de'
	option password 'PASSWORD'
	option force_link '1'
	option device 'eth2.7'

This combination works for me... but it looks quite close to yours, so maybe give 1&1 a call and tell them that no real traffic passes through your link?

Thank you for sharing your config!
Ah, I see, because of the bridge mode you need the vlan-bridge parts.
That seemed different, but because of our different use cases.

This is a good advice to call the 1&1 support. Would be sad if debugging on the CPE side does not help when there could be also something on the ISP side.

I try to post my findings as soon as I reach the support. :+1:

Maybe this was a stupid error in the end:
After a comparison between my router with OEM firmware and the new router with OpenWrt I realized that the tcpdumps of my dsl0 interface where quite different. Which lead me into the direction to think about VLAN tagging again.

Also the 1und1 support confirmed that although the DSL sync parameters where negotiated I was not successfully authenticated. Hence the issue with normal internet traffic.

Solution:
Use 802.1q (as also the wiki says everywhere) instead of 802.1ad network standard for the dsl0.7 interface!

Nevertheless thanks for your help anyway, because ruling out other possibilities always helps to narrow down the issue.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.