New OpenVPN server, can connect but can't get to LAN subnet.
-
@viragomann I didn't know it was for client and server but always suspected. I added the rules Source 192.168.193.0/24 pass to destination LAN net under OpenVPN Rules. If I remove the rule any rule I can no longer ping anything on the LAN.
I have two subnets. One goes out ExpressVPN and the other out my ISP. I do this for a number of reason but mainly paying around and to change my location for NFL games. The LAN is my ISP and LAN4 is the ExpressVPN connection.
This is the part I get lost at. Under Interface Assignments I added OVPNSERVER and assigned what I thought was the OpenVPN server.
I might have done this for nothing and shouldn't have but I was completely lost and hoping it was something I missed. I don't remember doing this on the other Netgate but I read something online that hinted this might be the problem. Again could be way off track. Should I remove this?
I don't have any floating rules. My expressVPN client just has an any to any rule. The only think I have under LAN4 is it can't use my WAN_DHCP gateway and to use ExpressVPN gateway. I found this to be the easy way to split the traffic.
-
@fatman032
I highly recommend to remove the rule from the EXPRESSVPN interface. This rule allows incoming connections from ExpressVPN to any destination in your network!
I assume, incoming traffic is not desired at all. If not, there isn't any need to have a rule on this interface.Having the OVPNSERVER interface for the access server is not wrong. But since you have it, you can move the rules for allowing access from VPN clients from the OpenVPN tab (interface group) to the OVPNSERVER. Simply edit the rule and change the interface.
And what do you have on the floating tab? Your log shows traffic permitted by floating rules.
If the LAN4 devices use the pfSense for DNS resolution you need to allow this by a rule. The pass rule on LAN4 directs all traffic to the EXPRESSVPN gateway and doesn't allow DNS access to pfSense.
Here a floating rule can do a good job. You can add a rule with Quick option for DNS (TCP/UDP port 53) to destination "This firewall" and select all desired interfaces (LAN, LAN4, OVPNSERVER) to allow DNS for all devices with a single rule. -
@viragomann Again I can't thank you enough for the help. I'm learning a lot. I need some time to process all of this but I think I'm getting most of it.
I never had anything in floating rules. In my post above you can see that. I never fully understood why you would use that rule set.
Here are some changes.
I just added the rule about DNS under floating rules.
Here is my LAN rules. No changes
My LAN 4 interface rules. No changes
I removed the any rule on ExpressVPN
I moved the openVPN rule to OpenVPNServer interface.
Now under openVPN I have no rules again.
-
@fatman032
Okay. The floating rule is not correct. Two things to change:Check the "Quick" option. This ensures that the rule is applied before a matching interface rule. Without Quick your LAN4 cannot access DNS, because there is a block rule.
The source port in the rule has to be "any" as almost. The source port is dynamic, so you must not state it.
Further on LAN4 in the block rule the gateway setting is useless. The gateway only comes in if the rule matches (interface, protocol, source address and port, destination address and port), but since the rule block anything anyway, there is no use of stating a gateway.
-
@viragomann Got it. I made the changes. I just tested the VPN and I'm still getting blocked.
-
@fatman032
Fine. That was just a rule clean up as mentioned before. Now the firewall log should be better readable.
So are there news?I assume, your pfsense is the default gateway in the LAN?
-
@viragomann Yes the default gateway for the LAN network it pfsense.
Here are the new logs. I agree much cleaner.
-
@fatman032
Since the ping from 192.168.193.2 to 192.168.192.10 is blocked in the second line, the rule on the OPENVPNSERVER does obviously not match.
So either 192.168.193.2 is not included in "OPENVPNSERVER net" or 192.168.192.10 is not included in "LAN net"I'm wondering, where do you get the "OPENVPNSERVER net" from?
I've also assigned interfaces to access servers, but there is not ...net generated by pfSense.So I'd replace that by 192.168.193.0/24 and try again.
Further the log shows that the VPN client tries to access 1.1.1.1 for DNS resolution, which is not allowed.
Obviously you route the whole clients upstream traffic over the VPN. Is this what you want?
If yes, you might also have to configure the outbound NAT for the tunnel network. -
@viragomann I changed the rule for OpenVPNserver. Still no go.
I wouldn't mind a spilt tunnel. If I uncheck the box to "Force all client-generated IPv4 traffic through the tunnel.". I don't get any blocks from 192.168.193.2 (source or destination) but still can't get to my devices.
I do get blocks and lots of them if I check the above box.
-
@fatman032
A view to the logs would be helpful.Is the access from 192.168.193.2 to 192.168.192.10 still blocked by the default deny rule?
If you unscheck "redirect gateway" you have to enter your LAN network into the "Local Networks" to push the proper route to the client.
-
OP is using a bogon address as the tunnel 192.168.193.0/24
Just FYI
-
@chpalmer
No, it's a private one out of 192.168.0.0/16. -
If I setup the VPN this way. I get no blocks from 192.168.193.0/24
Filter source 192.168.193
Filter Destination192.168.193
I do get blocks on my WAN interface but I don't think they have anything to do with OpenVPN. I'm little scared to post those log on the internet since they have my public IP address.If I setup the VPN this way.
I get blocks. No filter
This why I'm so confused.
-
@fatman032 said in New OpenVPN server, can connect but can't get to LAN subnet.:
I'm little scared to post those log on the internet since they have my public IP address.
No, you shouldn't show your public IP here. If the logs were relevant you can disguise it, but they might not be.
This why I'm so confused.
All right with that now. The log shows solely blocks to public IPs.
I mentioned already above, by checking "Redirect gateway" the client routes the whole upstream traffic to the vpn server. But your pass rule on OVPNSERVER doesn't allow it, it permits access to LAN net only. -
I mentioned already above, by checking "Redirect gateway" the client routes the whole upstream traffic to the vpn server. But your pass rule on OVPNSERVER doesn't allow it, it permits access to LAN net only.
I understand that. I just wanted to show this is the only blocks I'm getting now. Also I setup a NAT rule to allow 192.168.193.0/24 out. Not sure why they are still getting blocked. This isn't the part I'm confused on.
The part that I don't get is why I'm not seeing any blocks now form this network to my LAN network.
-
@viragomann Should I have any rules under OpenVPN?
-
@fatman032 said in New OpenVPN server, can connect but can't get to LAN subnet.:
The part that I don't get is why I'm not seeing any blocks now form this network to my LAN network.
Possibly because pfSense doesn't block any.
Maybe the remote device blocks the access by its own firewall. Since you said, this was already working before, this shouldn't be the case, but possibly you had set up a workaround with masquerading.To investigate on pfSense you can take a packet capture on LAN, while you try to access from the remote client to see if the device is responding properly.
-
@viragomann I think I found part of the problem. I added the OpenVPN rule back in. I can now see blocks from 192.168.193.2
-
@viragomann said in New OpenVPN server, can connect but can't get to LAN subnet.:
@chpalmer
No, it's a private one out of 192.168.0.0/16.I see that now.. I was an octet off.
-
@fatman032
These blocks are out of state packets. That is no traffic which should be allowed at all.
However, I've no idea, why you see this only, when you allow traffic on the OpenVPN interface.Is the port 5000 this one you tried to access from the remote client?
