|
Post by knightmb on Jul 14, 2021 6:03:38 GMT
I was able to isolate the issue, when using a dual ipv4 + ipv6 SmallWall setup, if you have the traffic shaper turned on with any rules that touch any ipv6 traffic on the "Outbound", aka, Upload, then this issue happens. Basically ipv6 only works for a minute or two until some traffic has to filter through those rules, then it gets stopped or packet loss. If you turn off the traffic shaper it will solve that issue, but then you have no traffic shaper. Download rules seem to work fine (Inbound Traffic) and if you make an Upload rule that *only* applies to ipv4 traffic, that will work to.
Basically, can't have any rules to apply against Outbound (Upload) ipv6 traffic with Traffic Shaper enabled.
Some basic hardware/version info: Version: 1.8.3 built on Sat Jun 13 13:09:04 CDT 2015 Platform: Generic PC Hardware crypto: VIA Padlock (enabled)
|
|
|
Post by knightmb on Jul 26, 2021 20:44:22 GMT
I've found a work-around for the issue using some creative traffic shaper rules. Basically, anything outbound that touches Ipv6 traffic is what causes the issue. Inbound rules that touch ipv6 traffic work fine. So to make it so that your ipv6 traffic has an outbound (upload) limit that works, you create an "download" rule on the LAN side of SmallWall that only applies to ipv6 traffic and this gives you the "effect" of upload traffic shaping. Here is an example rule for traffic shaper: LAN * !192.168.1.1/24 * Bulk Upload Basically any traffic not from your ipv4 network (which would be ipv6) is sent to the Bulk Upload rule even though it is in the inbound (download) direction. Anything sent to your LAN is the opposite direction of the WAN, that's why this trick works. :-)
|
|