Question about sharing a VPN tunnel

Parbold

Hi all - I have what I think is a simple question, but one that has spun me into an analysis loop and I can no longer see the wood for the trees and would gratefully accept any help offered.

My question is - how do I get the return traffic back off the tun0 interface and onto eth0

Requirements

I need to allow two machines in different physical and logical locations to talk to each other securely, where the only connectivity is internet based.
The 'target' end can only have one nic
Neither the source nor the target can have any vpn software installed upon them.
Subnet overlap at either end prevents routing whole subnets

Solution premise

So I am looking to create a tunnel between two, new, separate, but logically close machines at either end to achieve the desired connectivity at layer 3.
(I am using a user auth connection at the moment, until I can get the solution working at which point I will certificate the connection and make it automated)

Status so far

I have got the system set up and working to a point.

Source machine is running Linux, target machine is running Windows, both the VPN machines are Linux 64bit SMP, 3.14 kernel

The setup is as follows

Source: S1, 10.0.0.1
Source (Local VPN): SVPN, 10.0.0.2 (OpenVPN 2.3.2 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep 4 2013) - running as client
Source (Local VPN) Tunnel: 10.255.255.6

Remote VPN Tunnel: 10.255.255.1 (OpenVPN 2.3.2 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep 4 2013) - running as server
Remote VPN: TVPN, 10.84.0.1
Remote Target: T1, 10.38.0.1

When the tunnel is up an running, I can ping from the local VPN through the remote VPN to the target machine and get the replies

I have a route on the source machine to send traffic for 10.38.0.1 via the source (local) vpn (10.0.0.2) and a TCPDUMP of the traffic shows:-

1. On the source 10.0.0.1 : ICMP echo request 10.0.0.1 -> 10.38.0.1
2. On the SVPN 10.0.0.2 : ICMP echo request 10.0.0.1 -> 10.38.0.1
3. On the SVPN 10.0.0.2 : ICMP echo request 10.255.255.6 -> 10.38.0.1

4. On the TVPN 10.84.0.1: ICMP echo request 10.255.255.6 -> 10.38.0.1

** NB - I cannot packet trace on the target server, but replies are coming back

5. On the TVPN 10.84.0.1: ICMP echo reply 10.38.0.1 -> 10.255.255.6

6. On the SVPN 10.0.0.2: ICMP echo reply 10.38.0.1 -> 10.255.255.6
7. On the SVPN 10.0.0.2: ICMP echo reply 10.38.0.1 -> 10.0.0.1
8. ....... nothing 🙁 the ICMP reply never makes it to the Source server 10.0.0.1

I can only assume that the openvpn client is preventing the egress of the de-natted reply from tun0 getting onto eth0
I have read in one of the online pages I got back from many hours of googling that there is a setting to allow route-gateway, but have not been able to find any command line / config file directive help in setting this up. It all seems to be GUI based, and I don't have a gui on the machines the OpenVPN software reside on.

Configuration

The config files on the SVPN are as follows:-

cat /etc/sysctl.conf

net.ipv4.ip_forward=1
kernel.msgmnb=65536
kernel.msgmax=65536
kernel.shmmax=68719476736
net.ipv4.conf.default.rp_filter=1
kernel.sysrq=0
net.ipv4.conf.default.accept_source_route=0
kernel.shmall=4294967296
net.ipv4.tcp_syncookies=1
kernel.core_uses_pid=1

cat /etc/sysconfig/iptables

*nat

:INPUT ACCEPT [0:0]
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT

:PREROUTING ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]
-A OUTPUT -o eth0 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o tun0 -j MASQUERADE
-A POSTROUTING -o eth0 -j ACCEPT
COMMIT

*filter

:INPUT ACCEPT [34:4777]
:FORWARD ACCEPT [0:0]
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT

:OUTPUT ACCEPT [37:17570]

COMMIT

cat ~/client.ovpn

client
dev tun
proto udp
remote xxx.xxx.xxx.xxx 1194 # - Your server IP and OpenVPN Port
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ca ca.crt
auth-user-pass
comp-lzo
reneg-sec 0
verb 3
route no-pull
route 10.38.0.1 255.255.255.255 vpn_gateway

The config file on the Target VPN server is as follows:-

cat /etc/openvpn/server.conf

port 1194 #- port
proto udp #- protocol
dev tun
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
reneg-sec 0
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
plugin /etc/openvpn/openvpn-auth-pam.so /etc/pam.d/login
client-cert-not-required
username-as-common-name
server 10.255.255.0 255.255.255.0
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 5 30
comp-lzo
persist-key
persist-tun
status 1194.log
verb 3

Traffic

Parbold wroteNeither the source nor the target can have any vpn software installed upon them

erm .. what are you trying to do ? You MUST have OpenVPN Installed to make a VPN ...

Parbold

I have two new boxes that have a vpn between them. One of each is local to the boxes I want to be able to talk to each other.

I am trying to get traffic routed from the original source box through the new vpn'ed boxes to the target. I am 75% of the way there.

Parbold

I have installed two new boxes, one load to each of the source and target machines.

The two new boxes have a VPN between them, using openvpn

I am trying to get traffic to pass from the source, via the VPN (on the other boxes) to the server.

I have got 75% of the way there.
Traffic from the source, goes to the near VPN box, across to the remote vpn box and to the target.
Return traffic makes it all the way back to the vpn box near the source, but the return traffic never hits the source (originator) box - it just dies on the local vpn endpoint.

I've tried the client config route with iroute and route in server configs, but nothing I try seems to make the reply traffic egress from the local vpn back to the originator.

Traffic

Parbold wroteReturn traffic makes it all the way back to the vpn box near the source, but the return traffic never hits the source (originator) box - it just dies on the local vpn endpoint

Did you enable IP_Forwarding on the " local vpn endpoint " ?

Parbold

Did you enable IP_Forwarding on the " local vpn endpoint " ?

If you mean, did I set sysctl to net.ipv4.ip_forward=1, then yes I did (on both vpn boxes). Once done, I did a sysctl -p, and have also restarted both boxes.