Re: PPPoE (5.9 still): https gets stuck

2016-09-20 Thread Harald Dunkel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Stuart,

On 09/16/16 14:08, Stuart Henderson wrote:
> On 2016-09-14, Harald Dunkel  wrote:
>> 
>> AFAIU setting the max-mss affects TCP traffic only (e.g. HTTPS). It defines 
>> the maximum payload block size on sending and receiving(!) data via TCP. UDP 
>> and other protocols are not affected. Very important to know if you run 
>> IPsec or openvpn or other non-TCP protocols over the PPPoE tunnel.
>> 
>> The mtu works on ethernet level, giving the maximum packet size to send(!) 
>> to the next hop without fragmentation, regardless if the higher level 
>> protocol is TCP, UDP, ESP or whatever.
> 
> You are supposed to be able to get large packets through; routers are meant 
> to either fragment or send ICMP "frag-needed" messages to allow the end host 
> to do it. But some idiots misconfigure their firewalls to drop the necessary 
> ICMP messages causing breakage to some sites.
> 

Would you say that setting "scrub (no-df random-id)" is best practice
for IPv4 traffic forwarded into the internet?

> 
> The MSS in the TCP handshake is based on the MTU on the outgoing route from 
> the end host. So if you have
> 
> router - pppoe0 - 1492 router - internal - 1500 host - internal - 1500
> 
> the host will base its calculation on 1500 not 1492.
> 
> "scrub (max-mss ..)" will cap this in the TCP handshake (and adjust checksums 
> to match).
> 

I figured this out, but maybe pf.conf(5) could be more explicit on
this detail, too?

> However: if you have working 1500 MTU pppoe via baby jumbos on the ethernet 
> interface, "scrub (max-mss..)" shouldn't fix anything. The restricted MTU is 
> usually towards the "client" side of things rather than towards the server, 
> plus if it's towards the server then many people will be affected
> so it's easier for the server admin to spot problems.
> 
>> My current configuration uses both baby jumbo frames (mtu = 1508 on re0 and 
>> mtu = 1500 on pppoe0) and "scrub (max-mss 1452)" for TCP traffic on pppoe0 
>> (1500 bytes - 40 bytes TCP/IP header - 8 bytes PPPoE frame).
> 
> You should not need both. If baby jumbos are working correctly (you can "ping 
> -D -s 1472 $some_internet_host" from an end host) then you should be able to 
> get rid of the scrub. If they are not working correctly, you should get rid 
> of the baby jumbo config and just use 1492, this will at least
> fix things for larger packets in the normal case where there is no bad 
> firewall config in the way.
> 

Deutsche Telekom seems to support baby jumbo frames ("Dumbos"? :-) )
on my side, but they told me that they don't actively support per-
customer MTUs on their BNGs.


Thanx for your detailed response. That was really helpful.


Regards
Harri

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJX4h2HAAoJEAqeKp5m04HLwokH/2+c7vGc7Wn21M3qPBbDqjmw
/qJKQ9CrQUUXnQOcEPl9eMqVdM6hLJO6OBMpUoKWvIa9vxuSBy79IXIXv0vpXbtv
aC40rHUJViG3EB1YX0KLIpF7p0iAgv9+5vr7/7obmHfBSUogZAcARL0TwrAU9CAN
/gVMkfiYIyJyxRwmw194QoNmrfq33wXAC2QDWJANhRLTokPy6i1H9dOXNVuxpIs9
d/Ua0bvELT6Ak0xIieShWzL37wwnnu1aHS9bT/9utHU6JPSGPm85lPVpiFhgJU8J
7DxClVeRy4IIQ0FvxQgGotuT+dXZFqV/1D7WGfqu4F6TgrnCFYk9e/VH918Oeyw=
=2oHP
-END PGP SIGNATURE-



Re: PPPoE (5.9 still): https gets stuck

2016-09-16 Thread Stuart Henderson
On 2016-09-14, Harald Dunkel  wrote:
>
> Hi folks,
>
> On 09/13/2016 02:58 PM, Stuart Henderson wrote:
>> 
>> See "MTU/MSS ISSUES" in pppoe(4).
>> 
> indeed, its documented, but its also a little bit misleading.
> Reading the man page I had the first impression that modifying
> the mtu and max-mss are equally effective. Apparently they
> are not.
>
> AFAIU setting the max-mss affects TCP traffic only (e.g.
> HTTPS). It defines the maximum payload block size on sending
> and receiving(!) data via TCP. UDP and other protocols are not
> affected. Very important to know if you run IPsec or openvpn
> or other non-TCP protocols over the PPPoE tunnel.
>
> The mtu works on ethernet level, giving the maximum packet
> size to send(!) to the next hop without fragmentation,
> regardless if the higher level protocol is TCP, UDP, ESP or
> whatever.

You are supposed to be able to get large packets through; routers
are meant to either fragment or send ICMP "frag-needed" messages
to allow the end host to do it. But some idiots misconfigure their
firewalls to drop the necessary ICMP messages causing breakage to
some sites.

In practice, people configuring non-TCP services often try to keep
packets below the common breakage points (especially 1492)..

> Point is, setting the MTU does not affect the data flow from
> the peer back to your site. AFAIU this made the difference
> in this case. Reducing the max-mss seems to be a workaround
> for some networking issue I cannot fix.

The MSS in the TCP handshake is based on the MTU on the outgoing
route from the end host. So if you have

router - pppoe0 - 1492
router - internal - 1500
host - internal - 1500

the host will base its calculation on 1500 not 1492.

"scrub (max-mss ..)" will cap this in the TCP handshake (and adjust
checksums to match).

However: if you have working 1500 MTU pppoe via baby jumbos on
the ethernet interface, "scrub (max-mss..)" shouldn't fix anything.
The restricted MTU is usually towards the "client" side of things
rather than towards the server, plus if it's towards the server
then many people will be affected so it's easier for the server
admin to spot problems.

> My current configuration uses both baby jumbo frames (mtu = 1508
> on re0 and mtu = 1500 on pppoe0) and "scrub (max-mss 1452)" for
> TCP traffic on pppoe0 (1500 bytes - 40 bytes TCP/IP header -
> 8 bytes PPPoE frame).

You should not need both. If baby jumbos are working correctly
(you can "ping -D -s 1472 $some_internet_host" from an end host)
then you should be able to get rid of the scrub. If they are not
working correctly, you should get rid of the baby jumbo config
and just use 1492, this will at least fix things for larger
packets in the normal case where there is no bad firewall config
in the way.



Re: PPPoE (5.9 still): https gets stuck

2016-09-14 Thread Harald Dunkel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi folks,

On 09/13/2016 02:58 PM, Stuart Henderson wrote:
> 
> See "MTU/MSS ISSUES" in pppoe(4).
> 
indeed, its documented, but its also a little bit misleading.
Reading the man page I had the first impression that modifying
the mtu and max-mss are equally effective. Apparently they
are not.

AFAIU setting the max-mss affects TCP traffic only (e.g.
HTTPS). It defines the maximum payload block size on sending
and receiving(!) data via TCP. UDP and other protocols are not
affected. Very important to know if you run IPsec or openvpn
or other non-TCP protocols over the PPPoE tunnel.

The mtu works on ethernet level, giving the maximum packet
size to send(!) to the next hop without fragmentation,
regardless if the higher level protocol is TCP, UDP, ESP or
whatever.

Point is, setting the MTU does not affect the data flow from
the peer back to your site. AFAIU this made the difference
in this case. Reducing the max-mss seems to be a workaround
for some networking issue I cannot fix.

My current configuration uses both baby jumbo frames (mtu = 1508
on re0 and mtu = 1500 on pppoe0) and "scrub (max-mss 1452)" for
TCP traffic on pppoe0 (1500 bytes - 40 bytes TCP/IP header -
8 bytes PPPoE frame).


Regards
Harri


-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJX2XrzAAoJEAqeKp5m04HL6XcH/AsbZ4Cw0d/h3gwJGLYsk5/m
XehdN7Sc6c8yHRksVCShC59V24NO89Xx+/SM+oVz6cXrszhDKw2K0wkBhMj3+aRV
n6HUImpbkfnDE0TraxllcmDOljADLJut95LAetVkufiSIGsZVeofyx6JXdoW9xld
hHVGR90b31a4FdO2PZE9gn2Cq1vMroTOdhXzjvqbIPGoiBz1ojaETJbTZTYtbfDp
HeK0Sm1NMRtTZDO0IB/T+1G4CM/Ocmdtp6Pl1sIjsojJF5JKltt8J8D4gPFIS7dd
dTk81hTVAXJuTb5oMWizRyq95+5ZarPbMThBtgHDYotIafc1ZpuHqrAvuQcYmRs=
=QB+k
-END PGP SIGNATURE-



Re: PPPoE (5.9 still): https gets stuck

2016-09-14 Thread Christian Weisgerber
On 2016-09-13, "Peter J. Philipp"  wrote:

> This interests me because I'm switching to Deutsche Telekom in february
> 2017.  I did research back in
>
> march or april of 2016 on how to connect to Telekom with an allnet vdsl
> modem and I came across hints that Telekom uses vlan tagging.  I made
> notes but I don't know how updated they are, but you

That setup is straightforward.

The Allnet VDSL modem doesn't require any configuration; you just
plug it in.  (The device is actually a fully-fledged CPE with the
usual home gateway functionality, but that's all disabled by default.)

On the OpenBSD gateway, I have this:

==> hostname.em2 <==
description WAN
up

==> hostname.vlan0 <==
description "T-Online Internet"
vlan 7 vlandev em2

==> hostname.pppoe0 <==
description T-Online
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev vlan0 authproto pap \
authname m...@t-online.de authkey  up
dest 0.0.0.1
!route add default -ifp \$if 0.0.0.1


The authentication information is derived like above from the four
magic numbers provided by Telekom:

"Zugangsnummer" 
"Kennwort"  
"Anschlusskennung"  
"Mitbenutzernummer" 

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Harald Dunkel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Markus,

On 09/13/16 13:07, Harald Dunkel wrote:
> Hi Markus,
> 
> On 09/13/2016 12:42 PM, Markus Hennecke wrote:
>> 
>> Damn. Of course without this line it won't work:
>> 
>> match out on $ext_if all scrub (max-mss 1440)
>> 
> 
> I have
> 
> match in on pppoe0 scrub (no-df random-id max-mss 1440)
> 
> but no "match out". I will check.
> 

Congratulations, you are the winner. Replacing the

match in on pppoe0 scrub (max-mss 1440)
by
match on pppoe0 scrub (max-mss 1440)

did the trick.

I tried the suggested jumbo mtu approach, too, but this
didn't work for me, even though tracepath showed
pmtu = 1500 between my desktop PC and www.telekom.de.

I highly appreciate the helpful suggestions of all.


Regards
Harri

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJX2Ck/AAoJEAqeKp5m04HLwE8H/1WGGtU8wKXzEFQVbU3+J1Eg
pH/CjrySI9zr/8vTaEV/HtrEMTj3PS1AR+CFA4Tjl2yOJRy/5zoRa18jwDI68g2K
Yu99LgRQ543bPf1mB028aBl8AHyh0hnL1jZ8gp4GvKoGW5cp9B0R1OJH6PSlmi85
XH+zhj/jWXuHNzwgabfcJlMjQjQ7Fwzv0VcTQfR6Rry5rW5nyZGa9+54a4DWDtBm
mqm0zF8Sv/OI3LthuKGYcjZFnsv94SVLsaCH73GA0dqEep24TqNL6Evs+T1ixc5S
me7JMQWNH/QZDdhpJET+qJbeEBYn7Y0GNCf7NGjW78wzcM0iU4+9G7YezrBwASI=
=W64b
-END PGP SIGNATURE-



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Stuart Henderson
On 2016-09-13, Harald Dunkel  wrote:
> Hi Daniel,
>
> On 09/13/2016 12:00 PM, Daniel Gillen wrote:
>> 
>> I had a similar problem. In my case it had to do with Path MTU issues.
>> 
>> This site f.ex.: http://test-ipv6.com/ will check for that.
>> 
>> The solution for me was to switch to "jumbo" frames below the pppoe
>> device (1508 bytes if I remember correctly) and set the pppoe's MTU to 1500.
>> 
>> Daniel
>> 
>
> I will surely try asap, but I wonder if this is allowed?
> RFC 2516 says "... the PPP MTU MUST NOT be greater than
> 1492". https://tools.ietf.org/html/rfc2516
>
> ???

RFC 4638 supercedes this. Some providers + some xDSL bridges support it,
some don't, you have to try it to find out. And you have to actively test
rather than just see if it connects; not all ISPs have paths between LNS
and LAC that can cope with baby jumbos - also sometimes it can fail if
there are changes to the ISP's internal network or their L2/L3 providers.



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Stuart Henderson
On 2016-09-13, Harald Dunkel  wrote:
> Hi folks,
>
> I am using an openbsd (5.9) box as gateway/firewall to the
> internet. ISP is Deutsche Telekom. In between is a Vigor 130
> VDSL2 modem, configured to PPPoE passthrough. The PPPoE
> connection is initiated on the openbsd box.
>
> Problem: https via the tunnel gets stuck for some sites, e.g.
> https://telekom.de/ (please note the irony). Other sites work
> fine, e.g. https://kundencenter.telekom.de/. I tried a lot of
> clients: chrome, firefox, Safari, wget, etc. and all platforms
> I have at home.
>
> Other services (http, smtp, dns, ntp, vnc, ...) seem to work
> flawless.
>
> The problem came up with the migration from ADSL to VDSL this
> weekend. The gateway wasn't changed, but I wonder if there are
> some issues or pitfalls with PPPoE and fragmented packages or
> whatever, possibly breaking https negotiation?
>
>
> Every helpful comment is highly appreciated
> Harri
>
>

See "MTU/MSS ISSUES" in pppoe(4).



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Kapfhammer, Stefan
Hello Harald,

use the setup from there:

http://www.un.geeig.net/openbsd-vdsl.html

‎if you don't have IPTV, leave everything after
'ping' probe and reboot out. I didn't use
the 5 sysctl settings.

Update ALLNET Bridge to at least fw c46a,
reboot the device and reset to factory defaults.
Don't change anything here after defaults apply!

Wait for VDSL synchronization ‎(LINK/WAN)
permanent green LED on.‎ Then start soekris,
alix, apu/2, whatever is after the bridge.

My setup:
ALLNET ALL-BM100VDSL2V‎ with fw c46a
APU2B4 previously with OpenBSD 5.9 now 6.0
with fw 20160311
Grandstream HT-702 ATA ‎with fw 1.82
Telekom VDSL 50 Business Premium

Works well, even with https connections.
Good luck.


Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht
Von: Harald Dunkel
Gesendet: Dienstag, 13. September 2016 13:08
An: misc@openbsd.org
Betreff: Re: PPPoE (5.9 still): https gets stuck


Hi Markus,

On 09/13/2016 12:42 PM, Markus Hennecke wrote:
>>
>> I use the same VDSL modem with Deutsche Telekom and can reach
>> https://telekom.de/
>> The only MTU related setting in pf.conf seems to be this:
>>
>> ext_if = pppoe0
>> match in on $ext_if all scrub (no-df max-mss 1440)
>>
>> It is an old soekris, which does not support gbit ethernet.
>> I do the VLAN tagging on the OpenBSD router, I think I disabled the
>> automatic tagging the modem supports.
>>
>> Regards,
>> Markus
>>
>
> Damn. Of course without this line it won't work:
>
> match out on $ext_if all scrub (max-mss 1440)
>

I have

match in on pppoe0 scrub (no-df random-id max-mss 1440)

but no "match out". I will check.

Unfortunately I cannot check right now, since I use this line
to access my home network.


Thanx very much
Harri



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Harald Dunkel
Hi Markus,

On 09/13/2016 12:42 PM, Markus Hennecke wrote:
>>
>> I use the same VDSL modem with Deutsche Telekom and can reach
>> https://telekom.de/
>> The only MTU related setting in pf.conf seems to be this:
>>
>> ext_if = pppoe0
>> match in on $ext_if all scrub (no-df max-mss 1440)
>>
>> It is an old soekris, which does not support gbit ethernet.
>> I do the VLAN tagging on the OpenBSD router, I think I disabled the
>> automatic tagging the modem supports.
>>
>> Regards,
>> Markus
>>
> 
> Damn. Of course without this line it won't work:
> 
> match out on $ext_if all scrub (max-mss 1440)
> 

I have

match in on pppoe0 scrub (no-df random-id max-mss 1440)

but no "match out". I will check.

Unfortunately I cannot check right now, since I use this line
to access my home network.


Thanx very much
Harri



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Harald Dunkel
Hi Daniel,

On 09/13/2016 12:00 PM, Daniel Gillen wrote:
> 
> I had a similar problem. In my case it had to do with Path MTU issues.
> 
> This site f.ex.: http://test-ipv6.com/ will check for that.
> 
> The solution for me was to switch to "jumbo" frames below the pppoe
> device (1508 bytes if I remember correctly) and set the pppoe's MTU to 1500.
> 
> Daniel
> 

I will surely try asap, but I wonder if this is allowed?
RFC 2516 says "... the PPP MTU MUST NOT be greater than
1492". https://tools.ietf.org/html/rfc2516

???


Regards
Harri



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Markus Hennecke

Am 13.09.2016 um 12:38 schrieb Markus Hennecke:

Am 13.09.2016 um 11:51 schrieb Harald Dunkel:

Hi folks,

I am using an openbsd (5.9) box as gateway/firewall to the
internet. ISP is Deutsche Telekom. In between is a Vigor 130
VDSL2 modem, configured to PPPoE passthrough. The PPPoE
connection is initiated on the openbsd box.

Problem: https via the tunnel gets stuck for some sites, e.g.
https://telekom.de/ (please note the irony). Other sites work
fine, e.g. https://kundencenter.telekom.de/. I tried a lot of
clients: chrome, firefox, Safari, wget, etc. and all platforms
I have at home.

Other services (http, smtp, dns, ntp, vnc, ...) seem to work
flawless.

The problem came up with the migration from ADSL to VDSL this
weekend. The gateway wasn't changed, but I wonder if there are
some issues or pitfalls with PPPoE and fragmented packages or
whatever, possibly breaking https negotiation?


Every helpful comment is highly appreciated
Harri



I use the same VDSL modem with Deutsche Telekom and can reach
https://telekom.de/
The only MTU related setting in pf.conf seems to be this:

ext_if = pppoe0
match in on $ext_if all scrub (no-df max-mss 1440)

It is an old soekris, which does not support gbit ethernet.
I do the VLAN tagging on the OpenBSD router, I think I disabled the
automatic tagging the modem supports.

Regards,
Markus



Damn. Of course without this line it won't work:

match out on $ext_if all scrub (max-mss 1440)

Regards,
Markus



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Markus Hennecke

Am 13.09.2016 um 11:51 schrieb Harald Dunkel:

Hi folks,

I am using an openbsd (5.9) box as gateway/firewall to the
internet. ISP is Deutsche Telekom. In between is a Vigor 130
VDSL2 modem, configured to PPPoE passthrough. The PPPoE
connection is initiated on the openbsd box.

Problem: https via the tunnel gets stuck for some sites, e.g.
https://telekom.de/ (please note the irony). Other sites work
fine, e.g. https://kundencenter.telekom.de/. I tried a lot of
clients: chrome, firefox, Safari, wget, etc. and all platforms
I have at home.

Other services (http, smtp, dns, ntp, vnc, ...) seem to work
flawless.

The problem came up with the migration from ADSL to VDSL this
weekend. The gateway wasn't changed, but I wonder if there are
some issues or pitfalls with PPPoE and fragmented packages or
whatever, possibly breaking https negotiation?


Every helpful comment is highly appreciated
Harri



I use the same VDSL modem with Deutsche Telekom and can reach 
https://telekom.de/

The only MTU related setting in pf.conf seems to be this:

ext_if = pppoe0
match in on $ext_if all scrub (no-df max-mss 1440)

It is an old soekris, which does not support gbit ethernet.
I do the VLAN tagging on the OpenBSD router, I think I disabled the 
automatic tagging the modem supports.


Regards,
Markus



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Harald Dunkel
Hi Peter,

On 09/13/2016 12:13 PM, Peter J. Philipp wrote:
> 
> can try this:
> 
> T-Online uses vlan tag 7, IP-TV uses vlan tag 8.  So it depends on your
> plan I guess?  I'd appreciate if someone told me if this information is
> outdated but I'm probably going to have to ask in february again
> anyhow.  Apparently my allnet vdsl modem can vlan tag and give a
> passthrough to the router, I don't know if the Draytek Vigor can do this.
> 

Nice hint (esp. about vlan8), but please note that the problem
is on or above the PPPoE layer. I have a working tunnel (except
for https).

Vlan tagging (7) appears to be handled by the modem in its default
configuration.


Thanx very much for your hint

Harri



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Peter J. Philipp
Hello Harri,

This interests me because I'm switching to Deutsche Telekom in february
2017.  I did research back in

march or april of 2016 on how to connect to Telekom with an allnet vdsl
modem and I came across hints that Telekom uses vlan tagging.  I made
notes but I don't know how updated they are, but you

can try this:

T-Online uses vlan tag 7, IP-TV uses vlan tag 8.  So it depends on your
plan I guess?  I'd appreciate if someone told me if this information is
outdated but I'm probably going to have to ask in february again
anyhow.  Apparently my allnet vdsl modem can vlan tag and give a
passthrough to the router, I don't know if the Draytek Vigor can do this.

Regards,

-peter

On 09/13/16 11:51, Harald Dunkel wrote:
> Hi folks,
>
> I am using an openbsd (5.9) box as gateway/firewall to the
> internet. ISP is Deutsche Telekom. In between is a Vigor 130
> VDSL2 modem, configured to PPPoE passthrough. The PPPoE
> connection is initiated on the openbsd box.
>
> Problem: https via the tunnel gets stuck for some sites, e.g.
> https://telekom.de/ (please note the irony). Other sites work
> fine, e.g. https://kundencenter.telekom.de/. I tried a lot of
> clients: chrome, firefox, Safari, wget, etc. and all platforms
> I have at home.
>
> Other services (http, smtp, dns, ntp, vnc, ...) seem to work
> flawless.
>
> The problem came up with the migration from ADSL to VDSL this
> weekend. The gateway wasn't changed, but I wonder if there are
> some issues or pitfalls with PPPoE and fragmented packages or
> whatever, possibly breaking https negotiation?
>
>
> Every helpful comment is highly appreciated
> Harri



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Daniel Gillen
On 13/09/2016 11:51, Harald Dunkel wrote:
> Hi folks,
> 
> I am using an openbsd (5.9) box as gateway/firewall to the
> internet. ISP is Deutsche Telekom. In between is a Vigor 130
> VDSL2 modem, configured to PPPoE passthrough. The PPPoE
> connection is initiated on the openbsd box.
> 
> Problem: https via the tunnel gets stuck for some sites, e.g.
> https://telekom.de/ (please note the irony). Other sites work
> fine, e.g. https://kundencenter.telekom.de/. I tried a lot of
> clients: chrome, firefox, Safari, wget, etc. and all platforms
> I have at home.
> 
> Other services (http, smtp, dns, ntp, vnc, ...) seem to work
> flawless.
> 
> The problem came up with the migration from ADSL to VDSL this
> weekend. The gateway wasn't changed, but I wonder if there are
> some issues or pitfalls with PPPoE and fragmented packages or
> whatever, possibly breaking https negotiation?
> 
> 
> Every helpful comment is highly appreciated
> Harri
> 

Hi

I had a similar problem. In my case it had to do with Path MTU issues.

This site f.ex.: http://test-ipv6.com/ will check for that.

The solution for me was to switch to "jumbo" frames below the pppoe
device (1508 bytes if I remember correctly) and set the pppoe's MTU to 1500.

Daniel