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

[Openvpn-users] help



 

-----Original Message-----
From: openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx
[mailto:openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of
openvpn-users-request@xxxxxxxxxxxxxxxxxxxxx
Sent: Montag, 10. September 2007 10:13
To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Openvpn-users Digest, Vol 16, Issue 13

Send Openvpn-users mailing list submissions to
	openvpn-users@xxxxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/openvpn-users
or, via email, send a message with subject or body 'help' to
	openvpn-users-request@xxxxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
	openvpn-users-owner@xxxxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Openvpn-users digest..."


Today's Topics:

   1. Re: problem with server mode (Canhua)
   2. Re: Possible routing problem (john@xxxxxxxxx)
   3. Re: problem with server mode (Daniel L. Miller)
   4. Re: Possible routing problem (Daniel L. Miller)
   5. Re: problem with server mode (Canhua)
   6. Re: problem with server mode (Canhua)


----------------------------------------------------------------------

Message: 1
Date: Mon, 10 Sep 2007 10:16:18 +0800
From: Canhua <dreameration@xxxxxxxxx>
Subject: Re: [Openvpn-users] problem with server mode
To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Message-ID:
	<b2bbfcb60709091916vae9a55cy6581a84212ef064e@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

On 9/10/07, Daniel L. Miller <dmiller@xxxxxxxxx> wrote:
> Canhua wrote:
> > On 9/10/07, Daniel L. Miller <dmiller@xxxxxxxxx> wrote:
> >
> >> Canhua wrote:
> >>
> >>> hi all, I set up openvpn in server mode. My configuration file for
the
> >>> server is shown as follows:
> >>>
> Didn't see anything obvious in the initialization output.  I didn't
see
> a "server" directive in your server config.  Looks like you're doing
the
> "manual" method of configuration.  Might try replacing the mode,
> ifconfig, ifconfig-pool, and push lines with a "server 10.137.0.100
> 255.255.0.0".
As the doc. indicates my "mode...ifconfig...ifconfig-pool...push..."
lines are equivalent to the server directive. Why I do it manually is
to customerize the ifconfig-pool line to start the pool from .100 not
from .4 as default.
> Is anything listed in your openvpn-status.log ?  Do the client(s) get
> assigned IP's?
Here is the content of the log file:
OpenVPN CLIENT LIST
Updated,Mon Sep 10 10:11:43 2007
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
rxp,*.*.*.*:32818,26443,26792,Mon Sep 10 09:11:13 2007
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.137.0.102,rxp,*.*.*.*:32818,Mon Sep 10 09:14:12 2007
GLOBAL STATS
Max bcast/mcast queue length,0
END

> Daniel



------------------------------

Message: 2
Date: Sun, 9 Sep 2007 23:14:22 -0400 (EDT)
From: john@xxxxxxxxx
Subject: Re: [Openvpn-users] Possible routing problem
To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <43698.74.67.81.126.1189394062.squirrel@xxxxxxxxxxxxx>
Content-Type: text/plain;charset=iso-8859-1

Date: Sun, 09 Sep 2007 18:35:20 -0700
From: "Daniel L. Miller" <dmiller@xxxxxxxxx>
Subject: Re: [Openvpn-users] Possible routing problem
To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <46E49F58.7080504@xxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

john@xxxxxxxxx wrote:
> I recently set up openvpn between two lans and wanted clients on both
sides
> to have full access to either side....
>
Thanks for the reply.

My openvpn server config follows - I think it's fairly straightforward:
server 172.27.0.0 255.255.0.0
tls-server
local 192.168.0.222
port 1195
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key  # This file should be kept
secret
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
keepalive 10 120
persist-key
ifconfig-pool-persist /etc/openvpn/customers-ip.txt
client-config-dir /etc/openvpn/ccd
status customers.log
log-append /var/log/openvpn-customers.log
verb 3
replay-window 72 30
comp-lzo
# route to a remote lan on a client
route 10.4.1.0 255.255.255.0

Then the server's routing table:
172.27.0.2 dev tun0  proto kernel  scope link  src 172.27.0.1
192.168.20.0/24 dev vmnet8  proto kernel  scope link  src 192.168.20.1
10.4.1.0/24 via 172.27.0.2 dev tun0
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.71
192.168.0.0/24 dev br1  proto kernel  scope link  src 192.168.0.72
192.168.30.0/24 dev vmnet1  proto kernel  scope link  src 192.168.30.1
172.27.0.0/16 via 172.27.0.2 dev tun0
default via 192.168.0.1 dev eth0

VPN clients and the VPN server communicate without any problem.  I can
see the routes for the tun interface on the server - everything looks
right to me.

On a server-side LAN client, I add a route to the VPN.  For a Windows
client, I would execute:
route add 172.27.0.0 mask 255.255.0.0 192.168.0.71

And then test the connection.  I can ping the VPN server at 172.27.0.1
without problem.  But I can't ping the VPN clients.  Is an iptables rule
required for this step?

Daniel
-----------------------

Daniel,

I'm a little confused with your setup...

The server directive should be a non-routable, shouldn't it?

i.e., I have

server 10.0.2.0 255.255.255.0
dev tun
topology subnet

I don't worry about local setting, it's optional and will bind to all
the
internal ethernet cards on the network.

by setting the topology to subnet and using the ifconfig-pool-persist
directive, the other ends get a consistent address within the
10.0.2.0/24
network. In ther words, the server end of the tunnel gets 10.0.2.1 and
the
client consistently gets 10.0.2.4 (in my case).

I then push, from the server, the internal routes of the server, i.e.,
push route "192.168.xx1.0 255.255.255.0"
push route "192.168.xx2.0 255.255.255.0"
etc (I'm pushing 4 routes)

and added

client-to-client

and

persist-key
persist-tun

My client end is

route 192.168.x10.0 255.255.255.0

the above statement being part of server config, I just needed to add
the
route manually to the client's internal network.

Note that my client is actually a single server with workstations behind
it
getting their dhcp addresses from the local server, 192.168.x10.1, I am
not
serving dhcp from the server.

The client "server" gets it's server routes pushed to it and this is
transparent to all the workstations on the client end. I add no routes
to
the client's workstations since they only have one route now. The client
is
the only gateway for the client's lan.

So, my server tun0 is 10.0.2.1
my client "server" tun0 is 10.0.2.4

The OpenVPN client end is setup by the OpenVPN server, but at the server
I
had to add the route to the client, i.e, #route add -net
192.168.x10.0/24 gw
10.0.2.4 (the client end of the tunnel)

Setting the topology to subnet simplified this greatly, I'm only dealing
with two addresses, 10.0.2.1 and 10.0.2.4, either end of the tunnel. The
server needs the addition of the route to the client's network, the
client
gets the route from the server ( as I mentioned, I have linux boxes at
either end, so I just popped the route add -net statemet into the
openvpn
startup script, as well as the proxy_arp statements, echo 1 >
/proc/sys/net
etc).

As for the firewalls, the server has a static ip, the client is on a
cable
network, so on the server I have

iptables -I INPUT -i eth0 -p udp -s my.dyndns.addr --sport 1194 --dport
1194
-j ACCEPT
iptables -I OUTPUT -o eth0 -p udp -s my.dyndns.addr --sport 1194 --dport
1194 -j ACCEPT
iptables -I FORWARD -i eth0 -p udp -s my.dyndns.addr --sport 1194
--dport
1194 -j ACCEPT

(This last one probably isn't needed)

iptables -I INPUT -i tun+ -s 192.168.x10.0/24 -d 192.168.xx1.0/24 -j
ACCEPT
iptables -I OUTPUT -o tun+ -s 192.168.xx1.0/24 -d 192.168.10.0/24 -j
ACCEPT
iptables -I FORWARD -i tun+ -s 192.168.x10.0/24 -d 192.168.xx1.0/24 -j
ACCEPT
iptables -I FORWARD -o tun+ -s 192.168.xx1.0/24 -d 192.168.x10.0/24 -j
ACCEPT

iptables -I INPUT -i tun+ -s 10.0.2.4 -d 192.168.xx1.0/24 -j ACCEPT
iptables -I OUTPUT -o tun+ -s 10.0.2.4 -d 192.168.x10.0/24 -j ACCEPT
iptables -I FORWARD -i tun+ -s 10.0.2.4 -d 192.168.xx1.0/24 -j ACCEPT
iptables -I FORWARD -o tun+ -s 10.0.2.4 -d 192.168.x10.0/24 -j ACCEPT

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


Now, for those others who are reading this, I know it's overkill, but I
have
not finished cleaning this up and getting rid of the unnecesary stuff. I
suspect that the -s 10. network stuff really isn't needed, but I don't
think
it can hurt right now. I was strugging with the server side of the
firewall
and the middle eight statements seemed to help.

On the client side all I have is the initial three iptables statements
with
the server's static ip address as well as the last 3 statements.

Hopefully that will get you closer, Daniel, and hopefully it's not too
disjointed an explanation... it's getting late for a Sunday and I'm
hitting
the rack.

The default client and server .conf files and their in-line comments
helped
me a lot, and I really appreciated the fact that they were part of the
distribution. I had been struggling with openswan/ipsec and intermittent
connectivity for weeks. OpenVPN is far easier to set up and it
consistently
works well.

Regards,

John C.






------------------------------

Message: 3
Date: Sun, 09 Sep 2007 22:48:10 -0700
From: "Daniel L. Miller" <dmiller@xxxxxxxxx>
Subject: Re: [Openvpn-users] problem with server mode
To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <46E4DA9A.60905@xxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Canhua wrote:
> On 9/10/07, Daniel L. Miller <dmiller@xxxxxxxxx> wrote:
>   
>> Canhua wrote:
>>     
>>> On 9/10/07, Daniel L. Miller <dmiller@xxxxxxxxx> wrote:
>>>
>>>       
>>>> Canhua wrote:
>>>>
>>>>         
>>>>> hi all, I set up openvpn in server mode. My configuration file for
the
>>>>> server is shown as follows:
>>>>>
>>>>>           
>> Didn't see anything obvious in the initialization output.  I didn't
see
>> a "server" directive in your server config.  Looks like you're doing
the
>> "manual" method of configuration.  Might try replacing the mode,
>> ifconfig, ifconfig-pool, and push lines with a "server 10.137.0.100
>> 255.255.0.0".
>>     
> As the doc. indicates my "mode...ifconfig...ifconfig-pool...push..."
> lines are equivalent to the server directive. Why I do it manually is
> to customerize the ifconfig-pool line to start the pool from .100 not
> from .4 as default.
>   
>> Is anything listed in your openvpn-status.log ?  Do the client(s) get
>> assigned IP's?
>>     
> Here is the content of the log file:
> OpenVPN CLIENT LIST
> Updated,Mon Sep 10 10:11:43 2007
> Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
> rxp,*.*.*.*:32818,26443,26792,Mon Sep 10 09:11:13 2007
> ROUTING TABLE
> Virtual Address,Common Name,Real Address,Last Ref
> 10.137.0.102,rxp,*.*.*.*:32818,Mon Sep 10 09:14:12 2007
> GLOBAL STATS
> Max bcast/mcast queue length,0
> END
>   
Does your client actually receive that IP?  Confirm the ip, subnet, and 
gateway assigned on the client.

Then I think it's time to do a dump of both the server and client 
routing tables.

Daniel



------------------------------

Message: 4
Date: Sun, 09 Sep 2007 23:03:53 -0700
From: "Daniel L. Miller" <dmiller@xxxxxxxxx>
Subject: Re: [Openvpn-users] Possible routing problem
To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <46E4DE49.7030906@xxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

john@xxxxxxxxx wrote:
> The server directive should be a non-routable, shouldn't it?
>   
Yes - what's indicating otherwise?
> i.e., I have
>
> server 10.0.2.0 255.255.255.0
> dev tun
> topology subnet
>   
I had to research that part - you're running either a patched version or

the 2.1 beta?  I'm running stock 2.0.9 - topology subnet not supported.

Perhaps I need to explore the beta . . . .
> I don't worry about local setting, it's optional and will bind to all
the
> internal ethernet cards on the network.
>
> by setting the topology to subnet and using the ifconfig-pool-persist
> directive, the other ends get a consistent address within the
10.0.2.0/24
> network. In ther words, the server end of the tunnel gets 10.0.2.1 and
the
> client consistently gets 10.0.2.4 (in my case).
>
> I then push, from the server, the internal routes of the server, i.e.,
> push route "192.168.xx1.0 255.255.255.0"
> push route "192.168.xx2.0 255.255.255.0"
> etc (I'm pushing 4 routes)
>   
This may be part of the answer.  I DON'T want the VPN clients to see a 
route to the server LAN - I only want select members of my server LAN to

be able to reach the clients.  But I don't see why remote clients need 
to know my internal LAN routing - that's the whole idea of the router, 
to hide that!
> and added
>
> client-to-client
>
> and
>
> persist-key
> persist-tun
>   
I don't want client-to-client behaviour.  I am using persist-key, but I 
was having problems when clients would re-connect after communication 
interruption.  A search of the archives pointed to persist-tun being a 
possible problem - haven't had that issue since I removed it.
> Hopefully that will get you closer, Daniel, and hopefully it's not too
> disjointed an explanation... it's getting late for a Sunday and I'm
hitting
> the rack.
>   
Hope when you read this you've gotten some sleep.
> The default client and server .conf files and their in-line comments
helped
> me a lot, and I really appreciated the fact that they were part of the
> distribution. I had been struggling with openswan/ipsec and
intermittent
> connectivity for weeks. OpenVPN is far easier to set up and it
consistently
> works well.
>   
No doubt.


Wait a minute - as I type this I just had a brainstorm - does this mean 
each VPN client isn't on the 172.27.0.0/16 network?!  So I need to 
adjust my server routing tables for a separate /30 network for each 
client?!  Was that what I was missing?!

Daniel





------------------------------

Message: 5
Date: Mon, 10 Sep 2007 14:41:32 +0800
From: Canhua <dreameration@xxxxxxxxx>
Subject: Re: [Openvpn-users] problem with server mode
To: "Daniel L. Miller" <dmiller@xxxxxxxxx>,
	openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Message-ID:
	<b2bbfcb60709092341o1b060358j47a8d9643b709b38@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

On 9/10/07, Daniel L. Miller <dmiller@xxxxxxxxx> wrote:
> Canhua wrote:
> > Kernel IP routing table
> > Destination     Gateway         Genmask         Flags Metric Ref
Use Iface
> > 10.137.0.17     *               255.255.255.255 UH    0      0
0 ppp5
> > 10.137.0.15     *               255.255.255.255 UH    0      0
0 ppp9
> > 10.137.0.14     *               255.255.255.255 UH    0      0
0 ppp0
> > 10.137.0.13     *               255.255.255.255 UH    0      0
0 ppp15
> > 10.137.0.12     *               255.255.255.255 UH    0      0
0 ppp6
> > 10.137.0.10     *               255.255.255.255 UH    0      0
0 ppp2
> > 10.137.0.9      *               255.255.255.255 UH    0      0
0 ppp3
> > 10.137.0.8      *               255.255.255.255 UH    0      0
0 ppp8
> > 10.137.0.7      *               255.255.255.255 UH    0      0
0 ppp4
> > 10.137.0.6      *               255.255.255.255 UH    0      0
0 ppp11
> > 10.137.0.5      *               255.255.255.255 UH    0      0
0 ppp1
> > 10.137.0.4      *               255.255.255.255 UH    0      0
0 ppp12
> > 10.137.0.3      *               255.255.255.255 UH    0      0
0 ppp7
> > 10.137.0.2      *               255.255.255.255 UH    0      0
0 tun0
> > 10.137.0.2      *               255.255.255.255 UH    0      0
0 ppp10
> > *.*.0.0      *               255.255.0.0     U     0      0        0
eth0
> > link-local      *               255.255.0.0     U     0      0
0 eth1
> > 10.137.0.0      *               255.255.0.0     U     0      0
0 eth1
> > loopback        *               255.0.0.0       U     0      0
0 lo
> > default         *.*.*.*  0.0.0.0         UG    0      0        0
eth0
> > (Note: there is already a pptp vpn server on this server machine.)
> >
> >>
> I'm less than a novice at routing - but it looks like you've got
> overlapping ranges between your overall 10.137.0.0/24 network and your
> ppp networks.  Just for fun, may I suggest you choose a completely
> different IP base, like 10.13.0.0/24 or something, just to guarantee
> there's no overlap with your ppp?
I tried p2p mode and succeded: I used "ifconfig 10.137.0.1
10.137.0.100" on the server side and used "ifconfig 10.137.0.100
10.137.0.1" on the client side, and I could ping other machine on the
subnet of the server side from the client. The problem is when I use
server mode instead I just failed to make the VPN tunnel work. Why?



------------------------------

Message: 6
Date: Mon, 10 Sep 2007 16:13:19 +0800
From: Canhua <dreameration@xxxxxxxxx>
Subject: Re: [Openvpn-users] problem with server mode
To: "David Balazic" <David.Balazic@xxxxxxxxxxxxxxxxxx>,
	openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Message-ID:
	<b2bbfcb60709100113s73ed785bq58069c758e3bba8d@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

On 9/10/07, David Balazic <David.Balazic@xxxxxxxxxxxxxxxxxx> wrote:
> You have the address 10.137.0.2 assigned to two interfaces. That can't
work.
> Also the overlapping network addresses ...
Yes. However, I found that even when there is no pptpd client assigned
by pptpd the address of 10.137.0.2, and 10.137.0.2 is owned by only
openvpn client, the network still failed to work.
> Maybe it's it time to give a big link to some routing basics on the
> homepage.
> 80% of all problems here are routing problems, not vpn problems...
You're right, I am quite confused with routing.
>  From: openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx on
> behalf of Canhua
> Sent: Mon 10-Sep-07 08:41
> To: Daniel L. Miller; openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openvpn-users] problem with server mode
>
>
>
>
> On 9/10/07, Daniel L. Miller <dmiller@xxxxxxxxx> wrote:
> > Canhua wrote:
> > > Kernel IP routing table
> > > Destination     Gateway         Genmask         Flags Metric Ref
Use
> Iface
> > > 10.137.0.17     *               255.255.255.255 UH    0      0
0
> ppp5
> > > 10.137.0.15     *               255.255.255.255 UH    0      0
0
> ppp9
> > > 10.137.0.14     *               255.255.255.255 UH    0      0
0
> ppp0
> > > 10.137.0.13     *               255.255.255.255 UH    0      0
0
> ppp15
> > > 10.137.0.12     *               255.255.255.255 UH    0      0
0
> ppp6
> > > 10.137.0.10     *               255.255.255.255 UH    0      0
0
> ppp2
> > > 10.137.0.9      *               255.255.255.255 UH    0      0
0
> ppp3
> > > 10.137.0.8      *               255.255.255.255 UH    0      0
0
> ppp8
> > > 10.137.0.7      *               255.255.255.255 UH    0      0
0
> ppp4
> > > 10.137.0.6      *               255.255.255.255 UH    0      0
0
> ppp11
> > > 10.137.0.5      *               255.255.255.255 UH    0      0
0
> ppp1
> > > 10.137.0.4      *               255.255.255.255 UH    0      0
0
> ppp12
> > > 10.137.0.3      *               255.255.255.255 UH    0      0
0
> ppp7
> > > 10.137.0.2      *               255.255.255.255 UH    0      0
0
> tun0
> > > 10.137.0.2      *               255.255.255.255 UH    0      0
0
> ppp10
> > > *.*.0.0      *               255.255.0.0     U     0      0
0
> eth0
> > > link-local      *               255.255.0.0     U     0      0
0
> eth1
> > > 10.137.0.0      *               255.255.0.0     U     0      0
0
> eth1
> > > loopback        *               255.0.0.0       U     0      0
0
> lo
> > > default         *.*.*.*  0.0.0.0         UG    0      0        0
eth0
> > > (Note: there is already a pptp vpn server on this server machine.)
> > >
> > >>
> > I'm less than a novice at routing - but it looks like you've got
> > overlapping ranges between your overall 10.137.0.0/24 network and
your
> > ppp networks.  Just for fun, may I suggest you choose a completely
> > different IP base, like 10.13.0.0/24 or something, just to guarantee
> > there's no overlap with your ppp?
> I tried p2p mode and succeded: I used "ifconfig 10.137.0.1
> 10.137.0.100" on the server side and used "ifconfig 10.137.0.100
> 10.137.0.1" on the client side, and I could ping other machine on the
> subnet of the server side from the client. The problem is when I use
> server mode instead I just failed to make the VPN tunnel work. Why?
>



------------------------------

---------------------------------------------------------------------------------------------------

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


End of Openvpn-users Digest, Vol 16, Issue 13
*********************************************

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