3

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 10.200.200.5.

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 192.168.0.10 (Machine A's IP) and not 10.200.200.5.

I would like the latter.

My Current Setup

Machine A

This is a snippet of the relevant iptables rules:

*nat
:PREROUTING ACCEPT [18:1080]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

-A POSTROUTING -o eth0 -j MASQUERADE

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

// snip

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

# forward VPN traffic
-A FORWARD -s 10.200.200.0/25 -d 192.168.128.0/17 -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:

server 10.200.200.0 255.255.255.128
push "route 192.168.0.0 255.255.255.0"

Machine B

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

ip route add 10.200.200.0/25 via 192.168.0.10 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 - http://192.168.0.11/showip.php
Your IP is: 192.168.0.10

How do I get it to say 10.200.200.5?

Update

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

Oz Solomon
  • 365
  • 2
  • 3
  • 12
  • 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 01:55

3 Answers3

1

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.

Oz Solomon
  • 365
  • 2
  • 3
  • 12
  • 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 04: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 07 '16 at 18:42
  • @Erico, could you say what security setting this was in AWS? Have same issue... – Paul Grimshaw Apr 04 '18 at 21:22
  • @PaulGrimshaw Sorry it's been so long that I don't even remember what that was. The root cause might be the source/destination check in the EC2 instance that needs to be disabled. – Erico Apr 07 '18 at 21:38
  • @Erico, thanks - but still wasn't working with that disabled on both servers. I have parked for now, but need to dive back into this at some point. If anyone else has any ideas in the meantime, please let me know! – Paul Grimshaw Apr 10 '18 at 13:31
1

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.

kasperd
  • 30,455
  • 17
  • 76
  • 124
0

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 10.200.200.0/24 via 192.168.0.10

kasperd
  • 30,455
  • 17
  • 76
  • 124
  • 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 10.200.200.5'` 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