Bug #3824
openLimiters on bridge break traffic outside locally-configured IP subnets
0%
Description
Take the scenario:
LAN (IP: none) bridged to WAN (management IP on 192.168.1.10/24, gateway 1.1), where the system is strictly a filtering bridge.
Put a limiter on LAN firewall rule, where rule is interface LAN, proto any, source any, dest any, and specifying the limiter.
Hosts on LAN will work fine as long as they're within 192.168.1.0/24. Say you have a WAN-side secondary subnet of 192.168.2.0/24, that will be broken by limiters. Pings will get through, but TCP is unable to complete a handshake. Add an IP alias on WAN in 192.168.2.0/24, and the host on LAN on 192.168.2.0/24 will work. Take off the limiters and it works fine.
Expected result is the system won't care what IP subnet is in use, as in such transparent scenarios it shouldn't matter. The described 192.168.2.0/24 network should work with limiters without having an IP configured in that subnet.
Behavior same on 2.2, 2.1.5, and all prior releases. Not a very common scenario, and not a regression, so not targeting 2.2.
Updated by Jim Pingle over 10 years ago
This might be the same root cause as #1634
Updated by Chris Buechler over 10 years ago
Thanks, I was thinking there was something similar out there but couldn't find anything. Looks like it, yeah. Though the description there doesn't seem to match current status, I haven't had to put an IP on the bridge interface under any of a variety of circumstances, but it does need an IP within the subnet somewhere.
I'll poke a bit more at it to see if I can better quantify the issue, then either close this one or the other.
Updated by Chris Buechler about 10 years ago
- Category changed from Traffic Shaper (ALTQ) to Traffic Shaper (Limiters)
- Status changed from New to Confirmed