@michmoor Yes, exactly. But you can control his access by firewall rule anyway. If you allow the client only to access certain machines on your network and block the rest, the client will fail access the internet if he overrides the pushed routes. Hence I think, he will change his routing again. It is a known issue of some Linux NetworkManager versions to ignore pushed routes.

@germz1986 The VPN server pushes the default route to you, hence all upstream traffic goes to it. To avoid this check "Don't pull routes" in the client settings. Add all the IP you want to direct out to the VPN server to an alias. Then use it as source in a Policy Routing rule. Ensure to put this rule to the top of the interface rule set. Consider that with this rule there is no internal access allowed from the concerned IPs. Assuming that this is desired, create a second alias and add all RFC 1918 networks to it. Use this alias in the above rule as destination together with "invert." checked. So this rule is applied to any other destinations, but private networks.

Anyone have any suggestions?

@viragomann Thanks this did the trick

@jimp thank you Jim, I'm running into the same problem with some older VPN clients/certs.

@nogbadthebad the version I have is 2.6.0. maybe that would enplane why its not working when I try to follow tutorials cause there all out dated. I really appreciate you trying to help me... have a good holiday buddy...

@dotdash excellent thx. I'll try that.

@rcoleman-netgate no external 'Monitor IP' address works on the OpenVPN gateways. I can ping from a client PC on the network to external address with no issue once the connection is up. (System --> Routing --> Gateways) The monitor address is populated with the 'Gateway/Virtual Address' for this OpenVPN connection so it looks good to me.

@0ziris This is what I get on 22.05 ( from bottom to top ) : [image: 1670859796533-5c42778f-d346-4d78-b8a5-fa5d29b7aa79-image.png] The last 3 lines are the stop sequence. This is shown when the process starts : OpenVPN 2.6_git amd64-portbld-freebsd12.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] [DCO] built on Jun 4 2022 At that moment, 37441 was my OpenVPN PID.

@tact12 You have to provide the DNS server in the OpenVPN settings to get it pushed to the clients. And since your client might be in another domain as the server they have to use the FQDN to access it. E.g. MYSERVER01.remote.domain

@jknott Nope, but I just added a route and it's good to go ! Thanks!

@gertjan Thanks fo rthe reply. logs were not necessarily from the same session - I pasted the lines as reference to the error. BTW, after increasing the log-level to 7, it reveals that the error was coming from the outdated CRL but the error reporting was very generic and confusing. It started working since this morning.

@shadow_saunter said in Trouble passing traffic to OpenVPN server on digitalocean: Does the client log show that the routes are added properly? Yes, the client log would be in pfsense, and i see an "initialization sequence complete", and the interface negotiated an IP on the vpn, 10.8.0.34 on a /24 "Sequence complete" does not necessarily mean that the routes are added properly. It's more interesting, what's to see above of this line. Maybe you could post the log. But since your interface is showing an IP, at least the tunnel subnet will be assigned correctly and you should be able to ping the server IP if it is allowed. Can you ping the servers virtual IP, LAN IP? Can you ping other devices on the server side? Are there firewall rules on both sites to allow access? this is where i'm at a loss, 10.8.0.1 doesn't answer when i try ping from pfsense Can you ping it from another VPN connected device? pfsense doesnt answer when i ping 10.8.0.34 from my phone on the vpn (other devices do) That's not a good indicator for the a working VPN. This would require that the client-to-client communication is enabled on the server, which isn't by default. Also it requires that the access on the source device is permitted. For testing you can try to ping pfSense from the server, while you run a packets capture on pfSense on OpenVPN to see if packets are transmitted. the only rule i have made so far is <screenshot coming>: Source: PRIVATE_VPN Port: * Dest: * Dest Port: * Consider that this rule only allows access from inside the VPN tunnel network. What do you mean by both sites? I use 1194/UDP, and i allow that on the VPN server using an iptables rule set that loads at boot. I can imagine that the server also needs a rule on the OpenVPN interface to allow access. But if other devices are able to access the server and other remote devices it should also work from pfSense itself. Do i need a rule on the pfsense WAN? No. What does the fact that it negotiated an address tell me? I think it means that it reached my VPN server on 1194, and the server used 67 or 68 for DHCP and was successful. Yes you reach the VPN server, but there is no DHCP protocol on OpenVPN. So it doesn't indicate that IP is working.

@warningsystem said in Access to the client terminal connected to the VPN: My question is, from the company's network can I connect to this client, access the data from his machine? The needed data are on the client machine itself, as I understand? Accessing the network behind the client was more complicated and would need a client specific override, when running an access server. You can access the client itself simply by its virtual IP. You can add a SCO anyway to assign a static virtual IP to him. But you have to allow the access on the clients firewall at all. A trick I'm using for Windows clients to enable access to them is pushing the default route to them, but with a high metric by adding this into the servers custom options box: push "route-metric 512";push "route 0.0.0.0 0.0.0.0" This makes the client "smooth", but networking has to be enabled on the client anyway. However, consider that the pushed metric is applied to any route which is pushed to the client, but worked well.

@viragomann maybe, except like I said before, it works on Android, but not on PC. And both these devices are on the same network. I'm still struggling with this. I will keep trying though!

@gertjan You were very objective. Thank you very much, As I'm starting in PFsense it doesn't cost anything to put this CRON to restart at night. like I mentioned to you very strange, this happens to some person or other and expected. It seems that OPENVPN stops listening to that user, then when I restart it through the GUI, the client connects, but like, there are others connected and everything is working normally. But it's fixed, thanks a lot for your support.

@fadushin +1

@philipt said in VPN to my home network without access to all resources: I wouldn't be able to tell you if I am, I just followed a guide on IIRC the official wiki. Typically people post screenshots of their configs with public IPs and keys/password redacted. I suggest you want to do that at this point so we can point you in the right direction. As for opening a port -- I wasn't suggesting opening a port to the Pi, but to the pfSense so that if you lock yourself out of the VPN you can still make changes until it is running how you want it. After that you turn off the firewall rule that allows remote access.