IPSec VPN between DO Droplet and other (trusted) provider

January 28, 2019 1.2k views
VPN Networking
rdjurdjevic
By:
rdjurdjevic

Hi!

I have a requirement to set up IPsec VPN between my company’s droplet and a network owned by partner company that uses another provider.
Tooling:

  • Debian (my droplet) with IP e.g 169.22.231.13 and local address e.g 10.22.0.50
  • IPsec-Tools & Racoon
  • Tunnel
  • ESP

I’ve created a test environment in order to try out the tooling and feasibility of the task, consisting of 2 Droplets that I managed to connect according to the points above, and managed to achieve what I wanted (while testing with my own droplets).

Onto the real case - here’s the description of the remote server (owned by the partner company):

  • entry point has a firewall (my droplet is white-listed) - e.g public IP 153.132.142.123
  • service running on my droplet needs to connect to a service behind this public IP, e.g internal IP 10.100.232.11

I have managed to set up a VPN tunnel between my droplet and the remote network, according to:

  • racoonctl show-sa ipsec showing both in and out directions of the tunnel, with esp mode=tunnel and state=mature
  • racoonctl -l show-sa isakmp is showing correct destination and Phase 2 = 1
  • also, logs are reporting that connection is successfully made

However, when I try to ping the 10.100.232.11 address, it hangs, and when partner service pings my internal IP (that I mapped in Security Association Database) they tell me this IP is unreachable.

I have following suspicions:

  • my and/or partner networks are using NAT, while we both configured our VPNs with NAT Traversal = OFF;
  • DigitalOcean does not allow IPsec VPNs to other providers, due to some internal networking rules to protect our droplets

Can someone point me in the right direction? I would be most grateful to whomever could share some knowledge on this topic with me.

Thanks & Regards

Log In to Comment
1 Answer
jarland MOD January 28, 2019

Greetings!

I don’t use IPSec myself (I tend to use GRE tunnels), but I have a couple of theories that might at least help.

  1. You might try a different internal range to make sure you don’t cross paths with our anchor (for floating IPs) or private networking ranges. What about a 192.168 range? We never use that range for anything we do, but we do have those two things that will operate within subsets of 10.0.0.0/8.

  2. When the packets pass through they should have the public IP as the source in the header. Otherwise we’ll consider it to be spoofed and drop it whether coming in or going out.

Hope that helps a bit!

Jarland

Reply
  • rdjurdjevic January 28, 2019

    Dear @jarland,

    Thanks for your response! I have 2 brief follow-up questions:

    1. I’m fine with using 192.168 range, thanks for the suggestion! As I simply used the local address of the Droplet I obtained with hostname -I, I assume here I would need to set up some extra configuration e.g with iptables or routes? If you could point me to some online material or simply tell me which concept I need to learn and apply, that would be sufficient!
    2. Okay, I’ve got this from other sources too, and it makes sense as it is for our Droplets’ security. Could you tell me what technique I could use to keep public IP as source in header of packets? Does NAT come into place here? If so, is it required on both sides?

    Thanks a lot for your help! If it works out, I would be happy to post my findings in the community forum!

    Regards,
    Rasha

Have another answer? Share your knowledge.

Related