Must be missing something simple…
-
I have pfSense running 2 networks:
WIFI Interface - 192.168.4.1 (192.168.4.x)
LAN Interface - 192.168.5.1 (192.168.5.x)I also have OpenVPN running. I have a firewall rule on the WIFI interface to route ALL traffic to the VPN gateway. The LAN traffic goes straight to WAN.
What I am trying to accomplish is put a rule on the WIFI interface, before the OpenVPN traffic routing, that will allow me to access clients on the LAN network. For example, if a device on the WIFI network (192.168.4.100) wants to talk to a device on the LAN network (192.168.5.100), it should be able to do that without being routed to the firewall gateway.
I've tried many combinations of SOURCE/DESTINATION, it seems like LAN Net/Address doesn't trigger when pinging the 192.168.5.x network, even though that is the LAN network.
-
you have lan address in there as dest, if you want to get to stuff on the lan, that should be lan network, your just allowing access to pfsense lan IP with that rule.
Which you already allow with the dest firewall rule above it.
-
Thanks for the reply.
I've tried both versions of the destination, see the attached screenshot. Still can't ping 192.168.5.x devices from WIFI.
-
and what are you pinging? Windows machine out of the box with its firewall running will not allow ping from devices other than its local network. So your wifi network would not be allowed to ping it.
-
Windows Firewall is off for private network.
If I remove the gateway for the bottom WIFI rule, I can reach all 192.168.5.x devices fine. When I define traffic to the VPN it can't get there, that is why I'm trying to setup an additional rule in front of that VPN rule.
-
Did u clear states after adding new rule? This how policy routing works i do it same way u have rule before u send it out gateway that allows the traffic with no gateway set
-
Windows Firewall is off for private network.
If I remove the gateway for the bottom WIFI rule, I can reach all 192.168.5.x devices fine. When I define traffic to the VPN it can't get there, that is why I'm trying to setup an additional rule in front of that VPN rule.
I've seen Windows mark my private network as public. Changing it to private required messing with the Registry.
-
I've seen Windows mark my private network as public. Changing it to private required messing with the Registry.
Windows marks a network as public if there is no default gateway defined on the network adapter.
So setting a default route on the VPN adapter let Windows handles it as private.
Sure, since I don't want to route all my traffic over VPN, I found a workaround for this. I set my OpenVPN server to push routes with high very metric (512) by enteringpush "route-metric 512"
in the custom options field.
However, this metric is applied for all routes the server pushes to the client, but no matter, since there is no other route for the same networks with lower metric.
So I've 2 default routes now, one over VPN gateway with metric 512 and one the wired interface with 10.This works fine for months now on Windows an Linux clients.
-
While that works for a client connecting to a vpn.. That is not what the OP is doing. He has pfsense making a client connection to his vpn and he doesn't want to route all traffic over that vpn. Only traffic that is not going to one of his other networks.
How this is done is simple rule above the rule that shoves the traffic down the vpn to allow the traffic to use the normal pfsense routes/connections to other networks.
https://doc.pfsense.org/index.php/What_is_policy_routing
Do you have this vpn connection set as default in your routing tab? This should not be set as default.. Example see my attached setup. Also you shouldn't really be pulling routes from the client vpn connections.. Your just shoving traffic down it via your firewall rule, you do not need to get any route info from that connection. See my 2nd attachement
-
Harvy66 spoke from how Windows handles networks and I had something to contribute. Apologise if that digresses from the topic, but that happens a post above.
-
Huh.. While your solution would work for a client directly connecting to a vpn, was just pointing out that is not what the OP is doing.