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

@mainzelman it works ! I have created on FW-B rule: LAN -> OVPN2 for it. Whatever before there was nothing to be seen in the FW logs. <don't always believe what you see ;-))>

Go back to auto, deleted all the other rules. then go to hybrid and create your rule for your boubound nat for your vpn. [image: 1612088293164-hybrid.png]

@daddygo 192.168.38.1 is LAN IP The PF-Sense is connected via a DynDNS Name 10.x.y.z is nessesary cause we are running a bunch of offices - 192.x.x.x does no longer serve us. We are changing all up to 10.X.Y.Z but till everything is up I need to connect the old firewalls with the new ones :-) Later on everything will be changes to 10.x.y.z :-)

@rico thanks wasnt shure ! lets keep it a bit more strict "clean" .... i dont wanna know how many more of these classy "iDontKnowJackRules" i m gonna find on thes boxes ;) brNP #stayHealthy

@griffo Yes about the prevention of traffic leaks.

@adelphi Sorry for bumping such an old topic, but it's very relevant. I can't understand why your method didn't work for me, as it makes perfect sense. It's even weirder that what I came up with did work. After firewall rules failed to achieve the desired result, I tinkered elsewhere. Here is a NAT Port Forward rule that achieved the same goal. Interface: LAN Protocol: UDP Source: Any (this is default) Source Port: Any (this is default) Destination: WAN address Destination port range: 1196 (our VPN port) Redirect target IP: Random private IP address that is NOT part of your LAN network. I used 192.168.1.254, but our LAN network is 192.168.21.0 / 24 Redirect target port: I just chose a random port. 45534 I was surprised that it even let me create this rule, but doing so made it so people who are connected to the LAN can no longer connect to the OpenVPN server while people connecting to the VPN from outside the office are unaffected.

It isn't something you'd check directly like that. Setup a VPN using that cipher and run a speed test across it. Try a couple different types of AEAD ciphers and compare. IPsec can use AES-GCM WireGuard uses ChaCha20-Poly1305 OpenVPN supports both AES-GCM and ChaCha20-Poly1305