Community discussions

MikroTik App
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 11:56 am

Hello! I am trying to set up IPv6 with my ISP. I've set up DHCP client on PPPoE interface which is able to get routable /56 prefix. Next I've set up interface address with advertising - now all v6-capable devices in my net are getting v6 addresses from this pool, they're able to ping each other and remote addresses (like 2600::). I am able to ping this devices from anywhere too. Next I've set up DoH Cloudflare DNS so now every device is able to resolve and ICMP ping all external resources (like ipv6.google.com). And... I'm stuck! ICMP works but no TCP traffic is flowing, tools like curl just throw "connection refused" error.

My config:
# may/03/2021 11:44:43 by RouterOS 6.48.2
# software id = T6SD-1421
#
# model = 435G
# serial number = 2E2E0168B671
/ipv6 dhcp-client
add add-default-route=yes comment="Rostelecom IPv6 DHCP" interface=pppoe-out1 pool-name=rtelecomv6 pool-prefix-length=56 request=prefix use-peer-dns=no

/ipv6 address
add address=::d6ca:6dff:fe11:e72e comment="Address from IPv6 Rostelecom DHCP Pool" eui-64=yes from-pool=rtelecomv6 interface=bridge1

/ipv6 nd
Flags: X - disabled, I - invalid, * - default 
 0  * interface=all ra-interval=3m20s-10m ra-delay=3s mtu=unspecified reachable-time=unspecified retransmit-interval=unspecified ra-lifetime=30m hop-limit=unspecified advertise-mac-address=yes 
      advertise-dns=yes managed-address-configuration=no other-configuration=no

/interface pppoe-client
add add-default-route=yes allow=pap,chap,mschap2 comment="PPPoE WAN" disabled=no interface=ether1 max-mru=1492 max-mtu=1492 name=pppoe-out1 user=someuser
Any help is appreciated...
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11439
Joined: Thu Mar 03, 2016 10:23 pm

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 4:03 pm

/ipv6 dhcp-client
add add-default-route=yes comment="Rostelecom IPv6 DHCP" interface=pppoe-out1 pool-name=rtelecomv6 pool-prefix-length=56 request=prefix use-peer-dns=no

Don't set pool prefix length. It's not about prefix length you're getting from ISP (they give you whatever they decide and don't give a sh..t about what you'd like), it's about size of your own IPv6 subnets. Default setting is 64 which should be just fine.
 
User avatar
jvanhambelgium
Forum Veteran
Forum Veteran
Posts: 985
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 4:53 pm

What about the IPv6 firewal rules ? Can you list them ?
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 5:14 pm

/ipv6 dhcp-client
add add-default-route=yes comment="Rostelecom IPv6 DHCP" interface=pppoe-out1 pool-name=rtelecomv6 pool-prefix-length=56 request=prefix use-peer-dns=no

Don't set pool prefix length. It's not about prefix length you're getting from ISP (they give you whatever they decide and don't give a sh..t about what you'd like), it's about size of your own IPv6 subnets. Default setting is 64 which should be just fine.
I've stumbled upon this https://version6.ru/isp resource with some info on IPv6 in russia, it states Rostelecom ISP usually gives /56 so I set it there. Removed it now, so I get this pool:
0 D rtelecomv6                                      2a02:ad8:1484:7a00::/56                                64 23h54m40s
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 5:19 pm

What about the IPv6 firewal rules ? Can you list them ?
I've tried withot any rules at all but now firewall has this:
add action=drop chain=input comment="Drop invalid connections" connection-state=invalid
add action=accept chain=input comment="Accept established connections (input)" connection-state=established,related \
    in-interface-list=WAN
add action=accept chain=forward comment="Accept routed established connections (forward)" connection-state=established,related \
    in-interface-list=WAN out-interface-list=LAN
add action=accept chain=input comment="Accept incoming ICMPv6 with ratelimiting" limit=50,5:packet protocol=icmpv6
add action=accept chain=forward comment="Accept routed ICMPv6 with ratelimiting" limit=50,5:packet protocol=icmpv6
add action=accept chain=input comment="Accept DHCPv6" dst-port=546 in-interface-list=WAN protocol=udp
add action=accept chain=forward comment="Accept everyhthing from LAN to WAN" in-interface-list=LAN out-interface-list=WAN
add action=drop chain=input comment="Drop any other incoming traffic"
add action=drop chain=forward comment="Drop any other routed traffic"
 
User avatar
jvanhambelgium
Forum Veteran
Forum Veteran
Posts: 985
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 5:44 pm

Looks ok to me for this case, do you have "log" flag enabled on the last 2 rules ??

add action=drop chain=input comment="Drop any other incoming traffic"
add action=drop chain=forward comment="Drop any other routed traffic"

If not, please do so and look if anything is displayed in the log when you try TCP-connection from the local LAN -> to the remote host.
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 6:09 pm

Looks ok to me for this case, do you have "log" flag enabled on the last 2 rules ??

add action=drop chain=input comment="Drop any other incoming traffic"
add action=drop chain=forward comment="Drop any other routed traffic"

If not, please do so and look if anything is displayed in the log when you try TCP-connection from the local LAN -> to the remote host.
Nope, when I'm trying to curl ipv6.google.com it just stays empty (I enabled logging). So if everything looks fine, probably ISP is filtering v6 communications for some reason (which is strange-having routable v6 answering icmp echo from both sides but filtering tcp). I tried to communicate with the support but still nothing...
 
User avatar
jvanhambelgium
Forum Veteran
Forum Veteran
Posts: 985
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 6:51 pm

If you don't have much Ipv6 traffic just enable the logging also on the other rule ? So at least you are SURE the packet is actually leaving the Mikrotik ?!
Your claim on the ISP filtering out is very,very unlikely if they hand out IPv6 prefixes...

activate logging on :

add action=accept chain=forward comment="Accept everyhthing from LAN to WAN" in-interface-list=LAN out-interface-list=WAN
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 7:59 pm

If you don't have much Ipv6 traffic just enable the logging also on the other rule ? So at least you are SURE the packet is actually leaving the Mikrotik ?!
Your claim on the ISP filtering out is very,very unlikely if they hand out IPv6 prefixes...

activate logging on :

add action=accept chain=forward comment="Accept everyhthing from LAN to WAN" in-interface-list=LAN out-interface-list=WAN
Yep it seems to leave the router... SYN bit no ACKs strange that Cloudflare DNS ACKs tho...
19:53:49 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:46438->[2a01:4f9:c010:2636::1]:80, len 40
19:53:50 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:46438->[2a01:4f9:c010:2636::1]:80, len 40
19:53:53 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:46438->[2a01:4f9:c010:2636::1]:80, len 40
19:53:57 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:46438->[2a01:4f9:c010:2636::1]:80, len 40
19:54:05 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:46438->[2a01:4f9:c010:2636::1]:80, len 40
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 44
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 20
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 564
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 20
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 100
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 135
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 20
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 44
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 106
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 135
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 20
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 44
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 104
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 20
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 20
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 44
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 111
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 20
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 44
19:54:19 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 106
19:54:20 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:40488->[2606:4700:4700::1001]:853, len 20
19:54:20 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:37616->[2a00:1450:4010:c01::65]:443, len 40
19:54:21 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:37616->[2a00:1450:4010:c01::65]:443, len 40
19:54:23 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:37616->[2a00:1450:4010:c01::65]:443, len 40
19:54:27 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:37616->[2a00:1450:4010:c01::65]:443, len 40
 
User avatar
jvanhambelgium
Forum Veteran
Forum Veteran
Posts: 985
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 8:25 pm

Hmm, strange indeed.

Did you also enable logging for the rule below ??

add action=accept chain=forward comment="Accept routed established connections (forward)" connection-state=established,related \
in-interface-list=WAN out-interface-list=LAN

That rule should let the ACK's back through the Mikrotik to you LAN-host. (so not targeted at your device itself)

Strange thing indeed.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 8:31 pm

I would look at MTU as well especially since it is PPPoE - perhaps the 1500 byte response is not making it back to you.

Ideally if your ISP supports RFC4638 (getting 1500 MTU over PPPoE by making the PPPoE packets slightly oversize) you can eliminate most MTU issues by configuring that.
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 8:38 pm

Hmm, strange indeed.

Did you also enable logging for the rule below ??

add action=accept chain=forward comment="Accept routed established connections (forward)" connection-state=established,related \
in-interface-list=WAN out-interface-list=LAN

That rule should let the ACK's back through the Mikrotik to you LAN-host. (so not targeted at your device itself)

Strange thing indeed.
Yep, you were right, I forgot to log this rule:
20:33:15 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:51162->[2a00:1450:4010:c02::54]:443, len 40
20:33:36 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 44
20:33:36 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (SYN,ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 32
20:33:36 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 20
20:33:36 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 309
20:33:36 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:36 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 1380
20:33:36 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 1380
20:33:36 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK,PSH), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 122
20:33:36 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 20
20:33:36 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 100
20:33:36 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 135
20:33:36 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 135
20:33:36 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:36 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:36 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK,PSH), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 512
20:33:37 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 20
20:33:37 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 44
20:33:37 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 104
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2a00:1450:4010:c0b::bc]:5228->[2a02:ad8:1484:7a00:85e8:a490:938f:49f]:60416, len 32
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK,PSH), [2a00:1450:4010:c0b::bc]:5228->[2a02:ad8:1484:7a00:85e8:a490:938f:49f]:60416, len 59
20:33:37 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac ac:9e:17:27:ec:c3, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:85e8:a490:938f:49f]:60416->[2a00:1450:4010:c0b::bc]:5228, len 69
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK,PSH), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 512
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK,PSH), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 512
20:33:37 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 20
20:33:37 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 44
20:33:37 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,PSH), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 111
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:37 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK,PSH), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 512
20:33:37 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:54302->[2a00:1450:4010:c01::8b]:443, len 40
20:33:37 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 20
20:33:38 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:54302->[2a00:1450:4010:c01::8b]:443, len 40
20:33:40 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:54302->[2a00:1450:4010:c01::8b]:443, len 40
20:33:44 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:54302->[2a00:1450:4010:c01::8b]:443, len 40
20:33:47 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK,PSH), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 44
20:33:47 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK,FIN), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:47 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 20
20:33:47 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (ACK,FIN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072->[2606:4700:4700::1001]:853, len 20
20:33:47 firewall,info forward: in:pppoe-out1 out:bridge1, proto TCP (ACK), [2606:4700:4700::1001]:853->[2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:41072, len 20
20:33:48 firewall,info forward: in:bridge1 out:pppoe-out1, src-mac b4:6b:fc:dd:1c:3d, proto TCP (SYN), [2a02:ad8:1484:7a00:3b30:ac91:7187:e50f]:51162->[2a00:1450:4010:c02::54]:443, len 40
I've just checked and I am even able to manually resolve hosts with nslookup through IPv6 Cloudflare DNS (until those logs I thought it was DoH that resolves everything)
zsh 1120 % nslookup ipv6.google.com 2606:4700:4700::1111
Server: 2606:4700:4700::1111
Address: 2606:4700:4700::1111#53

Non-authoritative answer:
ipv6.google.com canonical name = ipv6.l.google.com.
Name: ipv6.l.google.com
Address: 2a00:1450:4010:c09::66
Name: ipv6.l.google.com
Address: 2a00:1450:4010:c09::71
Name: ipv6.l.google.com
Address: 2a00:1450:4010:c09::64
Name: ipv6.l.google.com
Address: 2a00:1450:4010:c09::8a
Maybe its ISP indeed...
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 9:13 pm

I would look at MTU as well especially since it is PPPoE - perhaps the 1500 byte response is not making it back to you.

Ideally if your ISP supports RFC4638 (getting 1500 MTU over PPPoE by making the PPPoE packets slightly oversize) you can eliminate most MTU issues by configuring that.
I've tried setting Max MTU and max MRU in PPPoE connection to 1500 but actual MTU is set to 1492... I thought v6 uses PMTUD...
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 9:47 pm

Read this whole topic: viewtopic.php?f=2&t=171390
And this: viewtopic.php?f=2&t=169757&p=832247#p831447
Disregard IP'njeneer's "solution" though.
 
User avatar
jvanhambelgium
Forum Veteran
Forum Veteran
Posts: 985
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 10:26 pm

If an MTU issue would be the cause, then it would also be applicable on IPv4 ? We weird broken connections, sites that don't open well etc.
I'm not aware IPv6 / IPv4 follow different MTU rules on an underlying common PPPoE transport link?
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 10:37 pm

They work under the same MTU provided by the PPPoE interface, yes.
However for IPv4 there's a default change-tcp-mss=yes rule set in the PPPoE Profile.
For IPv6 you apply one of the solutions mentioned in those posts.
Even if PMTUD works, the first connection will get "stuck", since the first packet leaves the CLIENT interface with the wrong initial MSS, telling the server: "OY, I CAN RECEIVE THIS MUCH" but in fact it can't.
PMTUD kicks in, destination gets cached with the proper MTU, and the next packets will go fine with the actual MSS, but that requires a refresh on most websites.
So you either send the proper MTU to the clients via IPv6/ND so that the first packets will go out with the proper MSS, or you do mss-clamping on the router, like RouterOS does internally for IPv4 when change-tcp-mss=yes.
My 2 cents on this.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: IPv6 ICMP ok but no TCP traffic

Mon May 03, 2021 11:47 pm

If an MTU issue would be the cause, then it would also be applicable on IPv4 ?
No - with IPv4, routers in between the source and destination are allowed to fragment packets, but not with IPv6. So in the event that the server sends the customer a 1500 byte packet, the ISP PPPoE concentrator router can fragment the packet on its way to the customer so that it doesn't have to be resent with a smaller size by the source. This feature is independent of MSS clamping. With IPv6, intermediate routers are not allowed to fragment the packet - they have to drop it and send an ICMPv6 message back to the sender. In this case with the PPPoE tunnel, the ISP knows that they can't send a full 1500 byte packet to the customer, so in the case of IPv4 they would fragment it and in the case of IPv6 their router would drop it and send an ICMPv6 packet back to the web server that sent the packet to the customer. If that ICMPv6 packet gets dropped, the web server will never know that its packet was too big.

With IPv4 a lot of firewalls block ICMP without a second thought because it doesn't really matter so much if packet-too-big messages can't make it through, since an intermediate router can still fragment the packets. With IPv6, using the same practice of dropping these ICMP messages will completely break the ability to deliver packets to anybody who has a smaller MTU than 1500, unless you resort to MSS clamping or some other client side workaround like advertising a smaller MTU to the local network via router advertisements.
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

Re: IPv6 ICMP ok but no TCP traffic

Tue May 04, 2021 12:19 am

If an MTU issue would be the cause, then it would also be applicable on IPv4 ? We weird broken connections, sites that don't open well etc.
I'm not aware IPv6 / IPv4 follow different MTU rules on an underlying common PPPoE transport link?
I've never had any problems on v4 on this connection before. This is v6-only problem...
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

Re: IPv6 ICMP ok but no TCP traffic

Tue May 04, 2021 12:59 am

Read this whole topic: viewtopic.php?f=2&t=171390
And this: viewtopic.php?f=2&t=169757&p=832247#p831447
Disregard IP'njeneer's "solution" though.
I've tried setting in different MTUs in neighbor discovery-lowest for v6 (1280), my PPPoE WAN interface's (1492) and auto-negotiated (1480) neither works.
I've also tried that rule from the thread you pointed me to:
/ipv6 firewall mangle
add action=change-mss chain=forward comment=\
    "update PMTU for PPPoE via WAN" new-mss=clamp-to-pmtu \
    out-interface=pppoe-out1 packet-size=1421-65535 passthrough=yes protocol=\
    tcp tcp-flags=syn
Doesn't seem to work too...
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: IPv6 ICMP ok but no TCP traffic

Tue May 04, 2021 3:58 am

/ipv6 firewall mangle
add action=change-mss chain=forward comment=\
"update PMTU for PPPoE via WAN" new-mss=clamp-to-pmtu \
out-interface=pppoe-out1 packet-size=1421-65535 passthrough=yes protocol=\
tcp tcp-flags=syn[/code]
What if you hard-set the new-mss instead of new-mss=clamp-to-pmtu? ex. something like new-mss=1400
 
Unb0rn
just joined
Topic Author
Posts: 20
Joined: Sat Jan 28, 2012 1:04 am

Re: IPv6 ICMP ok but no TCP traffic

Wed May 05, 2021 12:28 am

/ipv6 firewall mangle
add action=change-mss chain=forward comment=\
"update PMTU for PPPoE via WAN" new-mss=clamp-to-pmtu \
out-interface=pppoe-out1 packet-size=1421-65535 passthrough=yes protocol=\
tcp tcp-flags=syn[/code]
What if you hard-set the new-mss instead of new-mss=clamp-to-pmtu? ex. something like new-mss=1400
I've tried different MSS sizes 1300, 1350, 1400 still nothing...

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot], elvtechnology, GoogleOther [Bot] and 77 guests