[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Issues regarding tun interface & ARP protocol


  • Subject: Re: [Openvpn-users] Issues regarding tun interface & ARP protocol
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Thu, 9 Dec 2004 14:51:04 -0700 (MST)

On Thu, 9 Dec 2004 stefano@xxxxxxxxxxx wrote:

> 
> Hi list, during some experiments I discovered a strange behaviour regarding tun
> virtual adapter, with linux.
> 
> Suppose the following setup: local network with some computers and an openvpn
> server.
> In simple terms, the problem is this: if from any computer I issue an ARP
> request for the address owned by the tun interface, which by default it is
> 10.8.0.1 (multi-client server mode), I got an ARP reply (linux as both client
> and server used in my test). Is this very strange or there is a reason for that
> to occur? To me seems strange, since the tun adapter has NOARP flag (see for
> example 'ifconfig tun0' or 'ip link').
> 
> IMHO this behaviour can have dire consequences. Imagine that the server has the
> management interface enabled, password-protected or not. This is very useful
> obviously since it allows you to control OpenVPN from an administrator computer
> connected to the VPN server. With the behaviour explained above one problem
> arise: every other computer on lan can talk  directly to tun inteface (i.e.
> OpenVPN process) even if it is not an authenticated client! One might say that
> the management functionality is password-protected, but this behaviour is
> definitely not correct and expose OpenVPN to brutal force or DoS attaks.
> 
> It is simple to reproduce the problem: suppose A is a computer on the lan, which
> is not an intended VPN user. In A, add an entry to the routing table that points
> to 10.8.0.1 on OpenVPN machine. With linux:
> 
> A # ip route add 10.8.0.1 dev eth0
> or
> A # ip route add 10.8.0.1 via 192.168.1.2
> 
> assuming that 192.168.1.2 is OpenVPN computer lan address. Now, assuming that
> the interface is bound to port 5000, try:
> 
> A # telnet 10.8.0.1 5000

Of course -- this is basic LAN <-> VPN routing.

If you don't want 10.8.0.1 to be exposed to the LAN, you can firewall it
off or use 127.0.0.1 instead.

> In my setup, this gives OpenVPN management interface (no password set in my
> case, otherwise obviously user-pass must be given).
> 
> I would be glad to know if this is a common problem... Assuming that it is
> common, it seems to me a problem that not relates to OpenVPN, since the tun
> interface has correctly the NOARP flag set.

You need to use firewall rules here if you want to restrict access to the
tunnel endpoint.  While it does seem that the ARP behavior is wrong (this
would be a Linux issue -- OpenVPN is out of the loop with regard to
TUN/TAP ARP), trying to disable ARP for an interface is not a substitute
for setting firewall rules and/or disabling interface forwarding.

James

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users