bummer.. ok. well thank you very much for the help. I really appreciate it.

@viragomann thank you so much it worked very well, however, somehow, everytime that i change rules or nat settings, i have to reboot the pfsense... otherwise it doesnt work.

Maybe i will have to reinstall it. I loved PFENSE. no comparison with that horrible ASA.

regards,

Thank You!

https://www.netgate.com/resources/videos/openvpn-as-a-wan-on-pfsense.html

-Rico

Still hard to understand, what you really have there.

As read this, you're running an OpenVPN remote access server with tunnel network 192.168.30.0/24, where clients connects to and access local networks.
Further you have set up an OpenVPN client, which connects to a remote server and gets the virtual IP 10.8.0.126.

Now the clients of the remote access server should be able to access networks behind the client connection. Which networks?
Are the routes set and are you able to access these networks from pfSense?
Is that a site-to-site VPN or are the routes pushed by the server?

We need more info. What is your LAN subnet? Are you routing all traffic over the tunnel or policy routing? Your screenshot isn't showing enough info either.

@toni-networking said in Remote Access OpenVPN:

Is just working my VPN remote server

Not sure what that means. Please rephrase.

If you are doing a site-to-multisite with pfSense as the hub are you doing individual tunnels to each client or a single server with multiple clients connecting to it?

If you have a single server you will need to add client specific overrides for each client with the subnet behind them so OpenVPN knows which client to route traffic to.

Either way it sounds like you have a missing route in one direction. Check the routing tables at each end and makes sure the opposite subnets are present.

Steve

You need to state a specific destination address. Forwardings with destination "any" to a single host don't work.

thank you alot for your help

Personally I always use Certificates (SSL/TLS): https://docs.netgate.com/pfsense/en/latest/book/openvpn/site-to-site-example-configuration-ssl-tls.html
My Options are:

TLS Configuration: Use a TLS Key TLS Key usage mode: TLS Encryption and Authentication DH Parameter Length: 2048 bit Encryption Algorithm: AES-256-GCM Enable NCP: OFF Auth digest algorithm: SHA256 Certificate Depth: One (Client + Server) Compression: LZ4-v2 Topology: Subnet

Maybe you want to disable compression because of the VORACLE attack: https://forum.netgate.com/topic/133930/new-openvpn-attack-demo-d-at-defcon

-Rico

Well, I have just got it working. The solution may be very specific to my scenario.

First, I need to go through and test all the individual changes I made to ensure each one was needed, remove the cruft that was not needed and I will post the final solution here there after.

What I had to do in this scenario was go Pfsense A, go to advance settings of IPsec, From there:

Auto-exclude LAN address Enable bypass for LAN interface IP Exclude traffic from LAN subnet to LAN IP address from IPsec.

This box was checked by default.

I cleared it and traffic is now working both ways.

I suspect what mattered here was the fact that Pfsense A didn't have a LAN subnet, and OpenVPN client subnet may have been seen as a LAN by this rule. I am sure one of the Pfsense developers could provide an explanation.

Now I just need to check all the routes, rules, Phase 2 parts to ensure they are needed.

I didn't understand the route command. By adding this line:

route public.pfsense.ip 255.255.255.255 net_gateway

openvpn isn't routing the pfsense public ip through the vpn tunnel.

The problem was that in our environment we force to route the whole traffic through the openvpn server and this broke stunnel. Cause with this configuration openvpn wants stunnel goes trough the vpn tunnel and this ends in timeouts. By excluding the psense public ip (stunnel runs on this ip, too) it keeps the connection, also while vpn is running.

And the dns problem was a different one. I used the gnome vpn manager, before I tested the stunnel-thing with the openvpn command line. Gnome manager was setting everything in a proper way, but the openvpn command line tool not.

So, I had to do the following things:

sudo apt-get install resolvconf Add to openvpn client conf: script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf

Greetings Yannik

So here is a drawing of the network.

d51f6d59-d87e-475f-8485-ad799f7b3eef-image.png

using ssh the client can connect to PF1, Server A, Server B, as well as PF2, Server C and Server D
using html the client can not connect to PF1 or Server A and B, but can connect to Server C and D as well as PF2.
the client can connect via OVPN to a client on the network behind PF2, with RDP and then use that client to connect to PF1, Server A and Server B with HTML through the IPSEC tunnel.

Both pfsense boxes have the default (everything to everything) OpenVPN rules.

Uninstall whatever version you have and then install the latest OpenVPN 2.4 client.

It needs admin privileges to install, but not to run.

So you had a working setup with VPN speeds around 50MBit/s and without touching anything it's down to 10MBit/s?
Definitely sounds upstream/ISP to me. Not implicitly incident, maybe they capped some Ports or low QoS VPN traffic?
You are in TLS Authentication mode? Try TLS Encryption and Authentication.
Also try to change Port for OpenVPN, e.g. some real-time application port like SSH (22) for testing.
Should not be your actual problem but I'd go for AES-128-GCM or AES-256-GCM not CBC.

-Rico