LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices



Reply
 
Search this Thread
Old 09-05-2007, 01:22 PM   #1
skubik
Member
 
Registered: May 2003
Location: A dark corner in Canada
Distribution: Slackware 10.1
Posts: 100

Rep: Reputation: 17
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.
 
Old 09-07-2007, 07:27 PM   #2
andrewdodsworth
Member
 
Registered: Oct 2003
Location: United Kingdom
Distribution: SuSE 10.0 - 11.4
Posts: 347

Rep: Reputation: 30
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
Quote:
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
Quote:
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
 
Old 09-08-2007, 04:57 AM   #3
andrewdodsworth
Member
 
Registered: Oct 2003
Location: United Kingdom
Distribution: SuSE 10.0 - 11.4
Posts: 347

Rep: Reputation: 30
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.
 
Old 09-25-2007, 12:46 PM   #4
skubik
Member
 
Registered: May 2003
Location: A dark corner in Canada
Distribution: Slackware 10.1
Posts: 100

Original Poster
Rep: Reputation: 17
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
 
Old 09-25-2007, 06:36 PM   #5
andrewdodsworth
Member
 
Registered: Oct 2003
Location: United Kingdom
Distribution: SuSE 10.0 - 11.4
Posts: 347

Rep: Reputation: 30
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.
 
Old 09-27-2007, 02:19 PM   #6
skubik
Member
 
Registered: May 2003
Location: A dark corner in Canada
Distribution: Slackware 10.1
Posts: 100

Original Poster
Rep: Reputation: 17
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
 
Old 09-27-2007, 03:44 PM   #7
andrewdodsworth
Member
 
Registered: Oct 2003
Location: United Kingdom
Distribution: SuSE 10.0 - 11.4
Posts: 347

Rep: Reputation: 30
From the OpenVPN man pages:

Code:
--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!
 
Old 09-27-2007, 04:32 PM   #8
skubik
Member
 
Registered: May 2003
Location: A dark corner in Canada
Distribution: Slackware 10.1
Posts: 100

Original Poster
Rep: Reputation: 17
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.
 
Old 09-27-2007, 06:45 PM   #9
andrewdodsworth
Member
 
Registered: Oct 2003
Location: United Kingdom
Distribution: SuSE 10.0 - 11.4
Posts: 347

Rep: Reputation: 30
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:

Code:
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.
 
Old 09-28-2007, 11:46 AM   #10
skubik
Member
 
Registered: May 2003
Location: A dark corner in Canada
Distribution: Slackware 10.1
Posts: 100

Original Poster
Rep: Reputation: 17
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:

Code:
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:

Code:
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
 
Old 09-28-2007, 12:26 PM   #11
andrewdodsworth
Member
 
Registered: Oct 2003
Location: United Kingdom
Distribution: SuSE 10.0 - 11.4
Posts: 347

Rep: Reputation: 30
Quote:
Originally Posted by skubik View Post
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
Yes I have this set



Quote:
Originally Posted by skubik View Post
Code:
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:

Code:
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:

Code:
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
 
Old 09-29-2007, 10:31 PM   #12
skubik
Member
 
Registered: May 2003
Location: A dark corner in Canada
Distribution: Slackware 10.1
Posts: 100

Original Poster
Rep: Reputation: 17
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:

Code:
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:

Code:
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
 
Old 09-30-2007, 09:42 AM   #13
andrewdodsworth
Member
 
Registered: Oct 2003
Location: United Kingdom
Distribution: SuSE 10.0 - 11.4
Posts: 347

Rep: Reputation: 30
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:
Code:
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?

Last edited by andrewdodsworth; 09-30-2007 at 10:15 AM. Reason: additional info
 
Old 10-03-2007, 12:09 PM   #14
skubik
Member
 
Registered: May 2003
Location: A dark corner in Canada
Distribution: Slackware 10.1
Posts: 100

Original Poster
Rep: Reputation: 17
Works!

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:

Code:
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:

Code:
# 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):

Code:
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!!!
 
Old 10-03-2007, 03:43 PM   #15
andrewdodsworth
Member
 
Registered: Oct 2003
Location: United Kingdom
Distribution: SuSE 10.0 - 11.4
Posts: 347

Rep: Reputation: 30
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.

Last edited by andrewdodsworth; 10-03-2007 at 03:45 PM. Reason: maybe new post needed?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenVPN client has not default gateway when connect to OpenVPN server sailershen Linux - Security 3 03-04-2010 03:20 AM
openvpn assigns clients always to the same ip t0bias Linux - Networking 1 05-10-2007 08:08 PM
OpenVPN Question : connecting 5-6 comps with OpenVPN duryodhan Linux - Networking 7 02-15-2007 11:28 PM
Privileged user AbrahamJose Solaris / OpenSolaris 8 04-21-2006 07:13 PM
Privileged port AlexJ Suse/Novell 1 03-31-2006 08:40 AM


All times are GMT -5. The time now is 08:13 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration