OpenVPN 'privileged' clients?

I've setup a small VPN for my home network which allows me to connect to my home linux 'server' from my laptop. I have NFS and Samba shares configured on the server and am able to successfully mount those shares and otherwise access the server through the VPN connection. This works great. I've also gone and configured my wife's (Windows-based) laptop to connect to the VPN as well to access the same drives.

In my OpenVPN server config I do *not* have client-to-client enabled- so each client can only 'see' the server. But recently I've encountered a situation where I might need to remotely connect (using RDP/rdesktop) to my wife's laptop from *my* laptop via the VPN. Enabling client-to-client would probably help me in this aspect, but on the flip-side, I do *not* want her laptop to 'see' my laptop on the VPN, and enabling client-to-client would certainly allow that. Essentially I would like my laptop client to be 'privileged' such that it can 'see' the rest of the VPN network, but the rest of the VPN network (with the exception of the server) cannot 'see' my laptop.

Is there any other way of configuring such a connection? Is it possible to do with routing on the VPN server, or perhaps forwarding with iptables? I'm admittedly a relative newbie when it comes to both routing and iptables. or would a better solution be to enable client-to-client and then use iptables on the VPN server to prevent 'unprivileged' client machines (the wife's laptop) from seeing any other machine on the VPN besides the server?

Any help or suggestions are greatly appreciated.

Thank You,

- skubik.

Don't know whether this will help but I needed a situation where an OpenVPN client needed to find a route through to another machine on the internal network. Because I only wanted the access to this other machine restricted to a few remote clients I used the ccd stuff in OpenVPN - uncomment the

client-config-dir ccd

statement in the server, create the ccd directory (off /etc/openvpn or wherever your openvpn server stuff is) and in it put a file with the same name as the client's vpn name (in my case I use client1 , client2 etc) and in that file put the route statement like

push "route 192.168.2.192 255.255.255.192"

. What this does is push a specific route command to that client which it knows goes over the VPN. My particular example was to allow the client to connect to any machine in the range 192.168.2.192 to 192.168.2.254. To connect to another VPN client using 10.8.0.x I would assume that similar logic would apply. I'll try this out myself later to see if it works

Tried this - established the route correctly on the client but pinging the other client didn't work although it does from the server. Therefore probably need the OpenVPN server client to client stuff to do it via the OpenVPN server.

I thought I would update the thread since it's been a while.

I did, in fact end up enabling client-to-client to allow clients on the VPN to see each other.

I assigned certain clients (Windows boxes mostly) to a separate subnet by assigning the VPN IP addresses in the ccd directory on the OpenVPN server machine. I then used the 'push "route 10.8.1.0 255.255.255.0"' command within the ccd directory files for those clients on the subnet to allow the Windows boxes to 'see' each other and not just the 'admin' subnet.

So right now I'm essentially able to 'see' all the VPN client machines from any client on the VPN- but the problem now is, going back to my original issue in the first post, I don't necessarily want all the VPN client boxes to see all of the other clients on the VPN- only certain ones.

In particular I would like the Windows boxes on the 10.8.1.x subnet to see the VPN server (10.8.0.1), as well as each other- but not any of the other 'admin' clients on the 10.8.0.x subnet.

So I figure iptables is probably the way to implement this on the VPN server, but I'm not quite sure how to proceed. I've dabbled with it for the last few weeks and have gotten nowhere. I am an iptables noob, so perhaps I'm missing something painfully obvious.

Any suggestions/examples of how I might go about setting this up? Or am I taking a completely wrong approach to this?

Thanks,

- skubik

I think the problem in essence is that although all OpenVPN clients can see the OpenVPN server, the only way to allow OpenVPN clients to see each other is by the all or nothing client-to-client stuff. What this does is do all the routing through the OpenVPN server application and therefore I don't think iptables will help.

However, what might work is to run two OpenVPN servers - an open one for all the clients to see each other using the client-to-client stuff and the other for the admins. Then I think you can use iptables to allow the admin network access to the ordinary network.

I'll have a play with this myself in the next couple of days and let you know the outcome.

Thanks Andrew for all your help thus far. I tinkered with iptables last night and I'm beginning to think you're right in that client-to-client is an all-or-nothing solution. I completely locked down my openvpn server box and was unable to send a ping from my laptop to one of my Windows boxes via the vpn- so that does indeed indicate that the vpn traffic is going through the openvpn server itself. Whether it is in the application itself or not I'm not sure. I tried applying an iptables rule to only accept traffic on the tun0 device from 10.8.0.x, and yet I was still getting those from 10.8.1.x connecting without any problems.

Having multiple openvpn servers running would be okay. Would I need to bridge them somehow? I'm still relatively new at openvpn so any help is greatly appreciated.

I too will continue to tinker and see what I can whip up.

Thanks!

- skubik

From the OpenVPN man pages:

--client-to-client
              Because the OpenVPN server mode handles multiple clients through
              a single tun or tap interface, it is effectively a router.   The
              --client-to-client   flag  tells  OpenVPN  to  internally  route
              client-to-client traffic rather than pushing  all  client-origi‐
              nating traffic to the TUN/TAP interface.

              When  this  option  is  used,  each  client will "see" the other
              clients which are currently connected.  Otherwise,  each  client
              will  only see the server.  Don't use this option if you want to
              firewall tunnel traffic using custom, per-client rules.

Therefore it does look like an all or nothing and probably you could construct iptables rules to route data between specific clients. However, although I do have iptables experience routing between different interfaces, what's required here (I think) is routing between clients on the same virtual interface! In addition you have to know the IP addresses of each client, so you need to specify these in ccd files for each client, and have an iptable rule for each client pair. Not a scalable solution!

Running multiple OpenVPN servers on the same host is straightforward (in theory!) all you need is to specify a different port for each. Don't know whether you need another tun device, but it might be easier.

In my case my internal LAN is 192.168.2.x and the VPN is on 10.8.0.x so I have iptables rules to forward from 10.8.0.x to 192.168.2.x and allow responses coming back. If I had another VPN on 10.8.1.x I'd copy the iptables rules to allow that access to the 192.168.2.x LAN. Then if the new VPN was the admin one I'd then add rules to allow access from 10.8.1.x to 10.8.0.x. In theory that should work and you can then have client to client on 10.8.0.x so that normal users can see each other and not on the admin VPN.

Haven't had a chance to try this out yet but I will in the next few days as it's something useful for me as well!

Actually, I do know the IP addresses of each client. Luckily I'm not dealing with a substantially large VPN here- so it quite literally is my discretion to assign VPN IP's accordingly. So, then, the solution might be to *not* use client-to-client and setup iptables rules to route traffic according to the subnet being used?

I will give this a try tonight and hope for the best. This is somewhat along the lines of what I originally wanted to do as it gives me a little more 'control' over what clients can see what on the VPN. Now that I have a little experience with iptables- this might not be such a daunting task.

I'll post my findings as well.

Well I've done a bit more experimentation and you can indeed do it in iptables. In my setup client1 is 10.8.0.10 and client2 is 10.8.0.14. Before doing any investigation the server could ping both but neither client could ping the other. I looked at my firewall logs and ascertained that the ping requests were being dropped in the FORWARD chain so I added a forwarding rule to allow access from 10.8.0.10 to 10.8.0.14. I use SuSEfirewall2 to generate the iptables stuff, however, looking at iptables-save for 10.8.0.10 I think the core rules must be something like:

iptables -A FORWARD -s 10.8.0.10 -d 10.8.0.14 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.14 -d 10.8.0.10 -m state --state RELATED,ESTABLISHED -j ACCEPT

The good news is that provided you know both clients IP addresses you don't need to do anything else provided your default route for client1 is over the VPN. Once I'd added the firewall rule I was able to ping client2 from client1 but not vice-versa and also use Windows explorer to browse that machine (using \\10.8.0.14 as the URI).

Hope this helps.

Thanks for this Andrew. I tried fiddling with it last night as well- specifically I disabled client-to-client, restarted the openvpn server (which caused other problems- most notably, one of my XP clients still shows up as being connected in the openvpn-status.log file, but I cannot ping it at all from the server.) and checked to ensure that I could ping the clients from the server, and the server from the clients- but not from client to client. So in that case- I'm on the same path as you were.

I did also try adding FORWARD instructions in iptables, but not quite the same as yours. Mine were along the lines of:

iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 10.8.1.0/24 -j ACCEPT
iptables -A FORWARD -i tun0 -s 10.8.1.0/24 -d 10.8.1.0/24 -j ACCEPT

That is, allow the 'admin' subnet (10.8.0.x) to see the Windows subnet (10.8.1.x), and allow the Windows subnet to see itself.

This failed, however. But looking at your entries, I might understand why since it technically is an established connection through the tunnel, correct?

Also, I have *NOT* enabled IP forwarding as I have seen suggested by executing the following:

echo 1 > /proc/sys/net/ipv4/ip_forward

Is your system configured for this? I was confused as to why my attempt didn't work, and I figured it had something to do with this- but it could very well be the state information you had in your commands too. I'll try both approaches tonight.

Thanks,

- skubik

Originally Posted by skubik echo 1 > /proc/sys/net/ipv4/ip_forward

Yes I have this set

Originally Posted by skubik iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 10.8.1.0/24 -j ACCEPT iptables -A FORWARD -i tun0 -s 10.8.1.0/24 -d 10.8.1.0/24 -j ACCEPT

The first iptables statement will allow all traffic from 10.8.0.0/24 to 10.8.1.0/24, however, there is no route back for the replies. If you don't add the state stuff then by adding the reverse route you will open the forwarding both ways. Therefore:

iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 10.8.1.0/24 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i tun0 -s 10.8.1.0/24 -d 10.8.0.0/24 -m state --state RELATED,ESTABLISHED-j ACCEPT

should give you the correct rules. Because NEW connections are only allowed from 10.8.0.0 to 10.8.1.0 it is one way. I should get this bit working first before adding the other:

iptables -A FORWARD -i tun0 -s 10.8.1.0/24 -d 10.8.1.0/24 -j ACCEPT

Found a really good note on advanced techniques which would allow you to add firewall rules dynamically on clients connecting. I suggest leaving until later! http://searchnetworking.techtarget.c...220516,00.html

So I've tried modifying my iptables commands- but to no avail.

I did go ahead and execute enable ip forwarding in Linux- then added the iptables. But I am still unable to ping between or within subnets. All clients can ping the server- and I can ping the clients from the server, but pinging a Windows client from an 'admin' subnet client is still a no-go.

Am I missing something? the policies on my INPUT, FORWARD and OUTPUT chains are all 'ACCEPT'- no other chains anywhere else except for the ones I've added to FORWARD.

Essentially my commands were as follow:

iptables -A FORWARD -i tun+ -s 10.8.0.0/24 -d 10.8.1.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun+ -s 10.8.1.0/24 -d 10.8.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun+ -s 10.8.1.0/24 -d 10.8.0.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Nothing radically different from what we were thinking before.

Could it be a routing issue with Linux itself?
My routing output on the OpenVPN server box is as such:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.1.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         router          0.0.0.0         UG    0      0        0 eth0

I have both subnets listed, so I'm a little confused. What about routing configuration on the client machines? One of my 'admin' machines also has a similar routing setup.

Any insights?

Thanks,

- skubik

Well it looks as though it should work. My routing table looks similar to yours except I've only got one VPN network - 10.8.0.0. I've got default drop policies on my iptables setup with logging of dropped packets so I was able to see in the logs that the iptables rules were blocking the packets. The order of rules as you know is important but if you've only got the forwarding rules then that shouldn't be the issue. Presumably because the VPN is working it's not a firewall issue on the client and because the server can see all clients it can't be a server issue. Therefore the only thing I can think of is that you need to add a route on the clients for the other VPN ie if it's on 10.8.0.0 you need a 10.8.1.0 route. eg:

push "route 10.8.1.0 255.255.255.0"

in the client ccd file. If that doesn't work then it's back to iptables logging and packet sniffing with wireshark I guess to see where it's failing. Oh I forgot you can also turn up the OpenVPN logging to see if that gives you any clues and there may be some messages in your system logs. Good luck!

Can you post your vpn server conf file?

SUCCESS!

I worked steadily on getting everything up and running over the weekend and I'm happy to say that everything is working wonderfully now.

My solution?

First, I added the following to all the vpn client files in the ccn/ directory:

push "route 10.8.0.0 255.255.255.0"
push "route 10.8.1.0 255.255.255.0"

This is to ensure that all subnets have some route to the other subnets- even though we're going to prevent certain communications with the firewall on the OpenVPN server anyways- we at least need a way to get messages back to the subnets. I found that some of my Windows clients did not have a route to the 10.8.0.x subnet- so it could not send messages back to a machine on that subnet regardless.

On the OpenVPN server machine I have these same routes configured- which is necessary for it to perform routing between the subnets.

So, my firewall issue? I ended up completely clearing out the firewall rules and starting from scratch. So my rules are as follows:

# Policy:
#
# Server IP: 10.8.0.1
# Server Subnet: 10.8.0.x
#
# 'Admin' Subnet : 10.8.0.x
# 'Client1' Subnet : 10.8.1.x
#
# POLICY A ::  10.8.x.x --sees--> 10.8.0.1   (All subnets see the server)
# POLICY B ::  10.8.0.x --sees--> 10.8.x.x   ('Admin' subnet sees ALL subnets)
# POLICY C ::  10.8.1.x --sees--> 10.8.1.x   ('Client1' subnet sees 'Client1' subnet)
#

# Enable Linux IP Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# Reset Firewall settings
iptables -F
iptables -X
iptables -Z


### POLICY A :: All subnets see the server
iptables -A INPUT -i tun+ -d 10.8.0.1 -j ACCEPT  # untested


### POLICY B :: 'Admin' subnet sees ALL subnets
iptables -A FORWARD -i tun+ -s 10.8.0.0/24 -d 10.8.0.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i tun+ -s 10.8.0.0/24 -d 10.8.1.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun+ -s 10.8.1.0/24 -d 10.8.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT


### POLICY C :: 'Client1' subnet sees 'Client1' subnet
iptables -A FORWARD -i tun+ -s 10.8.1.0/24 -d 10.8.1.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

As a result, my current iptables listing appears as such (using iptables -L -v):

Chain INPUT (policy ACCEPT 1633K packets, 1361M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 25 packets, 1908 bytes)
 pkts bytes target     prot opt in     out     source               destination
  468 59238 ACCEPT     all  --  tun+   any     10.8.0.0/24          10.8.0.0/24         state NEW,RELATED,ESTABLISHED
 2139  184K ACCEPT     all  --  tun+   any     10.8.0.0/24          10.8.1.0/24         state NEW,RELATED,ESTABLISHED
 2249 1541K ACCEPT     all  --  tun+   any     10.8.1.0/24          10.8.0.0/24         state RELATED,ESTABLISHED
24657 3699K ACCEPT     all  --  tun+   any     10.8.1.0/24          10.8.1.0/24         state NEW,RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 1563K packets, 374M bytes)
 pkts bytes target     prot opt in     out     source               destination

And so, all is well and working perfectly. I can access all the Windows clients on the 10.8.1.x subnet from any machine on the 10.8.0.x subnet. All the clients on the 10.8.1.x subnet can see each other, but they cannot directly connect to any machine on the 10.8.0.x subnet except for the server.

Everything is working great!

I do still have an issue where two of my Windows clients (a remote XP client and a local (as-in physically located in the same room as the OpenVPN server) Vista client) appear to be connected to the VPN to the point I can 'see' them in the openvpn-status.log file on the OpenVPN server- but there is no information being sent between the clients and the server. This only is an issue when the network connection itself is interrupted or severed temporarily (ie: the network connection goes down temporarily where the remote XP client is, or the Vista client goes into 'sleep' mode). A restart fixes the problem and notes on openvpn.net seems to indicate it may be some kind of an ARP/MAC address issue. I'll need to fiddle with this a little more to make sure the link does successfully come back up properly- but at least for now the VPN itself works beautifully when those links are working.

Thanks for all your help!!!

Good news - glad it's sorted. On the losing connection problem by 'restart' do you mean just disconnecting and reconnecting using the OpenVPN-GUI or do you have to reboot the computer? Have you got the keepalive directive active in the OpenVPN server.conf? I have one (luckily only one!) Vista Home Premium client that seems to erratically disconnect from the VPN - difficult to pin down from the user the exact circumstances but it may be related to either powersave kicking in or else one of the new Vista 'features' that tries to optimise networking. Haven't noticed similar issues with XP.

Just realised that as your original problem is now sorted perhaps you need to start a new post with this last problem.