Bypass firewall rules for traffic on the same interface and additional networks
-
Hello.
Actually i was not sure if i had to post the issue in "Routing and Multi WAN" - anyway…
We are using a pfSense 1.2.1-RC2 as the NAT/Firewall/Gateway to the internet.
The internal network is divided into several VLANs which all are handled by a central switch.
The default gateway of the switch points to the internal nic of the pfSense (172.10.100.10).There is a static route on the pfSense for the LAN interface which points back
to the switch to make the VLANs work.LAN: 172.10.0.0/16 -> 172.10.100.1
Now we had to add another appliance (172.10.100.22) for an IPSec connection to a customers site (network 10.140.1.0/24).
Network layout looks like:
VLANs (172.10.20.0/24, 172.10.21.0/24, 172.10.22.0/24)
| | |
+–----------------------------------------+
| central switch managing VLANs |
| def. route 0.0.0.0/0 -> 172.10.100.10 |
+------------------------------------------+
| 172.10.100.1
+--------------+-------------+
VLAN 100 | |
| |
| 172.10.100.10 | 172.10.100.22
+-----------------+ +--------------------+
| pfSense | | IPSec Appliance |
+-----------------+ +--------------------+
: (static public ip) : ( static public ip)
: :There is a route on the ipsec appliance pointing to the VLANs via 172.10.100.1 (likewise on the pfSense)
We started to add another static route on the pfSense to route traffic for 10.140.1.0/24 over to the ipsec appliance.
LAN: 10.140.1.0/24 -> 172.10.100.22
The pfSense will not handle the connections correctly even with
the option "Bypass firewall rules for traffic on the same interface" set.The tcp connections like rdp die after 20 seconds.
It looks like the connection is handled by the state inspection code of the firewall and it is
well known that this is not possible on a firewall with traffic entering and leaving the same interface.I had a look using the status.php on the "pfctl -sr" results and they show something interesting:
…
pass in quick on em1 inet from 172.10.100.0/24 to 172.10.0.0/16 no state label "pass traffic between statically routed subnets"
pass in quick on em1 inet from 172.10.0.0/16 to 172.10.100.0/24 no state label "pass traffic between statically routed subnets"
pass out quick on em1 inet from 172.10.100.0/24 to 172.10.0.0/16 no state label "pass traffic between statically routed subnets"
pass out quick on em1 inet from 172.10.0.0/16 to 172.10.100.0/24 no state label "pass traffic between statically routed subnets"pass in quick on em1 inet from 172.10.100.0/24 to 10.140.1.0/24 no state label "pass traffic between statically routed subnets"
pass in quick on em1 inet from 10.140.1.0/24 to 172.10.100.0/24 no state label "pass traffic between statically routed subnets"
pass out quick on em1 inet from 172.10.100.0/24 to 10.140.1.0/24 no state label "pass traffic between statically routed subnets"
pass out quick on em1 inet from 10.140.1.0/24 to 172.10.100.0/24 no state label "pass traffic between statically routed subnets"
...Opps. What's that on the lower four rules (the ones for the ipsec network)?
The auto generated rules which are enabled via "Bypass firewall rules for traffic on the same interface"
option indeed only cover the LAN network of the pfSense! So the text of the option:"This option only applies if you have defined one or more static routes. If it is enabled, traffic that
enters and leaves through the same interface will not be checked by the firewall. This may be desirable
in some situations where multiple subnets are connected to the same interface."is missleading. It makes the user believe that this is true for ANY internal LAN (available via a static route).
Actually it is only true for traffic originating or ending in the LAN network (172.10.100.0/24) of the pfSense.It works for the traffic coming from the VLANs and ending at the pfSense, but it does not work for the kind of traffic
where the pfSense has to receive traffic from a VLAN and route it to the IPSec LAN (i.e. 172.10.21.23 -> 10.140.1.51 ).Note: The really bad thing is… we tested this all using ping (ICMP) and got fooled because
pinging the partners (incl. tracert) showed correct results.Ok. no problem i thought... lets add a manual firewall rule and use the "State Type" option "none" - but.....
pfctl -sr shows for this entry:
pass in quick on em1 inet proto tcp from 172.10.0.0/16 to 10.140.1.0/24 flags S/SA keep state label "USER_RULE: Permit internal VPN traffic to customer"
So for this rule the "keep state" is active even if "none" is selected in the firwall_rule_edit.php page.
Well - and this only covers a "pass in" and there is no chance to create a "pass out". :-(I already pulled my hair out about this and did not came to an easy solution.
Any ideas how to come around this?Regards
AndiFinally i thing the only solution is a switch which can handle static routes and place the static routes to the VPN partners there. :-(