1 WAN interface, 3 LAN interfaces, OpenVPN allow communication to all networks
-
Should the rule be greyed out like this? I still can't get it to go, I changed the interface to OPT2. My test client is on the LAN interface (192.168.1.5)
-
Oh sorry you need to set outbound NAT to hybrid or manual to apply user rules. I suggest hybrid so auto rules are still updated.
-
@stephenw10
Thank you, it's no longer greyed out but still not working.
The idea is for (LAN) 192.168.1.5 to access (OPT2) 192.168.3.101 as if it were on the 192.168.3.0/24 subnet. Do I need to specify port ranges or anything? I hope not.
I can verify access by switching from (LAN)192.168.1.5 to (OPT2) 192.168.3.5 on the windows test client and accessing the web IPMI interface.
-
Check the state table again. You should see the translation on the OPT2 state.
-
I only see activity from 192.168.15 to the pfsense admin web admin. Nothing for 192.168.3
-
@jg8000 said in 1 WAN interface, 3 LAN interfaces, OpenVPN allow communication to all networks:
I can verify access by switching from (LAN)192.168.1.5 to (OPT2) 192.168.3.5 on the windows test client
How exactly are you making that switch? Does that client have NICs in both subnets? If so it's probably not sending traffic through pfSense at all.
-
I just use it as a sanity check. I change the adapter IP from the 192.168.1 to the 192.168.3. and the IPMI port is on the same switch. So no, I doubt pfsense is involved. It only tells me that it's up and accessible.
-
Hmm, but sending from 1.5 to 3.5 should go through pfSense and seemingly isn't (no states). So either something else is routing between those subnets, layer 3 switch maybe, or the client itself can access both subnets directly. Or perhaps it's just not sending, no default route?
-
The IPMI has a default route, I set it to 192.168.3.1. The 192.168.1.5 interface has no gateway.
No layer 3 switch, IPMI cable to cheap netgear switch, and cable from same switch to windows client. I can't have the windows test client 192.168.1.5 have a gateway because it's dual homed with a WAN interface and the WAN needs it.
-
On the real server setup, I am able to see the states when going to the 192.168.3.0/24 from the VPN net 192.168.50.0/24. I'm not sure what to make of it.
Although it doesn't seem to matter if the target http address is real or not, but I guess that doesn't matter, looks like it's making an attempt?
-
The states are correct but there is no translation. Did you add an appropriate OBN rule there too?
-
I see those states no matter if the OBN is there or not.
-
What OBN rule are you setting there?
-
-
Is that destination the address or subnet? It needs to be the OPT2 subnet there to match.
-
It's the subnet. Does I need this Outbound rule when setting the OPT2 (192.168.3.0/24) as local networks in the OpenVPN config?
. -
Yes you still need the rule because hosts in the OPT2 subnet will block access from the VPN subnet directly.
That rule should match if the subnets are correct.
-
Is there a way to just have the vpn clients land on the OPT2 subnet? Would that solve the problem?
-
Yes, you can setup the VPN as TAP and bridge the interfaces. But that will only work for one interface and you have 3. And it introduces a bunch of other things you don't want so I wouldn't recommend it.
Adding an OBN rule that matches will allow this to work. The best solution is to just allow it on the hosts though.
Make sure the rules are actually loading in Status > Filter Reload. Make sure it returns without errors.
-
Ok, I'm confused now.
Looks as if rules are being loaded without error.
This is my Outbound rule
