@chuck1968 OpenVPN is OpenVPN. Doesn't need pfSense.
Just make sure settings are the same on both ends. Best to post pics so someone else can see because I'm sure you went through them already.

@thedharma Can you show pics of the outbound NAT?

You would just use the guest network as source and wan address as NAT address and all else as ANY.

My Solution

Install Shellcmd package Package Manager --> Available Packages --> Install The shellcmd utility is used to manage commands on system startup. Add a boot command to disable the OpenVPN services Find your 'OpenVPN ID' and whether it is a client or server from VPN --> OpenVPN --> (Servers|Clients) --> edit Services --> Shellcmd --> Add Command pfSsh.php playback svc stop openvpn server 1 or pfSsh.php playback svc stop openvpn client 3 ShellcmdType: shellcmd Description: Disable my OpenVPN on boot Repeat for each OpenVPN service you want to disable

@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 ) :

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!