Score:1

Can't establish s2s VPN connection between AWS EC2 and OVH Public Cloud using WireGuard

gb flag

I can't establish VPN connection between AWS EC2 instance and OVH Public Cloud. In /var/log/syslog there's no errors - just some info about wg-quick operations like adding routing etc.

AWS EC2 instance:

  • OS: Ubuntu 20.04.2 LTS

  • Internal IP Address: ex. 10.0.22.22/16 ens4

  • Public IP Address: ex. 123.123.123.123/32 aws public interface

  • Port 12345/udp and 12345/tcp opened via Security group

  • Config:
    /etc/wireguard/wg0.conf:

    [Interface]
    Address = 10.10.0.1/24
    SaveConfig = false
    PrivateKey = <aws-private-key>
    ListenPort = 12345
    PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE;  
    PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens4 -j MASQUERADE;
    
    [Peer]
    PublicKey = <ovh-public-key>
    AllowedIPs = 10.10.0.2/24, 192.168.10.0/16
    Endpoint = 321.321.321.321:12345
    

OVH Public Cloud instance:

  • OS: Ubuntu 21.04

  • Internal IP Address: ex. 192.168.10.100/16 enp0s2

  • Public IP Address: ex. 321.321.321.321/32 enp0s1

  • Port 12345/udp and 12345/tcp opened via ufw

  • Config:
    /etc/wireguard/wg0.conf:

    [Interface]
    Address = 10.10.0.2/24
    SaveConfig = false
    PrivateKey = <ovh-private-key>
    ListenPort = 12345
    PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o enp0s1 -j MASQUERADE;  
    PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o enp0s1 -j MASQUERADE;
    
    [Peer]
    PublicKey = <aws-public-key>
    AllowedIPs = 10.10.0.1/24, 10.0.0.0/16
    Endpoint = 123.123.123.123:12345
    

Both instances:

  • net.ipv4.ip_forward=1 in /etc/sysctl.conf
  • command: wg-quick up /etc/wireguard/wg0.conf
  • both are running and have created wg0 interfaces with IPs from wg0.conf

Summary:

  • curl to app listening on opened port 80/tcp doesn't work on both sides.

Am I missing something? How can I debug this? I've read several articles, but I can't figure it out.

UPDATE:

Communication is working after modifying /etc/wireguard/wg0.conf:
from AllowedIPs = 10.10.0.x/24, (...) to AllowedIPs = 10.10.0.x/32, (...)
as @Tom Yan suggested.

But I'm struggling with routing. This is how does it look with pings to other servers that are in the same networks as VPN Servers.

In AWS I added to routing table the rule:
192.168.10.0/16 via AWS-VPN-interface

In OVH-some-instance I ran:
ip route add 10.0.0.0/16 via 192.168.10.100 dev eno4

The summary of pinging:

OVH-VPN             -> AWS-VPN              OK
OVH-VPN             -> AWS-some-instance    timeout
OVH-some-instance   -> AWS-VPN              OK
OVH-some-instance   -> AWS-some-instance    timeout

AWS-VPN             -> OVH-VPN              OK
AWS-VPN             -> OVH-some-instance    OK
AWS-some-instance   -> OVH-VPN              timeout
AWS-some-instance   -> OVH-some-instance    timeout

In logs I can see only informations:

$: dmesg -wH
[Jul20 13:40] wireguard: wg0: Receiving keepalive packet from peer 5 (123.123.123.123:12345)

IPTables & Routing

AWS-VPN:

$: iptables-save
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -o wg0 -j ACCEPT

$: ip route
default via 10.0.22.1 dev ens4 proto dhcp src 10.0.22.22 metric 100 
10.0.22.0/19 dev ens4 proto kernel scope link src 10.0.22.22 
10.0.22.1 dev ens4 proto dhcp scope link src 10.0.22.22 metric 100 
10.10.0.2 dev wg0 scope link 
192.168.10.0/16 dev wg0 scope link 

### AWS Console Panel rules for AWS-VPN server
Custom TCP      TCP 12345   321.321.321.321/32
Custom UDP      UDP 12345   321.321.321.321/32
All traffic     All All     321.321.321.321/32
All traffic     All All     10.0.0.0/16
All traffic     All All     192.168.10.0/16
All traffic     All All     10.10.0.2/32

OVH-VPN:

$: iptables-save
*filter
:INPUT ACCEPT [26612:55893110]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [34036:3715836]
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -o wg0 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [69:5450]
-A POSTROUTING -o enp0s1 -j MASQUERADE
COMMIT

$: ip route
default via 321.321.321.1 dev enp0s1 proto dhcp src 321.321.321.321 metric 100 
10.0.0.0/16 dev wg0 scope link 
321.321.321.1 dev enp0s2 proto dhcp scope link src 321.321.321.321 metric 100 
169.254.169.254 via 192.168.10.2 dev enp0s2 proto dhcp src 192.168.10.100 metric 100 
10.10.0.1 dev wg0 scope link 
192.168.10.0/16 dev enp0s2 proto kernel scope link src 192.168.10.100

$: firewall-cmd --list-all-zones
# I removed empty lines
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 10.0.0.0/16 10.10.0.1/32 123.123.123.123/32
  services: dhcpv6-client mdns ssh
  ports: 12345/tcp 12345/udp
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 123.123.123.123/32
  services: dhcpv6-client ssh
  ports: 12345/tcp 12345/udp

What else should I do to make it work?

Tim avatar
gp flag
Tim
I would start by opening firewall to allow IMCP to verify network connectivity. Then I might telnet to the ports on each local machine to check wireguard is listening, then telnet to the ports from the remote machine.
Tom Yan avatar
in flag
Please do not use `/24` in `AllowedIPs=` unless the address is actually a subnet ID. (So it should be `10.10.0.1/32` / `10.10.0.2/32` or even just `10.10.0.1` / `10.10.0.2`. In fact, if you are not going to just allow `10.10.0.0/24` on both sides, it's probably unnecessary to use `/24` in `Address=`.)
Tom Yan avatar
in flag
Also `wg` tells you when / if you received a handshake from the other side.
maar avatar
gb flag
@TomYan Thanks! It's working after I changed `AllowedIPs` as you suggested. But I have some routing problems.. I've edited main post. I really appreciate your help!
Tom Yan avatar
in flag
Could you add the `iptables-save` output of both hosts?
maar avatar
gb flag
@TomYan Sure, I've updated the question content with `iptables-save` output.
Tom Yan avatar
in flag
Why are you not giving *actual* output for `AWS-VPN`?
Tom Yan avatar
in flag
Also, are either/both of them the default gateway for their some-instance(s)? For `AWS-some-instance -> OVH-VPN` / `OVH-some-instance -> AWS-VPN` to work / have worked, there should be route on the some-instance(s) that covers `10.10.0.1` and `10.10.0.2` respectively (since you are not `MASQUERADE`ing for what goes out of the VPN interface on either side). Also, you mentioned that you add the route `192.168.10.0/16 via [sic.] AWS-VPN-interface`, did you mean wg-quick didn't add it automatically for you? Why are the (manual) route adding you mentioned not "balanced"?
maar avatar
gb flag
@TomYan The route `192.168.10.0/16 via [sic.] AWS-VPN-interface` I added in AWS Console Panel, it's a route for other instances (entire network). Also on the AWS-VPN server I have only private interface (`ens4`) and there's destination NAT to public IP through AWS built-in firewall outside of the AWS-VPN instance. On OVH-VPN I have two interfaces - public (`enp0s1`) and private (`enp0s2`) interface and as firewall I'm using `firewalld` (in OVH-VPN).
maar avatar
gb flag
So, if I understand correctly in AWS side I should add route `192.168.10.0/16 via 10.10.0.1`? And on the OVH-VPN `10.10.0.2/16 via 10.10.0.2`? When I'm trying to do that on the other OVH-server I have an error: `Error: Nexthop has invalid gateway.`
maar avatar
gb flag
@TomYan I've added also ip route comand output from both.
Tom Yan avatar
in flag
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/127745/discussion-between-tom-yan-and-maar).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.