|
|
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).
______________________
OpenVPN mailing lists
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|