[2.0.1] Bypass firewall rules for traffic on the same IF inop [fixed] chk plz
-
Dear folks,
We have asymmetric routing for a VPN gateway on the LAN interface. Therefore, we use the "Bypass firewall rules for traffic on the same interface" option under Advanced on the PFSense default gateway.
The problem is that after a short time, the PFSense gateway stops forwarding packets to the gateway on the same network.Here's the layout:
rt1 vpn1
|–-----|
|
clientRT1 is supposed to redirect/forward 192.168.0.0/16 through vpn1. (Asymmetric routing).
http://redmine.pfsense.org/issues/1950 states that this was a problem in 2.0.
We are running 2.0.1 Release.
However, these four rules here are still at the very bottom of rules.debug under the userrules anchor:
pass quick on $EKHNET proto tcp from 192.168.16.64/26 to 192.168.0.0/16 flags any keep state(sloppy) label "pass traffic between statically routed subnets"
pass quick on $EKHNET from 192.168.16.64/26 to 192.168.0.0/16 keep state(sloppy) label "pass traffic between statically routed subnets"
pass quick on $EKHNET proto tcp from 192.168.0.0/16 to 192.168.16.64/26 flags any keep state(sloppy) label "pass traffic between statically routed subnets"
pass quick on $EKHNET from 192.168.0.0/16 to 192.168.16.64/26 keep state(sloppy) label "pass traffic between statically routed subnets"My question is is this normal?
Because the Bypass option seems to be broken for us… For example, if a user tried uploading data via VPN, the connection breaks after about 300kbs, and then fails.
If I manually add the 192.168.0.0/16 route to client, then everything works perfectly. Both rt1 and vpn1 run on pfsense.Any help would be greatly appreciated!
-
I would just like to add that this only happens if redirects are not honored by the client. Because if they are, the connection is handed off to the second router (vpn1) before the issue occurs.
Has no one experienced this?
Essentially, the rt1 router stops forwarding packets to vpn1 on behalf of client after about 300 kbytes (I assume it's a fixed number of packets actually). I thought the bypass checkmark was supposed to take care of exactly that, was is not?
-
Ok, guys, I just switched the bypass rules in the user anchor to be the first in the rules. For this I have changed filter.inc
Please find a unified diff file attached that fixes the problem
@The admins/devs: Should I commit this somewhere as a fix? Or would you like to just grab the diff file and look at it whether this is good?