Good morning, I am installing a VPN server in such a way that I have two virtual machines, one of them has the OpenVPN service and the other one has an Apache service running, both machines are in the same network segment 10.8.0.1 (VPN) and 10.8.0.3 (Apache) the Apache virtual machine does not have Internet access while VPN does, we have a static address and a forwarded port on the Router.
This is our server.conf file configuration:
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/vpn.crt
key /etc/openvpn/easy-rsa/keys/vpn.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig 10.8.0.1 10.8.0.2
push "route 10.8.0.1 255.255.255.255"
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.1.220 255.255.255.0"
push "redirect-gateway def1"
client-to-client
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb1
When establishing a VPN connection from the client, whether Windows or OSx connects perfectly, it even browses the Internet from this new public IP, but nevertheless it is unable to ping with the machine that has Apache and thanks the VPN is already inside your own network. It is as if OpenVPN made small subnets every time someone connects, since the network mask that it assigns to the client is always 255.255.255.252
Description
The main problems you suffer from are two:
client-to-clientpreventing the packets that are destined for the VPN IP range from leaving the openvpn server.Proposed solution (1)
I would suggest changing the network topology from net30 to subnet to facilitate management, but if you don't want to make many changes, I would only suggest the following:
In this way the VPN will assign IPs outside the LAN range and, therefore, you will not have problems communicating with its machines (regardless of the configuration of
client-to-client).Now you need to add the static route to the Apache machine so it knows how to reach the VPN clients as follows:
Once these changes are made you should have bidirectional connectivity between your VPN client and the Apache server.
The best tool for debugging traffic routing problems on IP networks is
traceroute.To check the hops and the correct arrival of the packets, use from your VPN client:
And from your Apache server you can check the reverse path with:
The main disadvantage of this system is that, since you don't want to access the Internet on the Apache server and you don't want to configure a default route, you have to add a static route so that it knows how to reach the VPN clients.
Proposed solution (2)
To avoid having to add static routes on the Apache server, you can use NAT so that VPN clients contact it using the LAN IP of the VPN server.
To the previous solution (without adding a static route in the Apache server) it would be necessary to add the following rule
iptablesto the VPN server:The main disadvantage of this system is that in the eyes of the Apache server, the connections are established by the VPN server, so we will not be able to differentiate which particular VPN client a connection is from.
Final configuration file