1

In the openvpn server's config file I have the line server 192.168.20.0 255.255.255.0.

This will cause tun0 to be created with inet addr:192.168.20.**1** P-t-P:192.168.20.**2** Mask:255.255.255.255

What do I need to do to change that into inet addr:192.168.20.**11** P-t-P:192.168.20.**12** Mask:255.255.255.255

I tried adding ifconfig 192.168.20.11 192.168.20.12 to the config file, but this doesn't work.

Solution

Following Zoredache's advice (RTFM 'man openvpn')

Instead of using server 192.168.20.0 255.255.255.0 I'm now using

mode server
tls-server
ifconfig 192.168.20.11 192.168.20.12 
ifconfig-pool 192.168.20.4 192.168.20.8
route 192.168.20.0 255.255.255.0
push "route 192.168.20.0 255.255.255.0"

and in the client's ccd file

ifconfig-push 192.168.20.1 192.168.20.2

This works.

1

If you refer to the OpenVPN man page you will see that --server is sort of an alias/macro directive that performs a bunch of configuration options. You don't have to use --server you could apply the individual configuration directives instead.

So if you removed your server line I believe your config would probably be something like this.

mode server
tls-server
topology subnet
# ip of server
ifconfig 192.168.20.11 255.255.255.0
# range offered to clients.
ifconfig-pool 192.168.20.1 192.168.20.10 255.255.255.0

Man openvpn

--server
A  helper  directive  designed  to  simplify  the 
configuration of OpenVPN's server mode.  This 
directive will set up an OpenVPN server which 
will allocate addresses to clients out of 
the given network/netmask.  The server itself 
will take the ".1"  address of the given network 
for use as the server-side 
endpoint of the local TUN/TAP interface.

For example, --server 10.8.0.0 255.255.255.0 expands as follows:

     mode server
     tls-server
     push "topology [topology]"

     if dev tun AND (topology == net30 OR topology == p2p):
       ifconfig 10.8.0.1 10.8.0.2
       if !nopool:
         ifconfig-pool 10.8.0.4 10.8.0.251
       route 10.8.0.0 255.255.255.0
       if client-to-client:
         push "route 10.8.0.0 255.255.255.0"
       else if topology == net30:
         push "route 10.8.0.1"

     if dev tap OR (dev tun AND topology == subnet):
       ifconfig 10.8.0.1 255.255.255.0
       if !nopool:
         ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
       push "route-gateway 10.8.0.1"

Don't use --server if you are ethernet bridging.  
Use --server-bridge instead.
| improve this answer | |
  • I knew I had seen something along these lines somewhere, but couldn't find it. Thanks, I'll get back to this after checking xofer's answer, which is currently working and might be the better solution. But I think that this might be the more accurate solution. – Daniel F Nov 5 '14 at 23:40
  • Sure, even with your comment it isn't entirely clear to me what exactly you want, but I can assure you that OpenVPN is extremely flexible, about what you can make it do. – Zoredache Nov 5 '14 at 23:43
  • Yep, this one works. The other solution gave me issues with pinging from the client into subnets attached to the server, so this is a quick and dirty way to do it. I added the solution to the question. Thanks. – Daniel F Nov 6 '14 at 0:14
1

I don't think it's possible. I'm assuming you have something on 192.168.20.1 - 10 that you want on the same subnet. Depending on your situation, you may be able to use a different subnet for OpenVPN and link the two by adding a static route on the 192.168.20 subnet, and using OpenVPN's push and route directives to add a route to the 192.168.20 subnet on the VPN clients.

| improve this answer | |
  • The reason for wanting to do this is that I want to have the client to have the __.1 and __.2 addresses assigned to them, then another client with __.3 and __.4. I'd move the server's ip to as high as the subnet allows, __.11 was just a random pick. The thing is that the client has servers bound to the (non-locally-existing) __.1 address and I'd have to modify every server-software on that client to bind to __.5, which is currently getting assigned to the client. – Daniel F Nov 5 '14 at 22:53
  • I was about to use this, but I got into problems with pinging from the client into some subnets attached to the server, so I went with the other answer. But I will move over to this long-term. Also, sorry for de-accepting your answer, since the other one is more accurate to the question (but not neccessarily better). The upvote is for the subnet recommendation. – Daniel F Nov 6 '14 at 0:12
  • I stand corrected. Glad you got it working. – xofer Nov 6 '14 at 1:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.