@griffo said in Route Traffic via VPN:

https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html

The second choices is what I want. To route all outbound traffic to my VPN provider.

@johnpoz

True. I never said that it has something to do with pfsense. But I found the problem and perhaps it might be interesting for others.

I dig a bit further and I did figure out that it has to do with the MTU Size of the packets in connection with certain providers.

How did I come up with it?
Yesterday I did configure one Notebook here in the office with openVPN and rdp connection. I did use our Guest lan to test it.

openVPN => works
RDP => works

Today the Notebook is at home and I have the described problem.

So I did start playing arround with ping MTU size (option -l) and did figure out that I can get a reply with packet size 1471 but not anymore with 1472.

I did use the custom option in openVPN server config and did try it with tun-mtu 1300; and it works!

I will now try to figure out what the best MTU size is.

thanks a lot for your help, always usefull to me!

@viragomann I agree, and we run pfSense with that turned on our on-premises hardware. However, when installing the official AMI in EC2 (and paying for it), I'd expect the defaults to be compatible with AWS' virtualized hardware edge-cases.

@gertjan Thanks for the link to the channel. I will definitely see everything.

You have two interfaces.
OPENVPN
OpenVPN

do they both need them to work correctly?

So after deleting the Virtual IP, clearing the "IPv4 Remote Network(s)" fields on both of the OpenVPN configs and adding in Static Routes for the remote subnets, it seems this is now working and the Static Route persists between tunnel reconnects. For some reason it still doesn't seem to work without defining a Static Route for the remote subnets to route over the VPN Interface gateway, but nonetheless, it works!

Would have never even considered to look in the Virtual IPs, thanks for your help @viragomann 👍

@tsptsp
So there should appear hints in the OpenVPN Log to find out the reason.

@johnpoz

I just downloaded the client, which I don't recall ever doing before. When I run it, it recommends TAP and says TUN is beta, which I am certain I've never seen before. Regarless, the exported client starts on boot up and connecting has not required a password before.

@sconvolt666 said in Openvpn Layer3 bridge:

when I invoke a service from site A from site B, the IP that invokes the services is that of Pfsense.

Huh? then you didn't setup a site to site vpn... But you have setup a road warrior?

With a site to site vpn, you would see the IP of the client.. There would be no natting going on.

192.168.1/24 - pfsA -- vpn -- pfsB - 192.168.2/24

When 192.168.1.x talks to 192.168.2.y, Y would see 192.168.1.x talking to it. And vise versa..

https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-psk.html
https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html

Have you reviewed this doc?:

https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-connect-to-oas.html

Thanks for the reply.

I have ended up using OpenVPN Connect an always on VPN and whilst not exactly what I wanted to do, it works for my apps in that it disconnects the VPN when I am home and works fine.

Just some of my apps when I am connected to the VPN act a little strange but that is for another post.

Cheers.

@viragomann All done. Misunderstanding on my Intranet Application state. You're right, using Intranet IP can access my Application.

Thank you very much, viragomann. You saved my days.

Ok, I found a solution for Remote Access Clients.

Shortform:

Openvpn Client: IP Forwarding configured (Borderrelay) PFSENSE: Client Specific Override for CN of the Borderrelay configured (Remote Networks added) PFSENSE: Borderrelay VPN IP as Gateway configured PFSENSE: OpenVPN Service restart

Now I am able to reach the Configured networks behind the Borderrelay from PFSENSE and also the PFSENSE Networks from the Client behind the Borderrelay.

@apsis-im You are welcome, enjoy :)