|
|
Mathias Sundman wrote:
On Sat, 19 Nov 2005, Daniel L. Miller wrote:
The Tap/Tun interface is the UNENCRYPTED, LAN-side connection - these
interfaces are used for communication with the LAN, and not the
Internet and/or VPN clients. So in the examples of a single NIC
OpenVPN server, the encrypted communication takes place via the
eth0. Where I was trying to use OpenVPN on my firewall, the
encrypted connection would be through the external interface -
therefore the internal interface gets the bridge for the unencrypted
side. Did I get it?
Correct.
So with a non-firewall implementation, my firewall must re-direct
OpenVPN packets to the internal OpenVPN server.
Correct.
After that, I can treat it as similar to any other firewalled service
- where I simply need to allow outbound traffic on the firewall.
Not entirely correct. As you have already enabled port forwarding so
your external OpenVPN clients can reach this OpenVPN server on the
local network through the firewall (with the help of NAT:ing), you
don't need to allow any outbound traffic on the firewall (other than
the reply packets of a already established udp or tcp session, but as
most firewalls are doing "stateful inspection" today, that will be
taken care of automagically).
And as you're doing bridging the accual traffic carried over the VPN
will never be seen by your firewall (other than as encrypted OpenVPN
packets).
Many thanks. The simple statement that the TUN/TAP devices are used for
the LAN-side unencrypted communications makes everything, if not
crystal-clear, just mildly streaky :). This also helps me understand
some of the problems I had in the past trying to get various xSwan/IPSec
implementations to work.
--
Daniel - "If at first you don't succeed, use a bigger hammer."
____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|