I've set up an OpenVPN network, and it is working properly in the sense that I can access the inner/LAN machines from the remote client. However, my problem is that all traffic from the remote machines appears to the LAN machines as though it is coming from the OpenVPN server machine, and not from the client machine.

To Better explain, consider my network topology:

Network Topology

Machine R connected to the OpenVPN server on Machine A, and got assigned the IP address of

Machine R then makes a request to Apache running on Machine B. The request arrives properly and I get a response. The problem is that Machine B sees the request coming in from (Machine A's IP) and not

I would like the latter.

My Current Setup

Machine A

This is a snippet of the relevant iptables rules:




// snip

# accept incoming VPN connections
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT

# forward VPN traffic
-A FORWARD -s -d -i tun0 -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

I have also enabled ip_forwarding:

echo 1 > /proc/sys/net/ipv4/ip_forward

.. and made the appropriate changes to /etc/sysctl.conf to make it permanent.

In the OpenVPN configuration, I have:

push "route"

Machine B

Since Machine A is not Machine B's gateway, I manually added a route on Machine B as follows:

ip route add via dev eth0

To test the which IP is being routed, I created a small PHP script called showip.php:

<?php echo "Your IP is: ", $_SERVER['REMOTE_ADDR'], "\n"; ?>

Machine R

# wget -q -O -
Your IP is:

How do I get it to say


To clarify, in my particular case Machine A has one NIC (eth0) which serves both the LAN and WAN.

  • 1
    Why do you have a nat rule enabled in your firewall if you don't want NAT? Perhaps you should start by removing your -A POSTROUTING -o eth0 -j MASQUERADE and figure out what happens? Also your question is unclear, since you haven't told us if eth0 is the lan or wan interface. In any case, you should be looking at traceroutes and tcpdump. These are the tools that help solve routing problems. – Zoredache May 15 '14 at 23:59
  • To answer some of your questions: (1) eth0 is both the LAN and WAN interface (2) As expected, removing -A POSTROUTING -o eth0 -j MASQUERADE makes it stop working. I'm not an iptables expert, but I believe this line is what is creating a NAT which is what I don't want, and I don't know what to replace it with (hence this question). (3) traceroutes are worthless because they either hang or return * * * * (4) I'm happy to run tcpdump if anyone can suggest what to look for – Oz Solomon May 16 '14 at 1:55

Answering my own question:

As further background, these machines are hosted on Linode. It turns out that they use static maps in their switches in order to route traffic to specific nodes on the LAN. Since the VPN source IPs aren't part of those static maps, the traffic wasn't routed anywhere.

So this turns out to be a Linode specific issue, but hopefully it can help others to know that.

  • Hey Oz, Actually I'm having the exactly same problem, but I'm running the servers in Amazon. Do you know if it's possible to fix that there ? Thanks. – Erico Sep 27 '14 at 4:16
  • @Erico I don't know enough about AWS. I suggest you start a new question and specifically mention AWS in the question title. – Oz Solomon Sep 27 '14 at 14:26
  • Hey Oz, thanks a lot for your answer, actually I was able to make it work. It was a problem with my AWS security settings. – Erico Sep 29 '14 at 13:54
  • how it was done in AWS would be interesting to know details of. – Sverre Sep 7 '16 at 18:42
  • @Erico, could you say what security setting this was in AWS? Have same issue... – Paul Grimshaw Apr 4 '18 at 21:22

Since you found that the connection between Machine A and Machine B is not really a switched Ethernet, and that it can only handle traffic using the IP addresses you have been assigned, you need to find another solution.

This can be achieved through the use of a tunnel. There are various kinds of tunnels, that could be used. One is to use VPN, which might be the simplest since Machine A is already a VPN server. Then you just need to make Machine B a VPN client, and then add routing table entries to forward the needed prefixes through that VPN connection.

Another option is to use a GRE tunnel or simply IP over IP. Those tunnels and associated routes could be configured statically, which would give them an advantage over the VPN approach.


On Machine A you have a NAT rule, which cause it to change the client IP before routing the packets to Machine B. The first you need to do is to remove that NAT rule, such that packets are forwarded to Machine B without modifications.

This change may cause the connections to stop working, if the routing table on Machine B is incomplete. What happens in this case is that packets are delivered correctly to Machine B, but it does not have a route to deliver the replies back. That will either make it not respond at all or send the responses to the internet instead of to the VPN server.

On Machine B you can try adding a route with the following command ip route add via

  • As stated in the original question, Machine B already had the appropriate ip route add applied. If I remove the NAT/MASQUERADE line, I can no longer ping Machine B. – Oz Solomon May 18 '14 at 18:58
  • @OzSolomon In that case the problem is a little less obvious. But it can still be found. Which interface on B is connected to A? If it is eth0, then look at the output from tcpdump -pni eth0 'host' on host B while you are trying to request the page. – kasperd May 18 '14 at 19:50
  • Thank you for your help. I have discovered the issue, please see my other answer. – Oz Solomon May 20 '14 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.