Feature #752
closed
Ease policy routing across OpenVPN
0%
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?
Updated by Chris Buechler over 13 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.
Updated by Mr Horizontal over 13 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.
Updated by Ermal Luçi over 13 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.
Updated by Chris Buechler about 13 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.