[Question] Connecting from behind NAT to two established vpncloud VPS with static public IP

[eskies]

Hello, I'm trying to connect my pc (behind nat, with dynamic public IP) to a peer network between 2 vps.

I did config my 2 VPS using a tutorial from this https://wp.alshowto.com/build-a-vpn-between-servers/ and success
Now, I have 1 server that works as a data backup server (at my place) behind NAT and doesn't have public IP. How to set it so it could connect to other VPS? which VPS should I connect from 3rd server and how to do it.

I try to read the documentation, but still yet cant find it.

[dswd]

Please have a look at the beginner tutorial: https://vpncloud.ddswd.de/docs/tutorials/basic/.
In you case you need to add the addresses of your 2 VPS servers as peers for your home server. You can't add your home server as peer to the VPS since it has a dynamic IP, but that is ok as long as the peers can find each other.

[eskies]

Thank you @dswd
Today I'm gonna scale my private (behind NAT) server by placing it on the other side but I got a problem.

I've 2 VPS with Public Static IP:

VPS-1: 
- eth0: 192.168.1.1 /24 (claimed) (has other service running on machine: 192.168.1.2)
- VPN: 200.1.0.1
- IP route:
   - 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
   - 192.168.2.0/24 via 200.1.0.2 dev tunnel-vpncloud
   - 192.168.51.0/24 via 200.1.0.51 dev tunnel-vpncloud
   - 192.168.52.0/24 via 200.1.0.52 dev tunnel-vpncloud
   - 200.1.0.0/24 dev tunnel-vpncloud proto kernel scope link src 200.1.0.1
VPS-2:
- eth0: 192.168.2.1 /24 (claimed) (has other service running on machine: 192.168.2.2)
- VPN: 200.1.0.2
- IP route:
   - 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.1
   - 192.168.1.0/24 via 200.1.0.1 dev tunnel-vpncloud
   - 192.168.51.0/24 via 200.1.0.51 dev tunnel-vpncloud
   - 192.168.52.0/24 via 200.1.0.52 dev tunnel-vpncloud
   - 200.1.0.0/24 dev tunnel-vpncloud proto kernel scope link src 200.1.0.2

and then 2 servers behind NAT and dynamic IP

PPS-1:
- eth0: 192.168.51.0/24 (claimed) (has other service running on machine: 192.168.51.2)
- VPN: 200.1.0.51
PPS-2:
- eth0: 192.168.52.0/24 (claimed) (has other service running on machine: 192.168.52.2)
- VPN: 200.1.0.52

I managed to create a hook script every time peers connected, claimed address by that peer will be routed to peer VPN API. Using this script:

#/bin/bash
echo "New connected peer from $PEER. It claimed: $CLAIMS on node $NODE_ID from dev $IFNAME"
IFS=" " read -a clms <<< $CLAIMS

if (("${#clms[@]}" >= "2"))
then
  VIA="${clms[-1]}"
  VIA=$(sed 's/\/.*//1' <<< $VIA)
  for clm in $clms
  do
    sh -c "ip route add $clm via $VIA dev $IFNAME"
  done
fi

And using this config:

listen: 3210
peers:
  - vps1:3210
  - vps2:3210
peer-timeout: 180
switch-timeout: 180
crypto:
  password: "secret"
device:
  name: "tunnel-vpncloud"
  type: tun
  fix-rp-filter: true
mode: normal
claims:
  - (eth0 network on machine)
auto-claim: true
ip: "200.1.0.X"
ifup: >-
  sysctl -w net.ipv4.ip_forward=1
beacon:
  interval: 3600

When I test ping from 192.168.51.2 to either 192.168.1.2 or 192.168.2.2, it works perfectly, and test again from 192.168.52.2 to either 192.168.1.2 or 192.168.2.2, it works perfectly. When I try to ping from 192.168.52.2 to 192.168.51.2 it won't work. I'm trying to ping it from 200.1.0.52 to 200.1.0.51 also not working. Got message from verbose vpncloud on 192.168.52.2:

........
DEBUG - No destination for 192.168.51.2 found, dropping
DEBUG - Repeating last init message
DEBUG - Sending msg with 155 bytes to [::ffff:192.168.51.2]:3210
DEBUG - Read data from interface: src: 200.1.0.52, dst: 192.168.51.2, 183 bytes
DEBUG - No destination for 192.168.51.2 found, dropping
DEBUG - Read data from interface: src: 192.168.52.2, dst: 200.1.0.51, 84 bytes
DEBUG - No destination for 200.1.189.51 found, dropping
DEBUG - Read data from interface: src: 192.168.52.2, dst: 200.1.0.51, 84 bytes
DEBUG - No destination for 200.1.0.51 found, dropping
DEBUG - Repeating last init message
DEBUG - Sending msg with 155 bytes to [::ffff:192.168.51.2]:3210
DEBUG - Read data from interface: src: 200.1.0.52, dst: 192.168.51.2, 183 bytes

I'm tried adding route 192.168.51.2/24 via 200.1.189.1 and still not working. Is it possible to make 192.168.51.2 and 192.168.52.2 able to communicate in this scenario? should I change the config to make it work?
So many thanks for your hard work on VPNCloud.

[dswd]

(Please mind that I can't provide help with specific use setups.)

It seems that you are trying to tell vpncloud how to forward traffic between its peers. That doesn't work. Vpncloud will connect all nodes and forward traffic directly (even when 2 of them are behind NAT, it just might take a few minutes to connect).

In your case it seems that you want 4 machines to talk to each other. This is a very simple setup:

• Give each of them a unique IP (from a private IP range)
• Configure the 2 nodes with static addresses as peers for all other nodes

If you want nodes to work as a gateway for a whole network then you need to:

• Add the network as a claim to the gateway node
• Add a route to that network (via vpncloud) to all other nodes
• Add a route to your vpn network (via the gateway) to all nodes in the network behind the gateway
• Enable ip forwarding on the gateway

Most of the time it is easier to just add all machines as nodes to the VPN than to setup routing for a gatway solution.

[eskies]

I'll try it, thank you for your advice @dswd

[eskies]

I've tried as you suggest. The problem within my PPS-2 ISP (let say X). Seems that I don't get a public IP address on my router, the public IP address is about 3-4 hop from my PPS-2. When I switch to another ISP (let say Y) (that exactly has public IP on the router, even dynamic IP), it works perfectly in a simple setup (PPS-1 can ping PPS-2).
To overcome the problem on ISP X, I've tried to reroute all data that going to either PPS-1 or PPS-2 must send to the VPS-1 or VPS-2. It works, but CPU usage just spikes up on that 2 VPS. Guess I need to find another way to do this (or maybe find another ISP).
Thank you @dswd

[dswd]

As a last thing to try, you can use different VPNs for each hidden node and use the public nodes to route between them. Just an Idea, not sure if it works.