You're messing entinies due to lack of understanding of OSI model. You should restrict login access to these servers basing on the user's group, not the connectivity to their subnets. The connectivity from VPN should be restricted globally, for all of the VPN subnetworks.
It is possible to setup openVPN server on the VPS end. the specific procedure would depend on what operating system the VPS is running. You might also consider Wireguard as an alternative to OpenVPN.
If your only objective is to ship log files from the home office environment, you might also consider using ssh. Although, if you decide to employ ssh in ...
You have no problem with the VPN, your problem is with the TCP connection that is probably restricted by the Fortigate firewall (fortigate device) you mentioned.
The way to solve this is to talk to the administrator of the firewall and ask for permission to contact the VPN server.
Gee.. boy my stupid. There was nothing to it when you do it the other way around. I simply added another cipher instead of turning encryption off. It looks like it's impossible to turn it off at all in these old versions. I couldn't find it how anyway..
So what did the trick for me was adding those two in my openvpn.vpn config file server side like this:
Your OpenVPN is quite old. And ncp-disable does not disable encryption. Official OpenVPN manual says:
Disable "negotiable crypto parameters".
This completely disables cipher negotiation.
OpenVPN introduced a cipher negotiation in version 2.4, and this directive is meant as a debug aid to disable negotiation and to work like ...
Do the VPN logs confirm that the tunnel is actually up and running?
You say you can traceroute successfully to the public IP addresses. Can you do a manual connection using telnet?
eg: if your host ip is 123.456.789.123:
telnet 123.456.789.123 80
You should get a response like :
Connected to www.example.com.
Escape character is '^]'...
The problem was with routing table configuration.
I noticed that when removing routes added by OpenVPN:
Destination Gateway Genmask Flags MSS Window irtt Iface
default 10.8.0.1 220.127.116.11 UG 0 0 0 tun0
and trying to perform ping 18.104.22.168 -I tun0 and simultaneously monitoring packets with tcpdump -nn ...
The problem with the gateway redirect that in the routing table the more specific entries override the less specific ones. So pushing the gateway usually not a big help, since every computer contains a /24 link-scope route entry for the local network, which is of course more specific than the advertised default route, so it will be used instead.
If you ...
Your VPN server is a IP router (which does packet forwarding), where packets might be filtered (be forwarded or not forwarded). This is done with a firewall. For example, if server is Linux, you add:
iptables -I FORWARD 1 -s 10.8.0.0/24 -d 10.200.3.0/24 -j REJECT
The -I ... 1 will install the rule before anything else in the chain, I crafted it like this to ...
I have a similar setup in which the raspberry pi is the client, but that should not matter too much. Disclaimer: It is not the easiest thing to set up.
I am using this /etc/iptables/iptables.rules file to NAT traffic from OpenVPN connections (usually tun0, but tun+ covers all) into the local networks:
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
this seems to work but you need to combine other options. From Manual:
–-iroute network [netmask]
Generate an internal route to a specific client. The netmask parameter, if omitted, defaults to 255.255.255.255.This directive can be used to route a fixed subnet from the server to a particular client, regardless of where the client is connecting from. Remember ...
It is easy to set in client config to route a particular ip(even VPN ip) via VPN with netmask as 255.255.255.255. However, the difficulty remains at OpenVPN server if it will route a client-to-client request without client-to-client option.
There is an option "iroute" that allows the server to forward a packet to a client rather than respond to its ...
As hashed out in the comments, the OP has not enabled IP forwarding on the OpenVPN server so it won't route any of the incoming packets from the OpenVPN clients to the internal network,
net.ipv4.ip_forward needs to be set to one in /etc/sysclt.conf. That file is only read on a reboot so you should run the following to enable it without a reboot:
$ echo 1 >...