OpenVPN

Hi Josh

josh wrote:
> Hi.
:.

>         We thought about using a VIP on the front end served up via CARP, then
>         running ripng on the back end for announcing the routes into the Cisco
>         environment, but I am open to suggestions.
> 
>         Another option is to just split the clients, pointing half and one T1000
>         and the other half at another, but then the problem is if you lose one
>         of them, you have to either assign a secondary IP to the "live" and make
>         manual route changes.
> 
>         I know that you can use the "remote-random" feature to alternate between
>         several vpn servers, but that does not address the issue of determining
>         from the internal networks which T1000 one would use to get back to the
>         VPN client. (this is a site-to-site VPN scenario)

Why can't you just NAT the VPN traffic on the two endpoints?

Erich

Erich,

On 2/29/08, Erich Titl <erich.titl@...> wrote:
> Hi Josh

Hello!

>  josh wrote:
>  > Hi.
>
> :.
>
>  >         We thought about using a VIP on the front end served up via CARP, then
>  >         running ripng on the back end for announcing the routes into the Cisco
>  >         environment, but I am open to suggestions.
>  >
>  >         Another option is to just split the clients, pointing half and one T1000
>  >         and the other half at another, but then the problem is if you lose one
>  >         of them, you have to either assign a secondary IP to the "live" and make
>  >         manual route changes.
>  >
>  >         I know that you can use the "remote-random" feature to alternate between
>  >         several vpn servers, but that does not address the issue of determining
>  >         from the internal networks which T1000 one would use to get back to the
>  >         VPN client. (this is a site-to-site VPN scenario)
>
>
> Why can't you just NAT the VPN traffic on the two endpoints?

I don't quite follow.

Currently the servers have the following configuration:

bge0: 216.x.x.x (internet facing)
bge1: 172.35.1.x (private facing)

Then behind the bge1 interface there's a whole internal network setup
with multiple routes, etc.

So I would need to somehow tell the router behind bge1 which client
networks are connected to which T1000's.

Josh

Josh

josh wrote:
> Erich,
> 
...
>>
>>
>> Why can't you just NAT the VPN traffic on the two endpoints?
> 
> I don't quite follow.
> 
> Currently the servers have the following configuration:
> 
> bge0: 216.x.x.x (internet facing)
> bge1: 172.35.1.x (private facing)
> 
> Then behind the bge1 interface there's a whole internal network setup
> with multiple routes, etc.

Sure

> 
> So I would need to somehow tell the router behind bge1 which client
> networks are connected to which T1000's.

Why, if you NAT the incoming connection then each packet gets as source 
address the internal address of the T1000 that translated it, so the 
route back is known. Just NAT the connections coming through the tunnel.

Erich

Erich,

On 2/29/08, Erich Titl <erich.titl@...> wrote:
[snip]

> Why, if you NAT the incoming connection then each packet gets as source
>  address the internal address of the T1000 that translated it, so the
>  route back is known. Just NAT the connections coming through the tunnel.

Wow OK that's a great idea...so simple :) That's a great suggestion,
let me see if that will work based on the network infrastructure that
we have there (this is for a client, so I don't have full access to
anything except the OpenVPN servers)

Josh

Hrm one issue.... How will packets originating from the backed network
get to the remote sites.  I think that's a requirement as well.

I.E. a machine back on the corporate network needs to initiate a
connection to one of the remote sites.  I'm looking to see if that's a
requirement.

Josh

josh wrote:
> Erich,
> 
> On 2/29/08, Erich Titl <erich.titl@...> wrote:
> [snip]
> 
>> Why, if you NAT the incoming connection then each packet gets as source
>>  address the internal address of the T1000 that translated it, so the
>>  route back is known. Just NAT the connections coming through the tunnel.
> 
> Wow OK that's a great idea...so simple :) That's a great suggestion,
> let me see if that will work based on the network infrastructure that
> we have there (this is for a client, so I don't have full access to
> anything except the OpenVPN servers)

As long as the client opens the connection it _should_ work. Mind you, 
that is the way a typical user's address is found for _any_ service on 
the internet (I doubt there are many users on DSL or Cable without a NAT 
device). Your NAT software may need helpers for protocols like ftp, e.t.c.)

Erich

josh wrote:
> Hrm one issue.... How will packets originating from the backed network
> get to the remote sites.  I think that's a requirement as well.
> 
> I.E. a machine back on the corporate network needs to initiate a
> connection to one of the remote sites.  I'm looking to see if that's a
> requirement.

Yes, this is a scenario which will not work. If this is a requirement 
then such a simple solution will fail. I like simple solutions, so I 
tend to avoid such requirements. In all complex cases a dynamic routing 
protocol might be a requirement.

Do you need to support networks _behind_ the clients also?

Erich

Erich,

On 2/29/08, Erich Titl <erich.titl@...> wrote:
>
>
>  josh wrote:
>  > Hrm one issue.... How will packets originating from the backed network
>  > get to the remote sites.  I think that's a requirement as well.
>  >
>  > I.E. a machine back on the corporate network needs to initiate a
>  > connection to one of the remote sites.  I'm looking to see if that's a
>  > requirement.
>
>
> Yes, this is a scenario which will not work. If this is a requirement
>  then such a simple solution will fail. I like simple solutions, so I
>  tend to avoid such requirements. In all complex cases a dynamic routing
>  protocol might be a requirement.
>
>  Do you need to support networks _behind_ the clients also?

Unfortunately this is sthe case, the main office will be initiating
the traffic to the end points, and they will need to access the
networks behing the OpenVPN endpoint at the client site.

Back to RIP I go!

Thanks for your help,
Josh

>
>
>  Erich
>

Client A <------> Server <-------> Client B

Client A wants to use client B as gateway so that all of A's network
traffic except for the VPN connection will be routed through B. So A's
packets targeted to any IP on the internet except for the OpenVPN
server will first go to the server and then to B and then to the
internet from B. It's not much different than doing redirect-gateway
def1 on A, except that server is not the gateway but client B is.

No, B is not supposed to connect to the OPenVPN server through client A.

I hope it's more clear now.


On 28/02/2008, Jan Just Keijser <janjust@...> wrote:
> Hi Luke,
>
>  what are you trying to achieve here, exactly?
>
>  server <---> client A <--> client B ?
>
>  can you draw an ASCII art diagram of your desired network setup, coz I
>  am completely confused by your last post ;-)
>  Is client B supposed to connecto the openvpn server through client A? if
>  so , why that would mean you've got double encryption.
>
>  HTH,
>
>  JJK
>
>  Luke Bonasera wrote:
>  >
>  >
>  > 2008/2/27 Jan Just Keijser <janjust@... <mailto:janjust@...>>:
>
> >
>  >     Luke Bonasera wrote:
>  >     > On 26/02/2008, *Josh Cepek* <josh.cepek@...
>  >     <mailto:josh.cepek@...>
>
> >     > <mailto:josh.cepek@... <mailto:josh.cepek@...>>> wrote:
>  >     >
>  >     >
>  >     >     You really don't want to do this (I'll explain why in a moment),
>  >     >     but it
>  >     >     is technically possible.  To do this, you'd need to use tap
>  >     adapters
>  >     >     (subnet topology may also work) since gateways need to be
>  >     reachable on
>  >     >     the link level.  You would then need to set the clients to
>  >     use the
>  >     >     following OpenVPN directives or push them from the server:
>  >     "route
>
> >     >     remote_host 255.255.255.255 <http://255.255.255.255/>
>  >     <http://255.255.255.255 <http://255.255.255.255/>> net_gateway"
>  >     >     "route 0.0.0.0 <http://0.0.0.0/> <http://0.0.0.0
>  >     <http://0.0.0.0/>> 128.0.0.0 <http://128.0.0.0/> <http://128.0.0.0
>
> >     <http://128.0.0.0/>>
>
> >     >     <gateway_ip>" "route 128.0.0.0 <http://128.0.0.0/>
>  >     <http://128.0.0.0 <http://128.0.0.0/>> 128.0.0.0 <http://128.0.0.0/>
>  >     >     <http://128.0.0.0 <http://128.0.0.0/>> <gateway_ip>".  Those
>
> >     routes
>  >     >     will duplicate what "redirect-gateway def1" would have done
>  >     if it was
>  >     >     redirecting to your chosen IP.  You'll also need to either
>  >     explicitly
>  >     >     set the gateway on any additional routes you're exposing or
>  >     use the
>  >     >     route-gateway option.  Finally, you can't send those options
>  >     to the
>  >     >     machine acting as the gateway for all other clients since
>  >     that would
>  >     >     create a routing loop.
>  >     >
>  >     >
>  >
>  > [...]
>  >
>  >
>  >     as for using a windows openvpn client as a gateway: sure it's
>  >     possible ,
>  >     even without routing&remote access on the client (which I'd
>  >     recommend)  .
>  >
>  >
>  >
>  >
>  > (sorry Jan, I sent a reply just to you. Here is an updated reply to
>  > the group.)
>  >
>  >
>  > Thanks for the info, but setting the client as gateway did not work.
>  > Here is what I did:
>  >
>  > I have a OpenVPN server and two clients A and B. I wanted to make B a
>  > gateway for A, so that A can route its traffic through B. This is what
>  > I added to A's config file:
>  >
>
> > route remote_host 255.255.255.255 <http://255.255.255.255> net_gateway
>  > route 0.0.0.0 <http://0.0.0.0> 128.0.0.0 <http://128.0.0.0> <VPN ip of B>
>  > route 128.0.0.0 <http://128.0.0.0> 128.0.0.0 <http://128.0.0.0> <VPN
>
> > ip of B>
>  >
>  > When A was trying to connect, here is what happened:
>  >
>  > Wed Feb 27 23:24:13 2008 Route: Waiting for TUN/TAP interface to come
>  > up...
>  > Wed Feb 27 23:24:15 2008 TEST ROUTES: 0/0 succeeded len=4 ret=0 a=0
>  > u/d=down( x 5 as usual)
>  >
>  > Wed Feb 27 23:24:16 2008 TEST ROUTES: 2/4 succeeded len=4 ret=0 a=0 u/d=up
>  > Wed Feb 27 23:24:16 2008 Route: Waiting for TUN/TAP interface to come
>  > up...
>  > ( x 19 unusually...)
>  >
>  > Wed Feb 27 23:24:40 2008 route ADD <VPN server ip> MASK
>
> > 255.255.255.255 <http://255.255.255.255> <Default gateway of A>
>
> > Wed Feb 27 23:24:40 2008 Route addition via IPAPI succeeded
>
> > Wed Feb 27 23:24:40 2008 route ADD 0.0.0.0 <http://0.0.0.0> MASK
>  > 128.0.0.0 <http://128.0.0.0> <VPN ip of B>
>
> > Wed Feb 27 23:24:40 2008 Warning: route gateway is not reachable on
>  > any active network adapters: <VPN ip of B>
>  > Wed Feb 27 23:24:40 2008 Route addition via IPAPI failed
>
> > Wed Feb 27 23:24:40 2008 route ADD 128.0.0.0 <http://128.0.0.0> MASK
>  > 128.0.0.0 <http://128.0.0.0> <VPN ip of B>
>
> > Wed Feb 27 23:24:40 2008 Warning: route gateway is not reachable on
>  > any active network adapters: <VPN ip of B>
>  >
>  > Where <VPN ip of B> is the IP that B normally gets for OpenVPN(thanks
>  > to Jan and ifconfig-pool-persist), <VPN server ip> is the IP of my VPN
>  > server and <Default gateway of A> is the default gateway of A.
>  > and in the end:
>  >
>  > Wed Feb 27 23:46:43 2008 Initialization Sequence Completed With Errors
>  > ( see http://openvpn.net/faq.html#dhcpclientserv )
>  >
>  > Besides, when there is no gateway route rule in the VPN, if I try to
>  > add the route using "route add" in the windows command line, it won't
>  > accept VPN IP addresses. The only such "route add" command that
>  > windows accepts is when it is ran on a VPN client and the gateway is
>  > given as the VPN server.
>  > So, it seems like Josh's first suggestion does not work. If you really
>  > think this is possible I'd appreciate alternative solutions. I would
>  > prefer a solution in which multiple clients can act as gateways and
>  > other clients can choose which gateway to use.
>  >
>  > Now I was able to route server's traffic through client by doing the
>  > following:
>  > In the server config:
>  >
>  > client-config-dir ccd
>  > route <external ip of server's network that clients connect to>
>
> > 255.255.255.255 <http://255.255.255.255> net_gateway
>  > route 0.0.0.0 <http://0.0.0.0> 128.0.0.0 <http://128.0.0.0>
>
> > route 128.0.0.0 <http://128.0.0.0> 128.0.0.0 <http://128.0.0.0>
>  >
>
> > and in the ccd dir in the specific client file:
>  >
>
> > iroute 0.0.0.0 <http://0.0.0.0> 128.0.0.0 <http://128.0.0.0>
>  > iroute 128.0.0.0 <http://128.0.0.0> 128.0.0.0 <http://128.0.0.0>
>
> >
>  > Without the <external ip of server's network that clients connect to>
>  > part, client couldn't connect to the server since server couldn't
>  > route back to the client I guess. I found this out sort of by luck
>  > while loking at the wireshark logs.
>  >
>  > This way, client and server managed to connect to each other and
>  > server's traffic ran through the client. Now I didn't try to make
>  > another client connect, but I'm assuming if I make other clients to
>  > route to the server, it should then route to the gateway client. The
>  > only big caveat right now is that I had to add the server's network's
>  > external ip to the server configuration file. This is the router's
>  > external IP that the clients connect to and it does port forwarding to
>  > the OpenVPN server. If there is a way to get rid of this, I would love
>  > to know. Also, any comments on this solution are welcome. It doesn't
>  > look like multiple gateways will be able to coexist at the same time
>  > in this setup, the server will have to choose which one is the active
>  > one. If there is a way to make server agnostic to this in which
>  > clients can use any other desired client as a gateway, it would be
>  > even better. One solution that would probably work would be having a
>  > parent VPN and having child VPNs that live inside of it that use the
>  > route/iroute method, but would be a very bad design:) My point is,
>  > since it is possible, I hope OpenVPN can also do it.
>  >
>  > Thanks in advance for the answers.
>  >
>  >
>  >     JJK
>  >
>  >
>
>

Hi Luke,

aaah I see... interesting setup...

Two options:
if you only have 2 clients then stop using the client/server model and 
set up two point-to-point connections. It's much easer to route all 
desired traffic over these 2 point-to-point links then when using the 
client/server model.

if you must use the client/server model then
- add 'client-to-client'
- make sure you can ping the VPN interface of client B from client A
- add a route to the VPN server which does NOT use any kind of tunneling
- add a route to client B which uses the VPN server
- add a "default" route to point to client B directly.
The " iroute " command probably won't help you here, as it would route 
all traffic from client B to the server first... the server will not 
grok this ...

HTH,

JJK

Luke Bonasera wrote:
> Client A <------> Server <-------> Client B
>
> Client A wants to use client B as gateway so that all of A's network
> traffic except for the VPN connection will be routed through B. So A's
> packets targeted to any IP on the internet except for the OpenVPN
> server will first go to the server and then to B and then to the
> internet from B. It's not much different than doing redirect-gateway
> def1 on A, except that server is not the gateway but client B is.
>
> No, B is not supposed to connect to the OPenVPN server through client A.
>
> I hope it's more clear now.
>
>
> On 28/02/2008, Jan Just Keijser <janjust@...> wrote:
>   
>> Hi Luke,
>>
>>  what are you trying to achieve here, exactly?
>>
>>  server <---> client A <--> client B ?
>>
>>  can you draw an ASCII art diagram of your desired network setup, coz I
>>  am completely confused by your last post ;-)
>>  Is client B supposed to connecto the openvpn server through client A? if
>>  so , why that would mean you've got double encryption.
>>
>>  HTH,
>>
>>  JJK
>>
>>  Luke Bonasera wrote:
>>  >
>>  >
>>  > 2008/2/27 Jan Just Keijser <janjust@... <mailto:janjust@...>>:
>>
>>     
>>  >     Luke Bonasera wrote:
>>  >     > On 26/02/2008, *Josh Cepek* <josh.cepek@...
>>  >     <mailto:josh.cepek@...>
>>
>>     
>>>     > <mailto:josh.cepek@... <mailto:josh.cepek@...>>> wrote:
>>>       
>>  >     >
>>  >     >
>>  >     >     You really don't want to do this (I'll explain why in a moment),
>>  >     >     but it
>>  >     >     is technically possible.  To do this, you'd need to use tap
>>  >     adapters
>>  >     >     (subnet topology may also work) since gateways need to be
>>  >     reachable on
>>  >     >     the link level.  You would then need to set the clients to
>>  >     use the
>>  >     >     following OpenVPN directives or push them from the server:
>>  >     "route
>>
>>     
>>>     >     remote_host 255.255.255.255 <http://255.255.255.255/>
>>>       
>>  >     <http://255.255.255.255 <http://255.255.255.255/>> net_gateway"
>>  >     >     "route 0.0.0.0 <http://0.0.0.0/> <http://0.0.0.0
>>  >     <http://0.0.0.0/>> 128.0.0.0 <http://128.0.0.0/> <http://128.0.0.0
>>
>>     
>>>     <http://128.0.0.0/>>
>>>       
>>>     >     <gateway_ip>" "route 128.0.0.0 <http://128.0.0.0/>
>>>       
>>  >     <http://128.0.0.0 <http://128.0.0.0/>> 128.0.0.0 <http://128.0.0.0/>
>>  >     >     <http://128.0.0.0 <http://128.0.0.0/>> <gateway_ip>".  Those
>>
>>     
>>>     routes
>>>       
>>  >     >     will duplicate what "redirect-gateway def1" would have done
>>  >     if it was
>>  >     >     redirecting to your chosen IP.  You'll also need to either
>>  >     explicitly
>>  >     >     set the gateway on any additional routes you're exposing or
>>  >     use the
>>  >     >     route-gateway option.  Finally, you can't send those options
>>  >     to the
>>  >     >     machine acting as the gateway for all other clients since
>>  >     that would
>>  >     >     create a routing loop.
>>  >     >
>>  >     >
>>  >
>>  > [...]
>>  >
>>  >
>>  >     as for using a windows openvpn client as a gateway: sure it's
>>  >     possible ,
>>  >     even without routing&remote access on the client (which I'd
>>  >     recommend)  .
>>  >
>>  >
>>  >
>>  >
>>  > (sorry Jan, I sent a reply just to you. Here is an updated reply to
>>  > the group.)
>>  >
>>  >
>>  > Thanks for the info, but setting the client as gateway did not work.
>>  > Here is what I did:
>>  >
>>  > I have a OpenVPN server and two clients A and B. I wanted to make B a
>>  > gateway for A, so that A can route its traffic through B. This is what
>>  > I added to A's config file:
>>  >
>>
>>     
>>> route remote_host 255.255.255.255 <http://255.255.255.255> net_gateway
>>>       
>>  > route 0.0.0.0 <http://0.0.0.0> 128.0.0.0 <http://128.0.0.0> <VPN ip of B>
>>  > route 128.0.0.0 <http://128.0.0.0> 128.0.0.0 <http://128.0.0.0> <VPN
>>
>>     
>>> ip of B>
>>>       
>>  >
>>  > When A was trying to connect, here is what happened:
>>  >
>>  > Wed Feb 27 23:24:13 2008 Route: Waiting for TUN/TAP interface to come
>>  > up...
>>  > Wed Feb 27 23:24:15 2008 TEST ROUTES: 0/0 succeeded len=4 ret=0 a=0
>>  > u/d=down( x 5 as usual)
>>  >
>>  > Wed Feb 27 23:24:16 2008 TEST ROUTES: 2/4 succeeded len=4 ret=0 a=0 u/d=up
>>  > Wed Feb 27 23:24:16 2008 Route: Waiting for TUN/TAP interface to come
>>  > up...
>>  > ( x 19 unusually...)
>>  >
>>  > Wed Feb 27 23:24:40 2008 route ADD <VPN server ip> MASK
>>
>>     
>>> 255.255.255.255 <http://255.255.255.255> <Default gateway of A>
>>>       
>>> Wed Feb 27 23:24:40 2008 Route addition via IPAPI succeeded
>>>       
>>> Wed Feb 27 23:24:40 2008 route ADD 0.0.0.0 <http://0.0.0.0> MASK
>>>       
>>  > 128.0.0.0 <http://128.0.0.0> <VPN ip of B>
>>
>>     
>>> Wed Feb 27 23:24:40 2008 Warning: route gateway is not reachable on
>>>       
>>  > any active network adapters: <VPN ip of B>
>>  > Wed Feb 27 23:24:40 2008 Route addition via IPAPI failed
>>
>>     
>>> Wed Feb 27 23:24:40 2008 route ADD 128.0.0.0 <http://128.0.0.0> MASK
>>>       
>>  > 128.0.0.0 <http://128.0.0.0> <VPN ip of B>
>>
>>     
>>> Wed Feb 27 23:24:40 2008 Warning: route gateway is not reachable on
>>>       
>>  > any active network adapters: <VPN ip of B>
>>  >
>>  > Where <VPN ip of B> is the IP that B normally gets for OpenVPN(thanks
>>  > to Jan and ifconfig-pool-persist), <VPN server ip> is the IP of my VPN
>>  > server and <Default gateway of A> is the default gateway of A.
>>  > and in the end:
>>  >
>>  > Wed Feb 27 23:46:43 2008 Initialization Sequence Completed With Errors
>>  > ( see http://openvpn.net/faq.html#dhcpclientserv )
>>  >
>>  > Besides, when there is no gateway route rule in the VPN, if I try to
>>  > add the route using "route add" in the windows command line, it won't
>>  > accept VPN IP addresses. The only such "route add" command that
>>  > windows accepts is when it is ran on a VPN client and the gateway is
>>  > given as the VPN server.
>>  > So, it seems like Josh's first suggestion does not work. If you really
>>  > think this is possible I'd appreciate alternative solutions. I would
>>  > prefer a solution in which multiple clients can act as gateways and
>>  > other clients can choose which gateway to use.
>>  >
>>  > Now I was able to route server's traffic through client by doing the
>>  > following:
>>  > In the server config:
>>  >
>>  > client-config-dir ccd
>>  > route <external ip of server's network that clients connect to>
>>
>>     
>>> 255.255.255.255 <http://255.255.255.255> net_gateway
>>>       
>>  > route 0.0.0.0 <http://0.0.0.0> 128.0.0.0 <http://128.0.0.0>
>>
>>     
>>> route 128.0.0.0 <http://128.0.0.0> 128.0.0.0 <http://128.0.0.0>
>>>       
>>  >
>>
>>     
>>> and in the ccd dir in the specific client file:
>>>       
>>  >
>>
>>     
>>> iroute 0.0.0.0 <http://0.0.0.0> 128.0.0.0 <http://128.0.0.0>
>>>       
>>  > iroute 128.0.0.0 <http://128.0.0.0> 128.0.0.0 <http://128.0.0.0>
>>
>>     
>>  > Without the <external ip of server's network that clients connect to>
>>  > part, client couldn't connect to the server since server couldn't
>>  > route back to the client I guess. I found this out sort of by luck
>>  > while loking at the wireshark logs.
>>  >
>>  > This way, client and server managed to connect to each other and
>>  > server's traffic ran through the client. Now I didn't try to make
>>  > another client connect, but I'm assuming if I make other clients to
>>  > route to the server, it should then route to the gateway client. The
>>  > only big caveat right now is that I had to add the server's network's
>>  > external ip to the server configuration file. This is the router's
>>  > external IP that the clients connect to and it does port forwarding to
>>  > the OpenVPN server. If there is a way to get rid of this, I would love
>>  > to know. Also, any comments on this solution are welcome. It doesn't
>>  > look like multiple gateways will be able to coexist at the same time
>>  > in this setup, the server will have to choose which one is the active
>>  > one. If there is a way to make server agnostic to this in which
>>  > clients can use any other desired client as a gateway, it would be
>>  > even better. One solution that would probably work would be having a
>>  > parent VPN and having child VPNs that live inside of it that use the
>>  > route/iroute method, but would be a very bad design:) My point is,
>>  > since it is possible, I hope OpenVPN can also do it.
>>  >
>>  > Thanks in advance for the answers.
>>  >
>>  >
>>  >     JJK
>>  >
>>  >
>>
>>
>>

Hi Jan,

2008/2/28 Jan Just Keijser <janjust@...>:

> Hi Luke,
>
> aaah I see... interesting setup...
>
> Two options:
> if you only have 2 clients then stop using the client/server model and
> set up two point-to-point connections. It's much easer to route all
> desired traffic over these 2 point-to-point links then when using the
> client/server model.


Oh I see. Would these point to point links be tun connecitons? I remember
playing with them, and I remember having to give the other party's IP to
both of them. This would require me to do port forwarding on client's router
which I don't want. Do you think I got what you meant? Is there a way to do
point-to-point connections w/o opening a port on client side?

I didn't understand what you meant in the following bullets:


>
>
> if you must use the client/server model then
> - add 'client-to-client'
> - make sure you can ping the VPN interface of client B from client A
> - add a route to the VPN server which does NOT use any kind of tunneling


do you mean add a route to A that routes to server?


>
> - add a route to client B which uses the VPN server

what woud this accomplish? what does "uses VPN server mean"


>
> - add a "default" route to point to client B directly.

In client A? route commands in client A do not accept B's IP as the gateway
as I said


>
> The " iroute " command probably won't help you here, as it would route
> all traffic from client B to the server first... the server will not
> grok this ...


with iroute I was able to make B advertise that it can route, and with route
on server towards B I was able to route server's traffic through B.

I should submit the final solution to the OpenVPN docs if we can figure this
out:)


>
>
> HTH,
>
> JJK
>
> Luke Bonasera wrote:
> > Client A <------> Server <-------> Client B
> >
> > Client A wants to use client B as gateway so that all of A's network
> > traffic except for the VPN connection will be routed through B. So A's
> > packets targeted to any IP on the internet except for the OpenVPN
> > server will first go to the server and then to B and then to the
> > internet from B. It's not much different than doing redirect-gateway
> > def1 on A, except that server is not the gateway but client B is.
> >
> > No, B is not supposed to connect to the OPenVPN server through client A.
> >
> > I hope it's more clear now.
> >
> >
> > On 28/02/2008, Jan Just Keijser <janjust@...> wrote:
> >
> >> Hi Luke,
> >>
> >>  what are you trying to achieve here, exactly?
> >>
> >>  server <---> client A <--> client B ?
> >>
> >>  can you draw an ASCII art diagram of your desired network setup, coz I
> >>  am completely confused by your last post ;-)
> >>  Is client B supposed to connecto the openvpn server through client A?
> if
> >>  so , why that would mean you've got double encryption.
> >>
> >>  HTH,
> >>
> >>  JJK
> >>
> >>  Luke Bonasera wrote:
> >>  >
> >>  >
> >>  > 2008/2/27 Jan Just Keijser <janjust@... <mailto:
> janjust@...>>:
> >>
> >>
> >>  >     Luke Bonasera wrote:
> >>  >     > On 26/02/2008, *Josh Cepek* <josh.cepek@...
> >>  >     <mailto:josh.cepek@...>
> >>
> >>
> >>>     > <mailto:josh.cepek@... <mailto:josh.cepek@...>>> wrote:
> >>>
> >>  >     >
> >>  >     >
> >>  >     >     You really don't want to do this (I'll explain why in a
> moment),
> >>  >     >     but it
> >>  >     >     is technically possible.  To do this, you'd need to use
> tap
> >>  >     adapters
> >>  >     >     (subnet topology may also work) since gateways need to be
> >>  >     reachable on
> >>  >     >     the link level.  You would then need to set the clients to
> >>  >     use the
> >>  >     >     following OpenVPN directives or push them from the server:
> >>  >     "route
> >>
> >>
> >>>     >     remote_host 255.255.255.255 <http://255.255.255.255/>
> >>>
> >>  >     <http://255.255.255.255 <http://255.255.255.255/>> net_gateway"
> >>  >     >     "route 0.0.0.0 <http://0.0.0.0/> <http://0.0.0.0
> >>  >     <http://0.0.0.0/>> 128.0.0.0 <http://128.0.0.0/> <
> http://128.0.0.0
> >>
> >>
> >>>     <http://128.0.0.0/>>
> >>>
> >>>     >     <gateway_ip>" "route 128.0.0.0 <http://128.0.0.0/>
> >>>
> >>  >     <http://128.0.0.0 <http://128.0.0.0/>> 128.0.0.0 <
> http://128.0.0.0/>
> >>  >     >     <http://128.0.0.0 <http://128.0.0.0/>> <gateway_ip>".
>  Those
> >>
> >>
> >>>     routes
> >>>
> >>  >     >     will duplicate what "redirect-gateway def1" would have
> done
> >>  >     if it was
> >>  >     >     redirecting to your chosen IP.  You'll also need to either
> >>  >     explicitly
> >>  >     >     set the gateway on any additional routes you're exposing
> or
> >>  >     use the
> >>  >     >     route-gateway option.  Finally, you can't send those
> options
> >>  >     to the
> >>  >     >     machine acting as the gateway for all other clients since
> >>  >     that would
> >>  >     >     create a routing loop.
> >>  >     >
> >>  >     >
> >>  >
> >>  > [...]
> >>  >
> >>  >
> >>  >     as for using a windows openvpn client as a gateway: sure it's
> >>  >     possible ,
> >>  >     even without routing&remote access on the client (which I'd
> >>  >     recommend)  .
> >>  >
> >>  >
> >>  >
> >>  >
> >>  > (sorry Jan, I sent a reply just to you. Here is an updated reply to
> >>  > the group.)
> >>  >
> >>  >
> >>  > Thanks for the info, but setting the client as gateway did not work.
> >>  > Here is what I did:
> >>  >
> >>  > I have a OpenVPN server and two clients A and B. I wanted to make B
> a
> >>  > gateway for A, so that A can route its traffic through B. This is
> what
> >>  > I added to A's config file:
> >>  >
> >>
> >>
> >>> route remote_host 255.255.255.255 <http://255.255.255.255> net_gateway
> >>>
> >>  > route 0.0.0.0 <http://0.0.0.0> 128.0.0.0 <http://128.0.0.0> <VPN ip
> of B>
> >>  > route 128.0.0.0 <http://128.0.0.0> 128.0.0.0 <http://128.0.0.0> <VPN
> >>
> >>
> >>> ip of B>
> >>>
> >>  >
> >>  > When A was trying to connect, here is what happened:
> >>  >
> >>  > Wed Feb 27 23:24:13 2008 Route: Waiting for TUN/TAP interface to
> come
> >>  > up...
> >>  > Wed Feb 27 23:24:15 2008 TEST ROUTES: 0/0 succeeded len=4 ret=0 a=0
> >>  > u/d=down( x 5 as usual)
> >>  >
> >>  > Wed Feb 27 23:24:16 2008 TEST ROUTES: 2/4 succeeded len=4 ret=0 a=0
> u/d=up
> >>  > Wed Feb 27 23:24:16 2008 Route: Waiting for TUN/TAP interface to
> come
> >>  > up...
> >>  > ( x 19 unusually...)
> >>  >
> >>  > Wed Feb 27 23:24:40 2008 route ADD <VPN server ip> MASK
> >>
> >>
> >>> 255.255.255.255 <http://255.255.255.255> <Default gateway of A>
> >>>
> >>> Wed Feb 27 23:24:40 2008 Route addition via IPAPI succeeded
> >>>
> >>> Wed Feb 27 23:24:40 2008 route ADD 0.0.0.0 <http://0.0.0.0> MASK
> >>>
> >>  > 128.0.0.0 <http://128.0.0.0> <VPN ip of B>
> >>
> >>
> >>> Wed Feb 27 23:24:40 2008 Warning: route gateway is not reachable on
> >>>
> >>  > any active network adapters: <VPN ip of B>
> >>  > Wed Feb 27 23:24:40 2008 Route addition via IPAPI failed
> >>
> >>
> >>> Wed Feb 27 23:24:40 2008 route ADD 128.0.0.0 <http://128.0.0.0> MASK
> >>>
> >>  > 128.0.0.0 <http://128.0.0.0> <VPN ip of B>
> >>
> >>
> >>> Wed Feb 27 23:24:40 2008 Warning: route gateway is not reachable on
> >>>
> >>  > any active network adapters: <VPN ip of B>
> >>  >
> >>  > Where <VPN ip of B> is the IP that B normally gets for
> OpenVPN(thanks
> >>  > to Jan and ifconfig-pool-persist), <VPN server ip> is the IP of my
> VPN
> >>  > server and <Default gateway of A> is the default gateway of A.
> >>  > and in the end:
> >>  >
> >>  > Wed Feb 27 23:46:43 2008 Initialization Sequence Completed With
> Errors
> >>  > ( see http://openvpn.net/faq.html#dhcpclientserv )
> >>  >
> >>  > Besides, when there is no gateway route rule in the VPN, if I try to
> >>  > add the route using "route add" in the windows command line, it
> won't
> >>  > accept VPN IP addresses. The only such "route add" command that
> >>  > windows accepts is when it is ran on a VPN client and the gateway is
> >>  > given as the VPN server.
> >>  > So, it seems like Josh's first suggestion does not work. If you
> really
> >>  > think this is possible I'd appreciate alternative solutions. I would
> >>  > prefer a solution in which multiple clients can act as gateways and
> >>  > other clients can choose which gateway to use.
> >>  >
> >>  > Now I was able to route server's traffic through client by doing the
> >>  > following:
> >>  > In the server config:
> >>  >
> >>  > client-config-dir ccd
> >>  > route <external ip of server's network that clients connect to>
> >>
> >>
> >>> 255.255.255.255 <http://255.255.255.255> net_gateway
> >>>
> >>  > route 0.0.0.0 <http://0.0.0.0> 128.0.0.0 <http://128.0.0.0>
> >>
> >>
> >>> route 128.0.0.0 <http://128.0.0.0> 128.0.0.0 <http://128.0.0.0>
> >>>
> >>  >
> >>
> >>
> >>> and in the ccd dir in the specific client file:
> >>>
> >>  >
> >>
> >>
> >>> iroute 0.0.0.0 <http://0.0.0.0> 128.0.0.0 <http://128.0.0.0>
> >>>
> >>  > iroute 128.0.0.0 <http://128.0.0.0> 128.0.0.0 <http://128.0.0.0>
> >>
> >>
> >>  > Without the <external ip of server's network that clients connect
> to>
> >>  > part, client couldn't connect to the server since server couldn't
> >>  > route back to the client I guess. I found this out sort of by luck
> >>  > while loking at the wireshark logs.
> >>  >
> >>  > This way, client and server managed to connect to each other and
> >>  > server's traffic ran through the client. Now I didn't try to make
> >>  > another client connect, but I'm assuming if I make other clients to
> >>  > route to the server, it should then route to the gateway client. The
> >>  > only big caveat right now is that I had to add the server's
> network's
> >>  > external ip to the server configuration file. This is the router's
> >>  > external IP that the clients connect to and it does port forwarding
> to
> >>  > the OpenVPN server. If there is a way to get rid of this, I would
> love
> >>  > to know. Also, any comments on this solution are welcome. It doesn't
> >>  > look like multiple gateways will be able to coexist at the same time
> >>  > in this setup, the server will have to choose which one is the
> active
> >>  > one. If there is a way to make server agnostic to this in which
> >>  > clients can use any other desired client as a gateway, it would be
> >>  > even better. One solution that would probably work would be having a
> >>  > parent VPN and having child VPNs that live inside of it that use the
> >>  > route/iroute method, but would be a very bad design:) My point is,
> >>  > since it is possible, I hope OpenVPN can also do it.
> >>  >
> >>  > Thanks in advance for the answers.
> >>  >
> >>  >
> >>  >     JJK
> >>  >
> >>  >
> >>
> >>
> >>
>
>

Luke Bonasera wrote:
> Hi Jan,
>
> 2008/2/28 Jan Just Keijser <janjust@... <mailto:janjust@...>>:
>
>     Hi Luke,
>
>     aaah I see... interesting setup...
>
>     Two options:
>     if you only have 2 clients then stop using the client/server model and
>     set up two point-to-point connections. It's much easer to route all
>     desired traffic over these 2 point-to-point links then when using the
>     client/server model.
>
>  
> Oh I see. Would these point to point links be tun connecitons? I 
> remember playing with them, and I remember having to give the other 
> party's IP to both of them. This would require me to do port 
> forwarding on client's router which I don't want. Do you think I got 
> what you meant? Is there a way to do point-to-point connections w/o 
> opening a port on client side?
both clients can create point to point connections to two separate 
instances on the server. You can then create all required routes.

> I didn't understand what you meant in the following bullets:
>  
>
>
>
>     if you must use the client/server model then
>     - add 'client-to-client'
>     - make sure you can ping the VPN interface of client B from client A
>     - add a route to the VPN server which does NOT use any kind of
>     tunneling
>
>  
> do you mean add a route to A that routes to server?
normally openvpn should do this but it is sometimes helpful to add this 
route explicitly
>  
>
>     - add a route to client B which uses the VPN server
>
> what woud this accomplish? what does "uses VPN server mean"
make sure that the route to client goes out the tun0/tap-win32 
interface; this can be achieved by selecting the right 'gw' address
>  
>
>     - add a "default" route to point to client B directly.
>
> In client A? route commands in client A do not accept B's IP as the 
> gateway as I said
after the direct route to client B they should.

HTH,

JJK

make backups of
  server.crt
  server.key
  ca.crt

copy cert-12345.pem to
  ssl/server.crt
copy the corresponding key (cert-12345.key) which you generated when 
creating the certificate signing request to
  ssl/server.key
copy the official CA certificate to
  ssl/ca.crt
and restart openvpn. That should be enough.

HTH,

JJK

Marcus wrote:
> Hi Folks,
>
> after issuing a PKCS#10-Request and the result to an official CA, i got 
> a cert-12345.pem File and the Certifikate of the CA. So i've got two files.
>
> Right now i am running my server with 4 files for Key-Stuff:
> # Key-Stuff
> ca ssl/ca.crt
> cert ssl/server.crt
> key ssl/server.key
> dh ssl/dh1024.pem
>
> These are all self generated and work pretty fine. Since we want to have 
> official keys, I am now supposed to integrate the two files into the 
> configuration of the server. The client is using the following 
> configuration:
>
> client
> dev tun
> proto udp
>
> remote openvpn1.uni-abc.de 1194
> remote openvpn2.uni-abc.de 1194
> remote random
> resolv-retry 20
>
> route-method exe
> route-delay 2
> resolv-retry infinite
> nobind
> persist-key
> persist-tun
>
> auth-user-pass
> ca keys/ca.crt
>
> comp-lzo
> verb 3
> tls-auth keys/ta.key 1
>
>
> I am doing radius-Authentication via pam which works fine.
>
> Serverconf  looks like this:
>
> local "ip-off-openvpn1.uni-abc.de"
> port 1194
> proto udp
> dev tun
>
> # Nutze das ganze Subnet am Stueck
> topology subnet
>
> # PAM for authentication
> plugin /lib/security/openvpn-auth-pam.so openvpn
>
> # Key-Stuff
> ca ssl/ca.crt
> cert ssl/server.crt
> key ssl/server.key
> dh ssl/dh1024.pem
>
> mode server
> server 135.5.228.0 255.255.255.0
>
> client-cert-not-required
> username-as-common-name
>
> tls-server
>
> up /etc/openvpn/server-up.sh
> down /etc/openvpn/server-down.sh
> client-connect /etc/openvpn/client-connect.sh
> client-disconnect /etc/openvpn/client-disconnect.sh
>
> push "redirect-gateway def1"
> push "dhcp-option DOMAIN uni-tuebingen.de"
> push "dhcp-option DNS 134.2.200.1"
> push "dhcp-option DNS 134.2.200.2"
>
> client-to-client
> duplicate-cn
> keepalive 10 120
> comp-lzo
> persist-key
> persist-tun
> status /var/log/openvpn/openvpn-status.log 1
> log-append /var/log/openvpn/openvpn.log
> verb 3
> user openvpn
> group openvpn
> tls-auth ssl/ta.key 0
>
> max-clients 100
>
> Any suggestions on how to get this bird flying with officialy signed key 
> an ca-certificate?
> Thanks for bothering,
>
>

Hi Markus,

it should be sufficient to let openvpn en ssh listen on eth2 only. You 
might want to switch to 'tcp' mode for openvpn , as with UDP traffic 
there is a chance that return traffic is sent over the default (i.e. non 
eth2) route. With TCP traffic this should not be possible.
normally all packets with a particular source address will leave the 
network interface with that source address. So replies to all traffic 
coming in on eth2 will also be sent out of eth2 UNLESS there is NAT'ting 
involved.
Also, make sure your ISP (or ISPs) did not set up assymetric routing 
(i.e. they are NAT'ting your traffic again).

Just try it and run a tcpdump session on eth1 while your ssh'ing in to 
your site - you should see the results soon enough.

HTH,

JJK

Markus Meyer wrote:
> Hi,
>
> first, sorry for asking this probably basic question which may not even
> have to do something with OpenVPN but more with general routing and
> firewalling, but despite much Googling I did not yet found a working
> answer to this.
>
> I have a server with two WAN interfaces (eth1 and eth2) and one
> interface to the local LAN (eth0). I want all "normal" internet traffic
> to go through eth1 (the ISP gateway is also the default gateway for
> eth0) but I want OpenVPN and SSH to listen on and use eth2 for VPN
> connections exclusively (which could be coming from anywhere in the
> Internet).
>
> Is it sufficient to just let OpenVPN and SSH listen on eth2 for incoming
> connections? Or do I need to set additional routing information? How can
> I set eth2 to use the second ISPs gateway for packets sent from eth2?
> Can I have two default gateways and how can I set which kind of traffic
> goes through which interface?
>
>
>

Hello Oscar and Openvpn friends,


On Thu, Feb 28, 2008 at 06:00:23PM -0500, Oscar Knight wrote:
> Hello,
> 
> Is there a way to set the MAC address of a tap interface at creation 
> time?   I would like to do this on Windows and Mac OS X machines.
> I want to do this as part of the install.
> 
> Thanks,
> odk
> -- 
> Oscar D. Knight                           knightod at appstate dot edu
> ITS                                                Voice: 828-262-6946
> Appalachian State University, Boone, NC 28608        FAX: 828-262-2236
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users

This is certainly possible. In Windows check the properties of the tap
device in your network connections in the system configuration. I guess
in the advanced mode you can set the MAC address of the tap device. For
Mac OS X I don't know how to proceed. Under Linux I use a script, that
runs after launching openvpn client and performs the following:

ifconfig tap0 hw ether <MAC-address>

Howto to do this as part of the install is not (yet) clear to me, since
I do not know what you mean with install.

I hope this helps.

-- 
Met vriendelijke groeten,
With kind regards,
Mit freundlichen Gruessen,
De jrus wah,

Willy

*************************************
W.K. Offermans
Home:   +31 45 544 49 44
Mobile: +31 653 27 16 23
e-mail: Willy@...

                                       Powered by ....

                                            (__)
                                         \\\'',)
                                           \/  \ ^
                                           .\._/_)

                                       http://www.FreeBSD.org

On Thu, Feb 28, 2008 at 10:04 PM, Jamal Ayach <jamal.ayach@...> wrote:
> removing auth-nocache did the trick of not prompting for
>  username/password. However , looks like that keys are out of sync now:
>
>  us=620783 username/user_ip:2359 TLS Error: local/remote TLS keys are out
>  of sync: user_ip:2359 [1]
>
You have
>  >>  tran-window 7200
on the client. Please remove that. The default is good enough, unless
you're an OpenVPN God.

Prasanna.

>
>
>
>  Prasanna Krishnamoorthy wrote:
>  > On Wed, Feb 27, 2008 at 10:03 PM, Jamal Ayach <jamal.ayach@...> wrote:
>  >
>  >> nothing came up on the server's log. client displayed this:
>  >>
>  >>  ------------------
>  >>  Wed Feb 27 11:27:59 2008 TLS: soft reset sec=0 bytes=2573119/0 pkts=18464/0
>  >>  Enter Auth Username:Wed Feb 27 11:27:59 2008 ERROR: Auth username is empty
>  >>  Wed Feb 27 11:27:59 2008 Exiting
>  >>  -----------------
>  >>
>  >>  using this config on client:
>  >>
>  >>
>  >>
>  >>  client
>  >>  dev tap0
>  >>  proto udp
>  >>  remote my_server_ovpn_ip 1194
>  >>  tls-client
>  >>  tran-window 7200
>  >>
>  > you have this as one hour - totally unnecessary param - the default is
>  > usually good enough.
>  >
>  >
>  >> persist-key
>  >>  persist-tun
>  >>  mute-replay-warnings
>  >>  auth-user-pass
>  >>  auth-nocache
>  >>
>  > you're not caching the auth creds.
>  >
>  > OpenVPN tries to auth again, and since creds are absent (Auth username
>  > is empty), you're losing the connection.
>  >
>  > Remove BOTH tran-window and auth-nocache, and you should be fine. I
>  > don't know if OpenVPN GUI knows how to work with auth-nocache.
>  >
>  > HTH
>  > Prasanna.
>  >
>  >
>  >>  ca /etc/openvpn/ca.crt
>  >>
>  >> ns-cert-type server
>  >>  cipher AES-128-CBC
>  >>  comp-lzo
>  >>  verb 3
>  >>
>  >>
>  >>
>  >> Jan Just Keijser wrote:
>  >>  > hi Jamal,
>  >>  >
>  >>  > are the clocks on both ends synchronized?
>  >>  > try increasing the verbosity to '5' before posting another log file.
>  >>  >
>  >>  > HTH,
>  >>  >
>  >>  > JJK
>  >>  >
>  >>  > Jamal Ayach wrote:
>  >>  >> ping, ping-restart, keepalive were tried and it didn't work. I ran
>  >>  >> tcpdump on eth0 and tap0 (client side) and I get a "network down"
>  >>  >> message when timeout occurs. looks like something is tearing down the
>  >>  >> tunnel at exactly 1 hour (3600). I also checked the reneg-sec option
>  >>  >> without success.
>  >>  >>
>  >>  >> *connection initiation:
>  >>  >>
>  >>  >> *14:30:06 2008 us=152674 username/user_ip:32818 MULTI: Learn:
>  >>  >> 62:40:95:3a:05:68 -> ayachj/user_ip:32818
>  >>  >>
>  >>  >> *timeout:*
>  >>  >>
>  >>  >> 15:31:04 2008 us=481470 username/user_ip:32818 TLS Error: TLS key
>  >>  >> negotiation failed to occur within 60 seconds (check your network
>  >>  >> connectivity)
>  >>  >> 15:31:04 2008 us=481538 username/user_ip:32818 TLS Error: TLS
>  >>  >> handshake failed
>  >>  >> 15:31:04 2008 us=481557 username/user_ip:32818 TLS: move_session:
>  >>  >> dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1
>  >>  >> 15:32:19 2008 us=11538 username/user_ip:32818 TLS Error: TLS key
>  >>  >> negotiation failed to occur within 60 seconds (check your network
>  >>  >> connectivity)
>  >>  >> 15:32:19 2008 us=11649 username/user_ip:32818 TLS Error: TLS
>  >>  >> handshake failed
>  >>  >> 15:33:34 2008 us=59881 username/user_ip:32818 TLS Error: TLS key
>  >>  >> negotiation failed to occur within 60 seconds (check your network
>  >>  >> connectivity)
>  >>  >> 15:33:34 2008 us=59940 username/user_ip:32818 TLS Error: TLS
>  >>  >> handshake failed
>  >>  >> 15:34:34 2008 us=156576 username/user_ip:32818 TLS Error: TLS key
>  >>  >> negotiation failed to occur within 60 seconds (check your network
>  >>  >> connectivity)
>  >>  >> 15:34:34 2008 us=156629 username/user_ip:32818 TLS Error: TLS
>  >>  >> handshake failed
>  >>  >> 15:35:34 2008 us=515790 username/user_ip:32818 TLS Error: TLS key
>  >>  >> negotiation failed to occur within 60 seconds (check your network
>  >>  >> connectivity)
>  >>  >> 15:35:34 2008 us=515845 username/user_ip:32818 TLS Error: TLS
>  >>  >> handshake failed
>  >>  >> 15:36:49 2008 us=58158 username/user_ip:32818 TLS Error: TLS key
>  >>  >> negotiation failed to occur within 60 seconds (check your network
>  >>  >> connectivity)
>  >>  >> 15:36:49 2008 us=58227 username/user_ip:32818 TLS Error: TLS
>  >>  >> handshake failed
>  >>  >> 15:38:04 2008 us=126083 username/user_ip:32818 TLS Error: TLS key
>  >>  >> negotiation failed to occur within 60 seconds (check your network
>  >>  >> connectivity)
>  >>  >> 15:38:04 2008 us=126153 username/user_ip:32818 TLS Error: TLS
>  >>  >> handshake failed
>  >>  >> 15:39:19 2008 us=171271 username/user_ip:32818 TLS Error: TLS key
>  >>  >> negotiation failed to occur within 60 seconds (check your network
>  >>  >> connectivity)
>  >>  >> 15:39:19 2008 us=171342 username/user_ip:32818 TLS Error: TLS
>  >>  >> handshake failed
>  >>  >> 15:43:48 2008 us=902938 event_wait : Interrupted system call (code=4)
>  >>  >> 15:43:48 2008 us=903771 TCP/UDP: Closing socket
>  >>  >> 15:43:48 2008 us=903829 Closing TUN/TAP interface
>  >>  >> 15:43:48 2008 us=903873 PLUGIN_CLOSE:
>  >>  >> /usr/lib/openvpn/openvpn-auth-pam.so
>  >>  >> 15:43:48 2008 us=904016 SIGTERM[hard,] received, process exiting
>  >>  >>
>  >>  >>
>  >>  >>
>  >>  >> David Balazic wrote:
>  >>  >>
>  >>  >>> Tried the "ping" options ?
>  >>  >>> Can you post the relevant log file(s) ?
>  >>  >>>
>  >>  >>> David
>  >>  >>>
>  >>  >>>> -----Original Message-----
>  >>  >>>> From: openvpn-users-bounces@...
>  >>  >>>> [mailto:openvpn-users-bounces@...] On Behalf Of
>  >>  >>>> Jamal Ayach
>  >>  >>>> Sent: Tuesday, February 26, 2008 5:23 PM
>  >>  >>>> To: openvpn-users@...
>  >>  >>>> Subject: [Openvpn-users] 1 hour timeout
>  >>  >>>>
>  >>  >>>> Hi, all my clients are timing out at exactly hour after
>  >>  >>>> successfully  connecting to my ovpn box. Is there a default timeout
>  >>  >>>> value that needs to be disabled ?
>  >>  >>>>
>  >>  >>>> below are both my server's and client's configs;
>  >>  >>>>
>  >>  >>>> regards
>  >>  >>>>
>  >>  >>>>
>  >>  >>>> _Client's config:_
>  >>  >>>>
>  >>  >>>> client
>  >>  >>>> dev tap0
>  >>  >>>> proto udp
>  >>  >>>> remote "my_ip" 1194
>  >>  >>>> auth-user-pass
>  >>  >>>> persist-key
>  >>  >>>> persist-tun
>  >>  >>>> mute-replay-warnings
>  >>  >>>> auth-nocache
>  >>  >>>> ca ca.crt
>  >>  >>>> ns-cert-type server
>  >>  >>>> cipher AES-128-CBC
>  >>  >>>> comp-lzo
>  >>  >>>> verb 3
>  >>  >>>>
>  >>  >>>> ==================================
>  >>  >>>>
>  >>  >>>> _Server's config:_
>  >>  >>>>
>  >>  >>>> local "my_ip"
>  >>  >>>> port 1194
>  >>  >>>> proto udp
>  >>  >>>> dev tap0
>  >>  >>>> ca /etc/openvpn/easy-rsa/keys/ca.crt
>  >>  >>>> cert /etc/openvpn/easy-rsa/keys/server.crt
>  >>  >>>> key /etc/openvpn/easy-rsa/keys/server.key
>  >>  >>>> dh /etc/openvpn/easy-rsa/keys/dh1024.pem
>  >>  >>>> server-bridge my_ip 255.255.255.0 pool-start pool-end
>  >>  >>>> push "dhcp-option DOMAIN my.domin.org"
>  >>  >>>> push "dhcp-option DNS dns_ip1"
>  >>  >>>> push "dhcp-option DNS dns_ip2"
>  >>  >>>> push "redirect-gateway def1"
>  >>  >>>> cipher AES-128-CBC
>  >>  >>>> comp-lzo
>  >>  >>>> username-as-common-name
>  >>  >>>> client-cert-not-required
>  >>  >>>> duplicate-cn
>  >>  >>>> user nobody
>  >>  >>>> group nogroup
>  >>  >>>> persist-key
>  >>  >>>> persist-tun
>  >>  >>>> max-clients 10
>  >>  >>>> verb 3
>  >>  >>>> status /var/log/openvpn/ovpn-status.log 60
>  >>  >>>> log /var/log/openvpn/ovpn.log
>  >>  >>>>
>  >>  >>>> ### Used for securid OTP
>  >>  >>>> plugin /usr/lib/openvpn/openvpn-auth-pam.so openvpn
>  >>  >>>>
>  >>  >>>> --------------------------------------------------------------
>  >>  >>>> -----------
>  >>  >>>> This SF.net email is sponsored by: Microsoft
>  >>  >>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>  >>  >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  >>  >>>> _______________________________________________
>  >>  >>>> Openvpn-users mailing list
>  >>  >>>> Openvpn-users@...
>  >>  >>>> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>  >>  >>>>
>  >>  >>>>
>  >>  >>
>  >>  >>
>  >>  >
>  >>
>  >>  --
>  >>
>  >> -- Jamal Ayach +++ jamal.ayach@...
>  >>  -- Environnement Canada / Environment Canada
>  >>  -- tel. 514.421.5010
>  >>
>  >>
>  >>  -------------------------------------------------------------------------
>  >>
>  >>
>  >> This SF.net email is sponsored by: Microsoft
>  >>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  >>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  >>  _______________________________________________
>  >>  Openvpn-users mailing list
>  >>  Openvpn-users@...
>  >>  https://lists.sourceforge.net/lists/listinfo/openvpn-users
>  >>
>  >>
>  >
>  >
>  >
>  >
>



-- 
 http://www.elinanetworks.com
Seamless, secure delivery of applications.