Messages

Also posted on this a good while ago but never received a reply to this. Also tried a pool of VPN client connections but everthing would be routed out through the default internet gateway. Tried different tier settings (equal tiers and different tiers) to no avail.

Had given up on this and just set a gateway and no gateway groups for VPN clients. But if there's a solution or workaround for this, I'm happy to hear it.

Hi everybody. A long time happy OPNsense user here.
Updated to 24.7.4 and ran into some stuff I'd like to share here to help improving development.

My setup:
-    Dual WAN (Cable and fibre (PPPOE)) with both IPv4 and IPv6 enabled
-    Several client connections to my VPN provider (OVPN because of their native IPv6 support).
   All of the connections are bound to Localhost so that in case my primary connection (FTTH) fails, it'll still establish the connection through the WAN_CABLE interface.


My FTTH provider (KPN) does not give a WAN address, only a /48 prefix.
Before the "Optional prefix ID" option was available, I used an alias to assign an IPv6 address to the WAN_FTTH interface (solved some issues with the firewall not having an IPv6 on that interface).

Recently I switched to the "Optional prefix ID" and deleted the alias without any issues until this update.
After the update was installed all of my VPN connections stopped working.
Found an error in the VPN log: TCP/UDP: Socket bind failed: Addr to bind has no AF_INET6 record
Thought this was strange because an IPv6 address was present.

Switched one of the connections to my WAN_CABLE (which does get a native external IPv6 from DHCP6) and everything went up without an issue.

After I cleared the "Optional prefix ID" option and reinstated the IPv6 alias for WAN_FTTH, the VPN connections started working on the FTTH interface again as well.

Another observation:
When pinging the IPv6 address on the FTTH interface from within the LAN I get a reply from that interface but with the message "TTL expired in transit". This is true when using the "Optional prefix ID" and when using the FTTH alias setup.
Before this update I just received a normal reply.
Cable interface replies as expected with no issues.

If more details are required for better insight, I'd be happy to give them.

Came across this one looking for something else. But you probably don't have these options enabled / checked:
- Don't pull routes
- Don't add/remove routes

This will cause the OpenVPN connection to insert itself into the OpnSense routing table and this can cause a real mess.
Check these and then the OpenVPN connection will only be used if you explicitly route traffic to it.

Gentle bump

Is it possilbe to get OpenVPN Client interfaces working in a gateway group or do I have to keep using a specific OpenVPN interface in the rule like it is now

If any more information is needed to clarify, please let me know

Hi,

My setup:
- OPNsense 23.7.8_1-amd64
- Two WAN interfaces (KPN & Ziggo) with both IPv4 and IPv6 enabled
- Several VLANs to segregate traffic (Management, IOT, guest, etc)
- VPN connections to several servers in different locations with OpenVPN to OVPN

What I'm trying to achieve is a failover setup with OpenVPN interfaces to be used in firewall rules. So i can route specific traffic over VPN connections. I have setup several OpenVPN connections through different servers, added them to interface and put them in a gateway group.

When I add the gateway group to a firewall rule, it routes the traffic through the primary WAN (KPN), but if I select an individual OpenVPN interface, it works just fine.
Also tried setting up the VPN connections up using UDP (default) and TCP

Other gateway groups with only the KPN and Ziggo interfaces in them behave as expected, but if i throw an OpenVPN interface in the mix, it doesn't seem to work.
All VPN connections are bound to the primary WAN interface, but from what I've read it's better to bind it to localhost so it will reconnect instead of a WAN failure(?)

There's something I'm missing obviously. So I'm hoping to get some pointers in the right direction here.