I am new to OpenVPN(and networking in general) and I have tried to look around the last few days for answers to a problem I am currently facing. I have a central application on a machine that uses OpenVPN server to have several other machines connect to it as OpenVPN clients. Each client machine has an web API that the central application uses. It checks up on them with a ping and then uses the web API.
This works fine when the relationship is one-to-one, as in only one tunnel from each machine to the central application's machine but I want to test the central application's ability to deal with data from a large number of client machines. To do this I want to have one client machine connect several times to the same OpenVPN server. The central application wouldn't know it's connected to the same machine several times and the data would still be valid. The client machine has OpenVPN IP addresses of say 10.8.0.20, 10.8.0.24, etc. that all be connected to the central application. The central application can then use...
ping 10.8.0.20
ping 10.8.0.24
...
curl 10.8.0.20/api/stuff
curl 10.8.0.24/api/stuff
and get back valid responses.
When I have tried this I run into the problem of one OpenVPN IP address being usable but the other does not respond. So if I do a ping 10.8.0.24 on the server it will respond normally but if I do a ping 10.8.0.20 it will not respond. I Googled around and looked around these forums several times but if I did find something that address this situation I didn't recognize it.
Here are some more things that might be relevant or I found while trying to figure this out.
- 1. These are all Linux based machines
2. I would prefer to use TUN over TAP. From what I understand TAP acts more like a real network which might solve this problem but I would prefer not to have to change this.
3. When I am pinging the from the server to the 'disabled' IP address the client machine receives the packet (The RX packets are incremented (see client ifconfig below for tun0)).
Like I have said before I don't have a lot of experience with OpenVPN and it seems like the problem is that when going though the openvpn tunnel that is 'disabled' it gets to the client and can't get back to the server. I would be grateful for any ideas, tip or criticism. Thanks.
Here are the config settings for the server
server 10.8.0.0 255.255.255.0
port 1194
proto udp
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
keepalive 5 30
dev tun
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
log-append server.log
verb 0
Here are the config settings for a client
remote 10.0.0.1
port 1194
proto udp
client
resolv-retry infinite
nobind
user nobody
group nobody
ca /etc/openvpn/client0/ca.crt
cert /etc/openvpn/client0/client.crt
key /etc/openvpn/client0/client.key
dh /etc/openvpn/dh1024.pem
dev tun0
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
keepalive 5 30
persist-key
persist-tun
log-append client0.log
verb 0
Here is the results from ifconfig on the central application machine(VPN Server)
eth0 Link encap:Ethernet HWaddr 08:00:27:16:CF:6E
inet addr:10.0.1.142 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe16:cf6e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21975351 errors:0 dropped:0 overruns:0 frame:0
TX packets:8267599 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2560973083 (2.3 GiB) TX bytes:1810654801 (1.6 GiB)
eth1 Link encap:Ethernet HWaddr 08:00:27:84:43:C6
inet addr:10.0.1.157 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe84:43c6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14950113 errors:0 dropped:0 overruns:0 frame:0
TX packets:22625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:929180727 (886.1 MiB) TX bytes:6193232 (5.9 MiB)
...
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:3286 errors:0 dropped:0 overruns:0 frame:0
TX packets:6029 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:819867 (800.6 KiB) TX bytes:645796 (630.6 KiB)
Here is the results from ifconfig on the machine with two clients
eth0 Link encap:Ethernet HWaddr 08:00:27:ff:6c:ad
inet addr:10.0.1.152 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:feff:6cad/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10529744 errors:0 dropped:0 overruns:0 frame:0
TX packets:243355 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:754543188 (754.5 MB) TX bytes:27509789 (27.5 MB)
...
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.20 P-t-P:10.8.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:25 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:2004 (2.0 KB) TX bytes:0 (0.0 B)
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.24 P-t-P:10.8.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1532 (1.5 KB) TX bytes:1861 (1.8 KB)