Project

General

Profile

Feature #752

Ease policy routing across OpenVPN

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

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
Start date:
07/20/2010
Due date:
% Done:

0%

Estimated time:

Description

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 10.0.0.140/30 as the local tunnel end point and 10.0.0.141/30 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 10.0.0.254, and is configured via a static route through 10.0.0.140 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 almost 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 almost 9 years ago

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

History

#1 Updated by Chris Buechler almost 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 almost 9 years ago

  • Tracker changed from Bug to Feature

#3 Updated by Mr Horizontal almost 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 almost 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 almost 9 years ago

  • Status changed from New to Feedback

#6 Updated by Chris Buechler about 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