I don't know the ins and out of how this security device works. But clearly it has a gateway (pfsense). And there is no reason to do the source natting of your vpn connection. From what you have shown the device is answering.. But was showing RST from your client, and Fin,ack from your device to your clients.. Both are ways to END a conversation. So what is actually the issue with vpn vs internet not sure? But from what you have shown pfsense is doing what its told to correctly. I would suggest you sniff on pfsense opt1 interface for your device IP. Set the sniffing packets limit from 100 to 0 so you can see the full conversation... Then start a conversation from internet doing your normal forwarding.. So you can see what is all involved with normal working conversation. Then make sure you kill any states for this conversation.. Reboot the device say, and then doing the same sniffing and talking from your vpn client.. So you can see what might be different? Off the top of head, thing that might be different while your on the actual internet with your client doing port forwarding on pfsense is you have access to internet from your client via the same connection. While your vpn connection would change that sort of connection, etc. Its possible your device phones home and checks something before allowing connection? It could be all kinds of things. But from what you have shown pfsense is doing exactly what it should be doing, and again doesn't care if your coming from the internet or a vpn.. It just allows the traffic or it doesn't..

Nevermind, the reason was that the openvpn had topology net30... changed it to subnet and things are working!

@viragomann said in Cannot access LAN resources: Have you updated the "Local networks" in the server settings to your new LAN subnet? Forgot that, fixed now. On WAN interface you have two equal OpenVPN wizard rules. So you may delete one. I did delete the whole vpn server and reconfigured it with wizard before posting here so apparently it made duplicate rules. Fixed now. You're allowing access to anywhere on the OpenVPN tab, so ensure you can trust all clients. I'm the only one using the VPN and I'll add SSL/TLS auth for more security. Thank you again!

If the --client-to-client option (Inter-client communication) is active, these packets are not exposed to the server host (pfSense in this case). Firewall rules will therefore not have any effect. https://community.openvpn.net/openvpn/wiki/HowPacketsFlow Check the client(s) firewall.

https://redmine.pfsense.org/issues/10650 -Rico

Dear viragomann, Thank you a lot for your answer. I just resolved my problem, problem I created myself. Fyi, let me answer to you : Yes I see the route on both sides and firewalls rules are ok. Also, I'm not doing the site to site only but the multi-purpose instance (sorry) : The solution was : (I'm ashamed), I did not realize that physicaly unpluging the interface deactivate the said interface and then make it unreachable, even under an icmp ping... I'm sorry for the inconvenience. Thanks again, Yorik

try to set net.link.ifqmaxlen="2048" see https://redmine.pfsense.org/issues/10311

Since you push the default route to the VPN client, also provide a DNS server and care that it is reachable. If you don't want to direct all traffic over the VPN, don't push the default route or check "Don't pull routes" in the client settings and add the routes manually.

Think like a packet. You send a packet in one direction, and you expect a different packet to come back as a reply. The first thing to check is to see (at a target) if a packet is actually getting to it. If so, you have a return routing problem possibly, though. Especially if the pfSense is not the default gateway to the internet. You also may not have put the best IP address choice for the VPN subnet. It's not the same as the internal LAN, is it? At any rate, I like to use Wireshark and packet captures to see where the packets are going. If nothing shows up at the destination, then move to (or start with) the pfSense and do a packet capture there. You are looking for packets coming out of the tunnel, including your ping tests to pfSense. Look for the addressing on the packets to see if the source and destination addresses are as expected. And you will need a filter rule on the pfSense to allow the traffic, under Firewall, Rules, OpenVPN. What do you have in there? I've got a simple Pass rule for any to any. That said, I set it up once as a quick test and didn't really do much testing, but I think it worked fine to my internal LAN.

@DutchSamurai What you ask is straight forward. pfsense with openvpn can do that. In your particular case, there are remote lans with conflicting ip ranges and there isn't much one can do about it. Its either nat, or renumber. Both will work fine. It can be done either by installing pfsense at the remote locations, or just keeping the current linux gateways Managing thousands of devices effectively does require some solid planning.

@Rico What I did was dial both tunnels into the same OpenVPN server instance at HQ. I figured as no routes were added to the backup it would work. I guess I figured wrong. I'll try setting up another OpenVPN server instance for the management tunnel.

@ScrubCoders said in Few Questions about OpenVPN: I was wondering if there was a way to log when a user disconnects from the OpenVPN within PFsense. Use the [image: 1600927676180-51c579bd-5ae2-4684-9a47-98e21294dbc9-image.png] a lot posts (thousands) where made about this subject this year when VPN became suddenly very popular. Scripts, logs, mails, what ever, can be implemented when users log in, and logged out etc.

And u folks here made my day here! Greets from Europe