Feature #752

Ease policy routing across OpenVPN

Added by Mr Horizontal about 9 years ago. Updated over 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


OpenVPN does all the ifconfig stuff of setting up the interface, so pfSense doesn't have to, but there are a couple of niggles with it when assigning the interface.

Assuming you have a typical 'topology net30' OpenVPN connection, you will have for example as the local tunnel end point and as the remote tunnel endpoint, with a /30 subnet so traffic can communicate between the two. However, the gateway will reside outside this subnet, say, and is configured via a static route through or 141 (can't remember which) to get to the gateway IP. As such when configuring a tun device as an interface with a static IP, can you ensure that it will accept the gateway as part of a /24 subnet and not a /30 subnet?

Associated revisions

Revision 7970b622 (diff)
Added by Ermal Luçi about 9 years ago

Ticket #752. Consider openvpn interfaces as ones with gateways now that the up/down scripts write the appropriate information.

Revision 9c43432a (diff)
Added by Ermal Luçi about 9 years ago

Ticket #752. Actually do this only for openvpn client instances.


#1 Updated by Chris Buechler about 9 years ago

  • Subject changed from OpenVPN client tun device assigned as interface gets confused with subnets to Ease policy routing across OpenVPN
  • Target version changed from 2.0 to Future
  • Affected Version deleted (2.0)

tun/tap interfaces should likely be treated as dynamic gateways, where that check doesn't exist (such as for PPP). But, the proper way to configure that is "none", not static IP. It's not a bug, moving to feature for the future. If you're going to statically configure the tun/tap, just use a /24 mask if you want it to check the /24.

#2 Updated by Chris Buechler about 9 years ago

  • Tracker changed from Bug to Feature

#3 Updated by Mr Horizontal about 9 years ago

This is how I work around the issue, by assigning the interface to a /24 subnet.

However, if you have a fresh OVPN client connection (assuming you don't have 'redirect-gateway def1' or use 'route-nopull' to override it and add 'route <remote_gateway>' as configs) then you will have a fully configured but unrouted interface to assign.

Assign this interface, then try to select the /24 subnet, and you will be presented with an error that the gateway doesn't exist in this interface's subnet - this bug report is to just to report that error, as it's not an invalid config.

#4 Updated by Ermal Luçi about 9 years ago

You should be able on latest snapshot see openvpn client connections in the system gateway and should be able to put them in a gateway group.

Please test and report back.

#5 Updated by Ermal Luçi about 9 years ago

  • Status changed from New to Feedback

#6 Updated by Chris Buechler over 8 years ago

  • Status changed from Feedback to Resolved
  • Target version changed from Future to 2.0

this has been good for a while, using it on a number of installs.

Also available in: Atom PDF