wrong p2p networks between a server and a client

[alexy]

Hello everyone.
I have configured an openVPN instances both on a server and a client.
The server config is

Code: Select all

root@Linux:/etc/openvpn# cat /etc/openvpn/server.conf
port 1194
proto udp
dev tun
;dev-node tap0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret
dh /etc/openvpn/dh1024.pem
server 10.10.10.0 255.255.255.0 # vpn subnet
ifconfig-pool-persist ipp.txt
push "route 192.168.7.0 255.255.255.0" # home subnet
;duplicate-cn
keepalive 10 120
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
;status openvpn-status.log
;log-append openvpn.log
verb 4
mute 20
client-to-client
client-config-dir /etc/openvpn/ccd
root@Linux:/etc/openvpn#

The client gets connected. BUT, there is a thing a don't get.
For some reason the client receive a wrong p2p network, that is to be exact 10.10.10.4/30, while it's 10.10.10.0/30 on the server site. Of course all networks that the client gets seemed through 10.10.10.5 which does not exist as a server interface or its p2p peer. Maybe it's a bug?

The most interesting is the server "knows" it gave a wrong p2p subnet.

Code: Select all

root@Linux:/etc/openvpn# cat /etc/openvpn/ipp.txt
 -VirtualBox,10.10.10.4
root@Linux:/etc/openvpn#

The ifconfig issue on the server is next.

Code: Select all

root@Linux:/etc/openvpn# ifconfig
eth0 Link encap:Ethernet HWaddr 00:24:1d:df:bf:5e
                    inet addr:192.168.1.24 Bcast:192.168.1.255 Mask:255.255.255.0
                    inet6 addr: fe80::224:1dff:fedf:bf5e/64 Scope:Link
                    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
                    RX packets:21388 errors:0 dropped:0 overruns:0 frame:0
                    TX packets:22073 errors:0 dropped:0 overruns:0 carrier:0
                    collisions:0 txqueuelen:1000
                    RX bytes:18281661 (18.2 MB) TX bytes:2736217 (2.7 MB)
                    Interrupt:44 Base address:0x6000

lo Link encap:Local Loopback
                    inet addr:127.0.0.1 Mask:255.0.0.0
                    inet6 addr: ::1/128 Scope:Host
                    UP LOOPBACK RUNNING MTU:16436 Metric:1
                    RX packets:21 errors:0 dropped:0 overruns:0 frame:0
                    TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
                    collisions:0 txqueuelen:0
                    RX bytes:1776 (1.7 KB) TX bytes:1776 (1.7 KB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
                    inet addr:10.10.10.1 P-t-P:10.10.10.2 Mask:255.255.255.255
                    UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
                    RX packets:48 errors:0 dropped:0 overruns:0 frame:0
                    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
                    collisions:0 txqueuelen:100
                    RX bytes:2880 (2.8 KB) TX bytes:0 (0.0 B)

root@Linux:/etc/openvpn#

Please, somobody explain to my brain if it's a bug and how can i get around this?

[Bebop]

For some reason the client receive a wrong p2p network, that is to be exact 10.10.10.4/30, while it's 10.10.10.0/30 on the server site. Of course all networks that the client gets seemed through 10.10.10.5 which does not exist as a server interface or its p2p peer. Maybe it's a bug?

From your description I don't see your precise problem yet. Maybe someone else here can. Let me hazard a guess though and say -- have you tried adding to your server.conf:

Code: Select all

topology subnet

If you add that code, then 10.10.10.1 will be your gateway, and 10.10.10.2 will be your client IP. 10.10.10.3 will be your second client IP and so on (10.10.10.4, 10.10.10.5, ...6, ...7, ...).

If thats not what you want, then try explaining again exactly what you want (explain the solution you are looking for, not just explain the problem).

[alexy]

in the server config file i put a string

Code: Select all

server 10.10.10.0 255.255.255.0 # vpn subnet

which means i assign a /24 netwok for VPN connections. But, the first cliet gets an ip 10.10.10.6 instead of 10.10.10.2.
Even if that's right i should see 10.10.10.5 address on the server site i guess.

[Bebop]

in the server config file i put a string

Code: Select all

server 10.10.10.0 255.255.255.0 # vpn subnet

which means i assign a /24 netwok for VPN connections. But, the first cliet gets an ip 10.10.10.6 instead of 10.10.10.2.

Excellent. Thank you for the clarification. In this case, my answer posted above is your solution.

In server.conf:

Code: Select all

topology subnet

After you make this change and restart OpenVPN, your first client will no longer be 10.10.10.6 -- it will be 10.10.10.2 instead.

[alexy]

Thanks Bebop!!! I'll try it in the evening.
But would You satisfy my curiosity...... Why did the client get a wrong subnet.

[janjust]

without

Code: Select all

topology subnet

each client is assigned a miniature /30 network. the server uses the 10.10.10.0-10.10.10.3 network. the first clients gets 10.10.10-4-10.10.10.7 etc
In this /30 block the following addreses are defined:
10.10.10.4 network address
10.10.10.5 virtual endpoint; cannot be reached but must be present
10.10.10.6 actual client VPN IP
10.10.10.7 mini-network broadcast address

etc. The 'topology subnet' assigns only a single IP address to each client.
This is all explained in the Openvpn.net documentation.

[Bebop]

Thanks Bebop!!! I'll try it in the evening.
But would You satisfy my curiosity...... Why did the client get a wrong subnet.

I will try :]

first of all, it is by design and not a bug.

Me personally, I basically never tried too much to understand it, because I had other priorities going on at the time. Then I found the work around ("topology subnet").

However, now that you have asked, I am looking in to it.

In this link: http://openvpn.net/index.php/open-source/faq.html

I found this information:

OpenVPN allocates one /30 subnet per client in order to provide compatibility with Windows clients due to the limitation of the TAP-Win32 driver's TUN emulation mode.

If you know that only non-Windows clients will be connecting to your OpenVPN server, you can avoid this behavior by using the ifconfig-pool-linear directive.

In OpenVPN 1.6, when you had to run one OpenVPN instance per client, then it would be more like you expected: a PtP link between the server and each client.

In 2.0 however, OpenVPN can handle multiple clients with only one tun interface on the server. To handle this, you can think of the PtP link you see on server as a link between the operating system and OpenVPN. Then when you're inside OpenVPN, another PtP link needs to created to each client. If all O/S would have supported true PtP links over the tun interface, this could have been done with the OpenVPN server using only one IP address and each client using another IP address.

But, as the TUN/TAP driver implementation on Windows does not support true PtP links, this is emulated through a /30 subnet.

So, you first have a PtP link 192.168.1.1 <-> 192.168.1.2 between your server O/S and OpenVPN on the server.

Then OpenVPN assigns a /30 subnet for each client that connets. The first available /30 subnet (after the one the server is using) is:
192.168.1.4/30
192.168.1.4 -- Network address
192.168.1.5 -- Virtual IP address in the OpenVPN Server
192.168.1.6 -- Assigned to the client
192.168.1.7 -- Broadcast address.

Then to reach the rest of the network on behind the OpenVPN server, you push a route to the client, so traffic is routed through 192.168.1.5.

So what I think it means basically is that it all comes down to OpenVPN trying to be compatible with Windows.

Best of luck with your VPN design.

[edit]

Beaten by janjust. So what janjust said will be correct, and janjust knows first hand how it all works a lot more than I do.

[alexy]

Then to reach the rest of the network on behind the OpenVPN server, you push a route to the client, so traffic is routed through 192.168.1.5.

You know what is the most intresting?
10.10.10.5 is unreachable as should be according to the theory

[janjust]

This is one of the most counter-intuitive things about the /30 subnets: the 10.10.10.5 address is unreachable BUT if you want to reach a subnet on the server-side LAN you need to add a route using the .5 address. This is caused by the way point-to-point /30 networks are set up and how OpenVPN implements it.

[alexy]

This is one of the most counter-intuitive things about the /30 subnets: the 10.10.10.5 address is unreachable BUT if you want to reach a subnet on the server-side LAN you need to add a route using the .5 address. This is caused by the way point-to-point /30 networks are set up and how OpenVPN implements it.

I have a lot of experience with Cisco equipment... and it's clear if you want to a network to be reachable through a gateway, the gateway must be reachable first.....