You need to push the IPv6 /64 as a route. It needs to be distinct from the tunnel network. I assume you have more than a /64 to use? /48 or /56?

Similar to how HE's TunnelBroker provides IPs, Unfortunately TunnelBroker does not work in this case because they Block CloudFlare (YES THEY FREAKING BLOCK CLOUDFLARE!!!).

Based on my experiences with HE over the years, if they did in fact block these sources, they have a good reason for doing so.

Client-specific overrides are is required for SSL/TLS with a larger than /30 tunnel network when you have remote subnets/routes above and beyond the tunnel address for a Remote Access client.

There is really no difference between a Remote Access server and a point-to-multipoint site-to site network other than different requirements for pushing routing and CSOs. They are the same OpenVPN server mode.

Them will tested, thanks for your help.

@treborjm87

I'd be curious about this as well...

I think you need to establish how much throughput/bandwidth you need and how many concurrent user connections you anticipate, etc? (Is this box dedicated to routing and VPN only or more exotic use cases like running VMs, etc)

I've seen some charts floating around with hardware recommendations based on required throughput here and at the servethehome website.

@AlexVP I ended up using only one WAN.

As soon as I got rid of the second WAN, OpenVPN started working correctly. Under Firewall > Rules, I added rules to both LAN interfaces so they can't access each other. For the WAN interface, I added rules & under NAT > Port Forward I mapped the WAN ports to the CCTV LAN so it works how we need it to.

I know our network is fairly simple, but if you can make it work with one WAN it'll be a lot easier to manage. If I do set up a second WAN, I'll let you know what I did to make it work.

Thanks for the tips @Gertjan. If I had added logs it would've made it a lot easier to figure out what I did wrong. I made it work with one WAN, and I'm leaving it that way unless I need to change it.

Hi Rico,

thank you for your answer. I had a look to your link. I think this would work, but if the subnet on LAN on the pfsense boxes is changed I need to reconfigure everything.

Is there no option like:

On the VPN Server:
Route ALL traffic from User-01 to VPN network of pfsense box1

On the Pfsense Box side:
Route ALL traffic on VPN network to OPT1 network

Sorry for my question, but I´m a beginner with OpenVPN and pfsense...

Thank you so much for your support.

@jknott said in Unable to get Openvpn 2.4.6 to work on pfsense 2.4.4:

You don't set up DNS on the VPN. You do it on the client or DHCP server config.

My mistake, there is a setting on the server config, under Advanced Client Settings.

So your running HA pair setup... Kind of should of mentioned this out of the gate ;)

Why would you be running public IP vip on a rfc1918 network and then forwarding to it?

If you have traffic hitting interface X, and you wan it to be able to get to the IP and port your vpn instance is listing on - then just put a rule on that specific interface X to allow allow it.

Install the FreeRADIUS3 package and setup OTP/GA in there, and setup OpenVPN to hit that for auth, and use it today. No need to use an extra OpenVPN plugin or to reinvent the wheel.

Client export is not for Site-to-Site. It is for exporting configurations for Remote Access clients.

Configure both sides to match and you should be all set.

@bigsy wow! thanks. After trying stuff for 3 hrs this tip was the answer.

https://www.netgate.com/resources/videos/advanced-openvpn-on-pfsense-24.html

@kekskrümel said in No Traffic into OpenVPN Tunnel until Static Route is set:

0.0.0.0/1 to the tunnel gateway 10.100.6.29

0.0.0.0/1 is only the half IPv4 range, so this cannot stand for the default route.

Furthermore, how have you set that route? A static route on pfSense or a CSO?

Are you talking about an access server and you want to route the whole traffic of only one client over the VPN?
So if the server uses TLS/SSL auth set up a CSO for the clients cert common name and check "redirect gateway".

What VPN provider is this?

Have you verified that the routes being pushed actually cover the addresses of the sites you think should be routed that way?

Are any of the route add logs indicating failure?

Are the pushed routes actually going tinto the routing table?

If so, pfSense and OpenVPN are working fine here.

https://www.netgate.com/docs/pfsense/virtualization/virtio-driver-support.html