PfSense as OpenVPN Client
-
That can be achieved by modifying the gateway setting on the default rule for each interface. Routing between the interfaces lying within pfSense should be affected (pfSense will route traffic through a gateway only when the destination is not within its interfaces, by default). If you want some specific traffic not to go through the VPN, you can create another rule and place it ABOVE the default one, specifying what gateway it should get sent to (or leave it blank to use the current system routing table). Remeber rules are matched from the top to the bottom, the first match wins and rules are not evaluated anymore (there's an option to override this, though).
Cheers!
-
The solution suggested here works in the sense that it will allow clients on the interfaces that are routed through the WAN gateway instead of the the default one access the internet without going through the vpn connection. But using the WAN gateway means that they are unable to access any other interface than the WAN (other local interfaces, eg if you have several LANs connected in pfsense).
Is there a solution to this?
Logically, it would be nice to let the interfaces that should use the vpn connection use a special gateway for this, and don't let openvpn mess with the default gateway. I guess you would have to turn of openvpn's auto routing and route yourself then. Question is how to configure the openvpn gateway (in my suggestion above) to give access to both other LANs and the WAN (WAN only through the VPN, of course).
This is just a matter of managing the firewall rules as you normally would when using multiple interfaces. For E.g if you want to have LAN subnet access to OPT2 subnet, 192.168.1.5 to access the internet through your VPN and everything else to go through you WAN your rules from top to bottom should look like this:
Source: LAN Subnet
Destination OPT2 Subnet
Gateway: * (Default)Source: 192.168.1.5
Destination: *
Gateway: VPN_GWSource *
Destination *
Gateway *Remember that rules are evaluated from top to bottom until the first match if found. I suspect you have something like this:
Source: 192.168.1.5
Destination *
Gateway: VPN_GWSource: *
Destiantion: *
Gateway: WAN_GWWith this configuration your traffic from 192.168.1.5 goes to VPN and everything else is sent to the WAN. No traffic to OPT2 is passed.
-
This is just a matter of managing the firewall rules as you normally would when using multiple interfaces. For E.g if you want to have LAN subnet access to OPT2 subnet, 192.168.1.5 to access the internet through your VPN and everything else to go through you WAN your rules from top to bottom should look like this:
Source: LAN Subnet
Destination OPT2 Subnet
Gateway: * (Default)Source: 192.168.1.5
Destination: *
Gateway: VPN_GWSource *
Destination *
Gateway *Remember that rules are evaluated from top to bottom until the first match if found. I suspect you have something like this:
Source: 192.168.1.5
Destination *
Gateway: VPN_GWSource: *
Destiantion: *
Gateway: WAN_GWWith this configuration your traffic from 192.168.1.5 goes to VPN and everything else is sent to the WAN. No traffic to OPT2 is passed.
Thanks for the reply! I can't get it to work, though. There are a number of discrepancies between your solution and the way my pfsense looks like.
First, I don't have all the rules in one table. In my version of pfsense (2.1Beta-1) all the interfaces have their own tabs with rules, so I don't know in which one to enter the rules you mention. I suppose they would be in different ones.
Second, the default gateway is altered somehow when connecting to an OVPN client, so the DEFAULT gateway is the VPN_GW in your example. There is another GW present once I have connected to the OVPN client called "WAN_DHCP (ip.addr.of.isp)". If I choose this gateway for the default rule on an interface AND also change the NAT outbound to use WAN instead of "OpenVPN Adress", then that inteface CAN connect to the internet via the WAN, but not to any clients connected to other interfaces on pfsense (like local LAN machines).So then I tried adding a rule for my (testing) interface that was placed above the standard allow all rule, with the difference that this rule only applied to "Destination: WAN subnet" and I also changed the gateway to WAN_DHCP in this rule.
Regardless if I have the NAT outbound rule to WAN or OpenVPN Adress for that interface, it doesn't work when I have "Destination: WAN subnet (or WAN address) in the rule.Do you understand what I'm doing wrong? Because I don't..
-
The rules mentioned above should be on the LAN tab.
Do you say that playing around with the gateway setting breaks connectivity towards your OPT2? There's something wrong there. pfSense will only route through a specified gateway for traffic that is directed to a subnet that is NOT hanging on its own interfaces. You cannot break inter-interface traffic just by messing up with the gateways, there's must be something else.
Also be careful with the outbound NAT. You mention several times "changing the outbound NAT from WAN to OpenVPN", I don't think there is any need to change anything once it's properly set up to alter the behaviour.
On your setup, outbound NAT should be set up to NAT traffic coming from ANY, destination ANY, on the WAN interface and also on the OpenVPN (two rules). You can leave both rules on at the same time and forget about them (unless there is a private subnet hanging on your WAN or something like that).
Reading your post once again, I think your problem is with the outbound NAT. Looks like your internal traffic towards OPT2 is being NAT'ed as well. Post your Outbound NAT rules and let's see, this shouldn't be this difficult…
EDIT: something else, I don't think you need rules matching "Destination WAN subnet" or "Destination WAN address". Those rules will NOT match traffic going out to the Internet through your WAN. The destination is the final destination of the package, which would be for example Google's IP address, not you WAN IP. Any time you want to match all outgoing traffic going to the Internet you need to specify destination ANY over the WAN interface, considering you are handling the "exceptions" with other rules above it.
Destination WAN address will only match traffic targeted at your ISP router (or whatever device is hanging off your WAN). Destination WAN subnet is useful if you have another devices hanging off your WAN subnet and you need to handle that traffic (for example if your ISP provides multiple public IPs over the same subnet, and you have something else plugged to your modem, outside your pfSense realm) -
The rules mentioned above should be on the LAN tab.
Do you say that playing around with the gateway setting breaks connectivity towards your OPT2? There's something wrong there. pfSense will only route through a specified gateway for traffic that is directed to a subnet that is NOT hanging on its own interfaces. You cannot break inter-interface traffic just by messing up with the gateways, there's must be something else.
Also be careful with the outbound NAT. You mention several times "changing the outbound NAT from WAN to OpenVPN", I don't think there is any need to change anything once it's properly set up to alter the behaviour.
On your setup, outbound NAT should be set up to NAT traffic coming from ANY, destination ANY, on the WAN interface and also on the OpenVPN (two rules). You can leave both rules on at the same time and forget about them (unless there is a private subnet hanging on your WAN or something like that).
Reading your post once again, I think your problem is with the outbound NAT. Looks like your internal traffic towards OPT2 is being NAT'ed as well. Post your Outbound NAT rules and let's see, this shouldn't be this difficult…
EDIT: something else, I don't think you need rules matching "Destination WAN subnet" or "Destination WAN address". Those rules will NOT match traffic going out to the Internet through your WAN. The destination is the final destination of the package, which would be for example Google's IP address, not you WAN IP. Any time you want to match all outgoing traffic going to the Internet you need to specify destination ANY over the WAN interface, considering you are handling the "exceptions" with other rules above it.
Destination WAN address will only match traffic targeted at your ISP router (or whatever device is hanging off your WAN). Destination WAN subnet is useful if you have another devices hanging off your WAN subnet and you need to handle that traffic (for example if your ISP provides multiple public IPs over the same subnet, and you have something else plugged to your modem, outside your pfSense realm)Very informative, thank you! By changing the outbound NAT rules to what you suggested (just two rules configured as you said), I can now make one of my interfaces (in my case all clients on the 2.4ghz AP are affected) go through my regular (unmasked) ISP internet connection while all the other interfaces goes through the VPN connection when accessing the internet. I do this by changing the allow-all rule gateway to WAN_DHCP instead of default on the interface I want to keep outside the VPN connection.
The problem is that any clients on that interface can't connect to my LAN (or any local subnet), only the internet. I can't ping my NAS and other servers connected to my pfsense box (in this case they are connected on another subnet, the wired LAN). The interfaces that have their allow-all rule set to use the default gateway can access all other local clients fine.
Based on what you have said, I'm beginning to speculate that the reason for this behavior is that the openvpn server I'm connecting to changes the pfsense routing table (or something like that, I'm not very good at network related stuff). That could perhaps explain why changing the gateway to WAN_DHCP for the allow-all firewall rule on the 2.4ghz-AP-interface (or OPT2, or whatever we want to call it) will make it connect to the internet without going through the VPN, but not connect to other local clients.
This is all very complicated to me, but I know there is a command I can use when connecting to the VPN server from pfsense (route-nopull) that will inhibit the vpn server from changing the pfsense routing table. If I add that command, the openvpn client in pfsense connects fine to the vpn server but no clients (on any interface) go through the vpn connection, all use my regular IP. So perhaps if I go that route (no pun intended) instead, and try to define what interfaces will be routed through the vpn rather than the other way around? I don't know how to do that routing, though.. I suppose I will need some firewall rules as well.
Do you have any ideas?
-
You have a routing problem there. Mmm what IP/mask do you get from the OpenVPN connection? The same as any of your internal networks? Looks like the VPN is pushing routes that direct the traffic intended to the other interfaces through the VPN. What if you use a completely different network segment for your internal networks?
-
I suspect you are best to use a "not" rule. For example, on WIFI1, you want to route all traffic except for packets with destination (LAN or WIFI2), to WAN_DHCP.
a) Put the default rule back the way it was (so it will allow any packets that don't match special rules, and those packets will get routed by the normal routing table, e.g. WIFI1 to LAN, WIFI1 to WIFI2).
b) Add a rule to WIFI1 passing source WIFI1 Net, destination not LAN Net, gateway WAN_DHCP - this will not match traffic to LAN, so traffic to LAN will fall through to the default rule and get normal routing. All other traffic will head out WAN_DHCP.For you, (b) is not quite right. You really want "destination (not LAN) and (not WIFI2)". To do that, add an Alias which has the network IP ranges for LAN and WIFI2 in it - e.g. name it InternalIPs - then in (b) make the destination (not InternalIPs).
Essentially, you want a way to specify destination "all addresses not in my internal network", and do the policy-based routing to WAN_DHCP on those only. In your case, you can even use (not 192.168.0.0/16) - then if you add other 192.168.n.0/24 nets to your internal network in future, the rules will work. It would be handy if there was a "built-in" alias for the private IPv4 address space, then it would be easy for anyone to specify rules to match (private IPv4 address) and (not private IPv4 address) - hmm now I'm rambling:)
-
You have a routing problem there. Mmm what IP/mask do you get from the OpenVPN connection? The same as any of your internal networks? Looks like the VPN is pushing routes that direct the traffic intended to the other interfaces through the VPN. What if you use a completely different network segment for your internal networks?
I don't think the IP I get from the OVPN connection interferes with any of my internal ones actually, its in a completely different range. This is what the logon sequence looks like:
Feb 10 11:09:40 openvpn[52909]: [ovpn1] Peer Connection Initiated with [AF_INET]178.132.75.50:1194 Feb 10 11:09:43 openvpn[52909]: SENT CONTROL [ovpn1]: 'PUSH_REQUEST' (status=1) Feb 10 11:09:43 openvpn[52909]: PUSH: Received control message: 'PUSH_REPLY,ifconfig-ipv6 2a03:8600:1001:2037::1009/64 2a03:8600:1001:2037::1,route-ipv6 2000::/3 2A03:8600:1001:2037::1,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 178.132.75.60,tun-ipv6,route-gateway 178.132.78.193,topology subnet,ping 3,ping-restart 15,ifconfig 178.132.78.203 255.255.255.224' Feb 10 11:09:43 openvpn[52909]: OPTIONS IMPORT: timers and/or timeouts modified Feb 10 11:09:43 openvpn[52909]: OPTIONS IMPORT: --ifconfig/up options modified Feb 10 11:09:43 openvpn[52909]: OPTIONS IMPORT: route options modified Feb 10 11:09:43 openvpn[52909]: OPTIONS IMPORT: route-related options modified Feb 10 11:09:43 openvpn[52909]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Feb 10 11:09:43 openvpn[52909]: ROUTE default_gateway= <myispsgatewayipaddress>Feb 10 11:09:43 openvpn[52909]: ROUTE6: default_gateway=UNDEF Feb 10 11:09:43 openvpn[52909]: TUN/TAP device /dev/tun2 opened Feb 10 11:09:43 openvpn[52909]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=1 Feb 10 11:09:43 openvpn[52909]: /sbin/ifconfig ovpnc2 178.132.78.203 netmask 255.255.255.224 mtu 1500 up Feb 10 11:09:43 openvpn[52909]: /sbin/route add -net 178.132.78.192 178.132.78.203 255.255.255.224 Feb 10 11:09:43 openvpn[52909]: ERROR: FreeBSD route add command failed: external program exited with error status: 1 Feb 10 11:09:43 openvpn[52909]: /sbin/ifconfig ovpnc2 inet6 2a03:8600:1001:2037::1009/64 Feb 10 11:09:43 openvpn[52909]: /usr/local/sbin/ovpn-linkup ovpnc2 1500 1541 178.132.78.203 255.255.255.224 init Feb 10 11:09:43 openvpn[52909]: /sbin/route add -net 178.132.75.50 130.243.232.1 255.255.255.255 Feb 10 11:09:43 openvpn[52909]: /sbin/route add -net 0.0.0.0 178.132.78.193 128.0.0.0 Feb 10 11:09:43 openvpn[52909]: /sbin/route add -net 128.0.0.0 178.132.78.193 128.0.0.0 Feb 10 11:09:43 openvpn[52909]: add_route_ipv6(2000::/3 -> 2a03:8600:1001:2037::1 metric 0) dev ovpnc2 Feb 10 11:09:43 openvpn[52909]: /sbin/route add -inet6 2000::/3 -iface ovpnc2 Feb 10 11:09:43 openvpn[52909]: Initialization Sequence Completed</myispsgatewayipaddress>
I also noted something strange today. The OVPN connection went down for some reason, in the logs it said it couldn't resolve the address to the OVPN server. This made all internet access go down from all clients, including the clients on the interface that I had told to use the WAN_DHCP-gateway (to get a non-VPN-IP). When I restarted the OVPN-connection, it connected fine and everything worked.
Is it hard to route/firewall-rule-stuff through the OVPN connection if I choose to use the route-nopull command for the OVPN connection?
-
I suspect you are best to use a "not" rule. For example, on WIFI1, you want to route all traffic except for packets with destination (LAN or WIFI2), to WAN_DHCP.
a) Put the default rule back the way it was (so it will allow any packets that don't match special rules, and those packets will get routed by the normal routing table, e.g. WIFI1 to LAN, WIFI1 to WIFI2).
b) Add a rule to WIFI1 passing source WIFI1 Net, destination not LAN Net, gateway WAN_DHCP - this will not match traffic to LAN, so traffic to LAN will fall through to the default rule and get normal routing. All other traffic will head out WAN_DHCP.For you, (b) is not quite right. You really want "destination (not LAN) and (not WIFI2)". To do that, add an Alias which has the network IP ranges for LAN and WIFI2 in it - e.g. name it InternalIPs - then in (b) make the destination (not InternalIPs).
Essentially, you want a way to specify destination "all addresses not in my internal network", and do the policy-based routing to WAN_DHCP on those only. In your case, you can even use (not 192.168.0.0/16) - then if you add other 192.168.n.0/24 nets to your internal network in future, the rules will work. It would be handy if there was a "built-in" alias for the private IPv4 address space, then it would be easy for anyone to specify rules to match (private IPv4 address) and (not private IPv4 address) - hmm now I'm rambling:)
Can't I just add two rules under the default rule on WIFI1? I.e., two not-rules just over/under each other?
-
UPDATE: I went ahead and tried doing it the route-nopull way instead. Had some success!
I added the route-nopull command to the OVPN client config. This leaves my routing intact, I think. Then I added this OVPN client connection as an interface, named it "VPN". This made the VPN appear under "Gateways", but the default is still my usual ISP on WAN. I then under "Outbound NAT", I removed all the rules, switched to automatic, saved, and then back to manual and saved. This created a number of rules apparently needed for this to work. Applied the changes.
Then I created rules for interfaces LAN, WIFI1, WIFI2. For all interfaces, I added three rules at the top that tells any traffic that has destination LAN, WIFI2, and WIFI2 to use default gateway (). For LAN and WIFI1 I then added a fourth rule at the bottom for any traffic with any destination to use the VPN gateway instead. So everything that isn't headed for LAN, WIFI1 or WIFI2 will go through the VPN instead. For WIFI2 I just set the fourth any rule to go through the default gateway (), so that one goes through my usual internet connection.
This actually worked!
The downside is that for some reason, this causes the CPU use of the pfsense machine to be at around 50% at IDLE. Load is 3,5-ish. This is without any heavy traffic over the VPN. When I use the VPN normally (before doing these latest changes), like downloading at 1 MB/s, I certainly see an increase in CPU use (like 20-30%) due to the encryption going on, but now it is constantly there instead. Very strange.
Also, one machine is connected to IRC, and that connection drops frequently (start lagging, and then reconnects) after these last changes.
Any ideas? Maybe I've done some configuration wrong, but what I don't get is what's causing all this CPU use.
EDIT: Something strange is definitely going on. When downloading, general speed to the internet slows down in a way that it doesn't normally do. Also, when I look under Status->Gateways, the VPN-gateway shows as Offline while the WAN-gateway is Online. The VPN still works for all interfaces using it, though…
EDIT2: Download speeds are also very unstable, varying between 50-1000 kb/s for the same torrent over time. Distinctly different behavior from before my latest changes.
EDIT3: Now I got a message in pfsense that something crashed (something with PHP..), and after that CPU use normalized. Download speeds are still going up and down like crazy though. Torrents sometime stop downloading completely for 5 min and then go up to 1 MB/s again.
EDIT4: I think I got rid of the problem with losing internet access. I disabled flushing of states when a gateway goes down. Seems like when I saturated the connection, "apinger" (or whatever it's called) couldn't ping my WAN gateway so it flushed states, making the connection go down for a couple of minutes. WHY this started happening with my new conf, I have no idea..
-
Alright, you have enough for a couple of topics right there XD
Going back to your first problem, I think the problem is the "redirect-gateway" option you seem to have on the ovpn config. Could you try disabling that and manually direct traffic to the right gateway through rules? (as we have been suggesting). I insist that all this "playing around with the gateway option and outbound NAT" mess shouldn't be needed. The redirect-gateway seems to be messing up your default gateway (which you don't want to be changed! You want to send specific traffic through it)
Cheers!
-
Can't I just add two rules under the default rule on WIFI1? I.e., two not-rules just over/under each other?
- Any special rules need to go before (above) the more general rules. The rules are checked from top to bottom, and the first match is what counts.
- If you put 2 rules on WiFi1
(a) (destination !LAN) to WAN_DHCP
(b) (destination !WIFI2) to WAN_DHCP
then:
(i) traffic from WIFI1 to WIFI2 matches (a) - so it gets routed to WAN_DHCP
(ii) traffic from WIFI1 to LAN matches (b) - so it gets routed to WAN_DHCP
not what you want!
The rule on WIFI1 needs to be
(destination (!LAN and !WIFI2) to WAN_DHCP)
For that, you need an alias that covers LAN and WIFI2 together, and use (destination !alias) in the rule.
-
Can't I just add two rules under the default rule on WIFI1? I.e., two not-rules just over/under each other?
- Any special rules need to go before (above) the more general rules. The rules are checked from top to bottom, and the first match is what counts.
- If you put 2 rules on WiFi1
(a) (destination !LAN) to WAN_DHCP
(b) (destination !WIFI2) to WAN_DHCP
then:
(i) traffic from WIFI1 to WIFI2 matches (a) - so it gets routed to WAN_DHCP
(ii) traffic from WIFI1 to LAN matches (b) - so it gets routed to WAN_DHCP
not what you want!
The rule on WIFI1 needs to be
(destination (!LAN and !WIFI2) to WAN_DHCP)
For that, you need an alias that covers LAN and WIFI2 together, and use (destination !alias) in the rule.
That makes sense, thanks!
-
Alright, you have enough for a couple of topics right there XD
Going back to your first problem, I think the problem is the "redirect-gateway" option you seem to have on the ovpn config. Could you try disabling that and manually direct traffic to the right gateway through rules? (as we have been suggesting). I insist that all this "playing around with the gateway option and outbound NAT" mess shouldn't be needed. The redirect-gateway seems to be messing up your default gateway (which you don't want to be changed! You want to send specific traffic through it)
Cheers!
But isn't that what I've done? The "redirect-gateway" that shows up in the OVPN log isn't something that's decided by me, the server is just configured that way I guess. But when I did put in "route-nopull" in my config, doesn't that disable the redirect-gateway effect? Because after putting that in the config, my gateways are not changed (ie, WAN_DHCP is still the default one). I then proceeded with adding rules for each interface as you said.
The difference from what you suggested is just that I had to create and interface for the VPN (after which a VPN gateway also appeared) in order to be able to actually use rules to direct traffic to the VPN. The NAT-things I'm less sure of. I just noticed that if I leave it at automatic, my configuration won't work. Perhaps I could replace all the rules I created with just two rules like you suggested, one for WAN and one for VPN, allowing all on both. Would that increase performance? I don't really understand what those rules do, to be completely honest.
-
Ok, if it is not in your config then the "redirect-gateway" is being pushed by the server, the "route-nopull" should be enough.
As regards Outbound NAT, I'll summarize for you (I'll put it the easy way, don't blame for the technical inaccuracies!).
On the inner side of your pfSense you have multiple devices with multiple IP addresses, but on the outer side you usually have only 1 public IP address. When you send a package out to the internet from a PC within the LAN, the package has the originating header set to the internal IP address. In order to be able to receive a response from the remote machine, that package needs to have the header set to the public IP (otherwise it will never get routed back). This is what "NAT" (or "Network Address Translation") does. pfSense grabs every package going out and replaces the originating header with the the WAN IP address, and at the same time keeps an internal record (based on the ports) of which package going out corresponds to which internal IP (so it can deliver the response whenver it arrives). When the response arrives, pfSense does the same but the other way around (replaces the WAN IP that comes in the destination with the proper internal IP addressSo when the Outbound NAT is set to Manual, the rule tells pfSense to follow this procedure to every package matching the rule (that's why it is usually set to match everything leaving out the WAN interface, and in your case, also everything leaving out the OpenVPN interface). This can get more complicated as the network grows, since you might need some traffic NAT'ed and some traffic not, etc.
Hope that helped!
Regards!
-
georgeman: Thank you for the excellent explanation. I had some sort of understanding of this, but now you made it much clearer. I am now using only two rules, and it works fine. The only thing I don't understand now is why the automatic NAT doesn't work when running an VPN client?
My pfsense is now running as I wanted it to in my initial post, so big thanks to everyone who came with input on this and helped me, very appreciated!
-
pelle_chanslos, can you please tell me in summary the configuration you have done? As i understood you have some LAN Clients which are allowed to use VPN and the other only WAN. Is it right?
I have a similar network with 4 LAN clients and only 2 of the should use the VPN client connection (established within pfsense) and the other 2 should use directly the WAN.Your support is much appreciated.
-
pelle_chanslos, can you please tell me in summary the configuration you have done? As i understood you have some LAN Clients which are allowed to use VPN and the other only WAN. Is it right?
I have a similar network with 4 LAN clients and only 2 of the should use the VPN client connection (established within pfsense) and the other 2 should use directly the WAN.Your support is much appreciated.
I don't have that, I have different interfaces instead of different users. But I think you could use the same method anyway.
-
Add the VPN connection as an interface. This will add a "VPN gateway".
-
Create two rules for the LAN, one with the IPs of the two that shouldn't use the VPN, and use let them use the default gateway. The other rule should contain the IPs of the clients that should use the VPN, make it exactly the same as the first rule, but change gateway to the VPN gateway you just created when adding the interface.
You could also create two aliases, one for the two IPs that should go through the VPN and one for the two IPs that should go through the regular WAN connection.
Good luck!
-
-
It works fine, thank you for the short and clear description. Only one point is open i could not solve. Whats happend if the VPN connection is lost? In this case i am connected again to the WAN Interface and i would like to avoid this.
I tried to add a rule where any traffic between my "PC" and "any" over "WAN-gateway" is blocked. But this doesnt help.
-
Can't I just add two rules under the default rule on WIFI1? I.e., two not-rules just over/under each other?
- Any special rules need to go before (above) the more general rules. The rules are checked from top to bottom, and the first match is what counts.
- If you put 2 rules on WiFi1
(a) (destination !LAN) to WAN_DHCP
(b) (destination !WIFI2) to WAN_DHCP
then:
(i) traffic from WIFI1 to WIFI2 matches (a) - so it gets routed to WAN_DHCP
(ii) traffic from WIFI1 to LAN matches (b) - so it gets routed to WAN_DHCP
not what you want!
The rule on WIFI1 needs to be
(destination (!LAN and !WIFI2) to WAN_DHCP)
For that, you need an alias that covers LAN and WIFI2 together, and use (destination !alias) in the rule.
Wouldn't it be clever to implement AND, OR into the pfSense ruleset right away to be able to use them within the firewall rules? I think this would make sense, because the two dimensional matrix layout (aliases) doesn't suit very well for a three dimensional problem (single host aliases, groups of hosts, groups of groups meaning different layers).