Bug #2526
closedLimiter appears to break IPv6 connectivity
Added by Alex Fox about 12 years ago. Updated about 9 years ago.
0%
Description
IPv6 connectivity through pfSense appears to be blocked when directed through a limiter (accessed under Firewall -> Traffic Shaper.) The applied traffic shapers work properly when IPv4 traffic is directed through them.
Attached is a screen cap of the limiter output when attempting to access IPv6 and IPv4 resources simultaneously.
Files
Updated by Alex Fox about 12 years ago
This bug applies to 2.1 dev from June 28th as far back as June 20th. Prior to that dates build I was not using 2.1 and cannot comment.
Updated by Alex Fox about 12 years ago
On review of the screenshot it appears that the limiter is not assigning a bucket for IPv6 traffic denoted by "BKT 0". Additionally it appears that the limiter is not identifying the source/destination of IPv6 traffic properly as denoted by "::/0" for source and destination for each connection. IPv4 traffic has "0.0.0.0/0" for either source or destination and an IPv4 address for the other.
Updated by Jim Pingle about 12 years ago
For informational purposes, this bug is still present. If a limiter is applied on an IPv6 rule, the traffic no longer passes.
Updated by Chris Buechler about 12 years ago
- Category set to Traffic Shaper (ALTQ)
- Priority changed from Normal to High
- Target version set to 2.1
- Affected Version set to 2.1
Updated by Ermal Luçi almost 12 years ago
- Status changed from New to Feedback
Brought limiters up-to-speed with IPv6.
Updated by Chris Buechler over 11 years ago
- Status changed from Feedback to Resolved
Updated by Alex Fox about 11 years ago
This problem appears to be present in the Wed Jun 12 06:19:03 EDT 2013 build. IPv6 Traffic hits the limiter as shown below but fails to pass. I did a clean install and created new limiters to be sure. The same limiter was applied to both default pass rules for IPv4 and IPv6. Using Chrome, the error message "Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data." is received when loading IPv6 enabled websites and IPv6 connectivity tests in multiple browsers fail.
*=redacted
Limiters:
00001: 14.000 Mbit/s 0 ms burst 0
q131073 50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail
sched 65537 type FIFO flags 0x0 1024 buckets 0 active
00002: 2.500 Mbit/s 0 ms burst 0
q131074 50 sl. 0 flows (1 buckets) sched 65538 weight 0 lmax 0 pri 0 droptail
sched 65538 type FIFO flags 0x0 1024 buckets 0 active
Queues:
q00001 50 sl. 3 flows (256 buckets) sched 1 weight 1 lmax 0 pri 0 droptail
mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
BKT Prot Source IP/port_ _Dest. IP/port_ Tot_pkt/bytes Pkt/Byte Drp
23 ip 0 ::/0 2601:4:100:1b:f465:b85:****:23d3/0 14 1056 0 0 0
81 ip 0.0.0.0/0 192.168.***.1/0 45 5045 0 0 0
94 ip 0.0.0.0/0 192.168.***.14/0 4 396 0 0 0
q00002 50 sl. 0 flows (256 buckets) sched 1 weight 1 lmax 0 pri 0 droptail
mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
BKT Prot Source IP/port_ _Dest. IP/port_ Tot_pkt/bytes Pkt/Byte Drp
q00003 50 sl. 0 flows (256 buckets) sched 1 weight 1 lmax 0 pri 0 droptail
mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
BKT Prot Source IP/port_ _Dest. IP/port_ Tot_pkt/bytes Pkt/Byte Drp
q00004 50 sl. 5 flows (256 buckets) sched 2 weight 1 lmax 0 pri 0 droptail
mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000
BKT Prot Source IP/port_ _Dest. IP/port_ Tot_pkt/bytes Pkt/Byte Drp
88 ip 192.168.***.248/0 0.0.0.0/0 1 76 0 0 0
90 ip 192.168.***.249/0 0.0.0.0/0 1 76 0 0 0
142 ip 0 2601:4:100:1b:f465:b85:****:23d3/0 ::/0 48 15722 0 0 0
170 ip 192.168.***.1/0 0.0.0.0/0 27 1520 0 0 0
180 ip 192.168.***.14/0 0.0.0.0/0 4 268 0 0 0
q00005 50 sl. 0 flows (256 buckets) sched 2 weight 1 lmax 0 pri 0 droptail
mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000
BKT Prot Source IP/port_ _Dest. IP/port_ Tot_pkt/bytes Pkt/Byte Drp
q00006 50 sl. 0 flows (256 buckets) sched 2 weight 1 lmax 0 pri 0 droptail
mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000
BKT Prot Source IP/port_ _Dest. IP/port_ Tot_pkt/bytes Pkt/Byte Drp
Updated by Cino . over 9 years ago
This issue is still not resolved
https://forum.pfsense.org/index.php?topic=77506.new;topicseen#new
Can this ticket be reopened?
Updated by Ermal Luçi over 9 years ago
- Status changed from Resolved to Feedback
- Target version changed from 2.1 to 2.2.1
- Affected Version changed from 2.1 to All
A patch has been pushed which will fix limiters with ipv6.
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to Resolved
confirmed, limiters work correctly on v6 now.
Updated by Kill Bill over 9 years ago
Ermal Luçi wrote:
A patch has been pushed which will fix limiters with ipv6.
Sorry, that did not help. Confirmed at https://forum.pfsense.org/index.php?topic=77506.0. No luck with this even with latest 2.2.2-DEV snapshots.
Updated by Chris Buechler over 9 years ago
- Status changed from Resolved to Confirmed
- Assignee set to Chris Buechler
- Target version changed from 2.2.1 to 2.2.3
this is still an issue in some circumstances. To me to better quantify the circumstances where it's an issue.
Updated by Ermal Luçi about 9 years ago
Can you specify the scenario to check it?
Normally the only thing i see might be missing some parameter passing to dummynet to calculate the proper flow apart that i do not see any issue.
Updated by Ermal Luçi about 9 years ago
- Status changed from Confirmed to Feedback
To be retested with a new snapshot there might have been issue with operator precedence in previous patch.
Updated by Kill Bill about 9 years ago
Well I think it looks good now.
Tested with bunch of speedtest stuff like http://ipv6-test.com/speedtest/, http://ipv6-speedtest.net/, http://www.thinkbroadband.com/ipv6/speed-test.html, some browsing, FTP, wget...
Updated by Chris Buechler about 9 years ago
- Status changed from Feedback to Resolved
works here too, looks good all around.