|
|
jessica six wrote:
3) This setup would be used for clients travelling, and needing access to internal resources. Routing would require routes on ALL internal resources to use the Openvpn server for the range of addresses it assigns. I don't think this is what I want. With bridging, the client is assigned an IP on the internal network and all access works. There's another approach which doesn't require modifying the routing tables on your internal systems: Your site's default gateway can have the route to the VPN server. That way, instead of modifying the configuration of the internal machines, you simply route packets host->gateway->vpn. Granted, it may not be as much of an issue if you use ebtables or such to filter broadcast traffic. Using a tap-based VPN means you end up paying (unfiltered-broadcast-traffic-on-LAN) * (#-of-VPN-clients) in external-network traffic, plus some overhead for the Ethernet frames (which aren't transmitted over a tun-based VPN).
Warning: require_once(../../../archive_common.php) [function.require-once]: failed to open stream: No such file or directory in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2006-05/msg00087.html on line 192 Fatal error: require_once() [function.require]: Failed opening required '../../../archive_common.php' (include_path='/usr/local/lib/php') in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2006-05/msg00087.html on line 192 |