Lindsay Vette's picture

I am having issues getting routing configured for a site to site VPN between an on-premise network and AWS.

At the AWS end I have deployed a TurnKey OpenVPN server from the AWS Marketplace. At the on-premise end a TurnKey OpenVPN server downloaded and deployed in Hyper-V.

At the  AWS end I have two subnets, 10.0.1.0/24 and 10.0.2.0/24. At the on-premise end three subnets, 10.10.1.0/24, 10.105.3.0/24 and 10.102.40.0/24.

The AWS end is the server, and the on-premise end the client.

The server.conf looks like this for routing:

# virtual subnet unique for openvpn to draw client addresses from
# the server will be configured with x.x.x.1
# important: must not be used on your network
server 10.115.252.0 255.255.255.0

route 10.10.1.0 255.255.255.0
route 10.105.3.0 255.255.255.0
route 10.102.40.0 255.255.255.0


# push routes to clients to allow them to reach private subnets
push "route 10.0.1.0 255.255.255.0"
push "route 10.0.2.0 255.255.255.0"

 

The ccd file like this for the client:

iroute 10.10.2.0 255.255.255.0
iroute 10.105.3.0 255.255.255.0
iroute 10.102.40.0 255.255.255.0

 

When the link is established, the client (on-premise) end gets routes added for 10.0.1.0/24 and 10.0.2.0/24 as expected. However, I am having to manually addd routes at the server (AWS) end for 10.10.1.0/24 etc.

Does anyone have any insites on this?

 

Thanks,

Lindsay

Forum: 
Jeremy Davis's picture

What versions are these? I'm guessing that the AWSMP server is v14.1 (because that's the latest available there). And if you've installed from the latest ISO locally, then you'll have v14.2 there (which has a couple of bugs fixed).

That may possibly explain why things are working better on the local end, than the remote end?!

I hope to update the AWSMP images (to v14.2) in the next week or 2.

TBH, my direct experience with OpenVPN is pretty limited, so if that's not the issue, I'm not sure how useful I will be. But I can certainly try to recreate your issue when I have time. Unfortuantely, time is not something I have tons spare at the moment. I need to tidy up the AWSMP images ASAP, plus I need to get the basis of v15.0 in place so the app dev guys have got something to be going on with (v14.2 will be the last v14.x release).

Lindsay Vette's picture

Hi,

Yes you are correct, the AWS server is running TurnKey 14.1, the local server 14.2.

Both are running openvpn  2.3.4-5+deb8u2 looking at "dpkg -l"

 

Thanks,

Lindsay

Jeremy Davis's picture

However, since we first released v14.0, the Debian OpenVPN package had a security update which changed the default package config a bit. That broke some of our initial config helper scripts in v14.1 (which we've fixed in v14.2).

I'm almost certain, that your issue is related to the v14.1 bug that we fixed in v14.2. If you are open to re-configuring your AWSMP server (just the initial TurnKey OpenVPN initialisation, not the whole setup from scratch), then you could try working around this by downloading the updated config script and redoing the initial TurnKey OpenVPN config. If you log into your AWSMP server via SSH, then this should do the trick:

SCRIPT=/usr/lib/inithooks/bin/openvpn-server-init.sh
URL=https://raw.githubusercontent.com/turnkeylinux-apps/openvpn/master/overlay${SCRIPT}
sudo wget $URL -O $SCRIPT
sudo /usr/lib/inithooks/bin/openvpn.py
Note, the sudo prefix for the last 2 commands is only needed/wanted on the AWSMP server. All other builds default to using the root account and don't even have sudo installed.

If you test out my workaround and it works as expected, please let me know. Regardless, I've opened a bug on our tracker, to ensure that your issue doesn't get forgotten.

Either way, I'll get the AWSMP AMI updated as soon as possible and if the issue still exists, we'll look into it further.

Also, thanks again for reporting the issue! It's one of the best things that users can do to make TurnKey better for everyone!

Lindsay Vette's picture

Hi

Thanks for your response, very timely as I am under pressure to get this working. I will need to generate a new client key I assume?

Lindsay

Lindsay Vette's picture

Hi,

The update has resolved the routes being added, and I now have routes being added correctly.

I am now finding that it hasn't resolved the basic issue I was having in that packets are not being forwarded past the local tun0 adapter.

If I run a tcpdump to watch for ping packets on the tun0 device on each end of the VPN, then ping through from one VPNed LAN to the other, I see on the originating VPN server tun0 device the packets being forwarded, but they are never received at the tun0 device of the receiving VPN server.

IPTABLES rules on both servers explicitly accept packets to be forwarded on eth0 and tun+ (covers all tun devices).

All suggestions gratefully accepted.

 

Lindsay

Jeremy Davis's picture

Sorry on the radio silence. I only just realised that I hadn't replied to your latest message. :(

Unfortunately, I do not understand why that would be occurring. The only thought I have is, whilst your firewall rules may be explicitly set up the way you want, have you enabled the firewall?

I know that may sound like a dumb suggestion (and you are possibly already all over it) but whilst TurnKey ships with pre-configured firewall rules, it's disabled by default.

For AWS servers, if you use the default/suggested security group (provided by us), then the AWS security group should more-or-less mirror our default firewall rules, however iptables (the Linux firewall) will still be disabled by default.

If you are already all over that (or you've now enabled it on both ends) and you're still having issues, then I'm not sure. I'd need to try to recreate your issue and see if I can match your experience. If we can reproduce a bug, we can fix it; or at least develop a work around.

I'm pretty under the pump at the moment trying to finalise the v14.2 release and start work on the v15.0 release (I'm currently blocking all our app dev guys from starting work on v15.0 release of appliances). And perhaps updating the AWSMP server to v14.2 may even address this issue (I may be reaching here as no one else has reported this)? So I'm not sure when I'll be able to do that. But the more info you can share about how you've configured things, the easier it will be for me to match your settings and hopefully reproduce your issue.

Jeremy Davis's picture

As per the (closed) bugs, #925 and #772, this issue should have been resolved in the v14.2 release.

If you are using v14.2 (or newer) and still experiencing this issue, please provide as much info as possible, as it's likely that whilst the result may be the same, the cause is likely different to this thread.

Add new comment