3

I have a cloud server running on Ubuntu 14.04 which is connected with an IPsec tunnel.

The server has a real interface with a public IP x.x.x.x and a virtual interface 172.16.100.1 All the traffic to the remote network should be routed over the virtual interface with IP 172.16.100.1 Therefore I have set up an routing an entry. This works correctly for all the traffic that is generated on that server.

route add -net 172.17.1.2/21 gw 172.16.100.1 dev eth0:1

But another requirement is that if the cloud server receives traffic on it's public IP with a specific port, that traffic should also be forwarded to the remote network. I tried that by adding an IP table entry:

iptables -t nat -A PREROUTING -p tcp --dport 45678 -j DNAT --to-destination 172.17.1.2:29871

but the problem is that it somehow ignores the routing configuration and just forwards the request with its source IP instead of using 172.16.x.x

Is that configuration even the right approach or am I completely wrong? What else do I have to configure to forward the traffic correctly?

Improve this question
5
  • This question lacks the actual interface configurations. "IPSec tunnel" has lots of meanings and by itself doesn't tell anything about your setup.
    – drookie
    Feb 22, 2016 at 10:51
  • what information are you missing? the whole VPN setup is based on Strongswan, but I'm not sure if it is a problem with that VPN itself. As said when generating some traffic on the server itself it is correctly routed via 172.16.100.1 to the remote machine.
    – Patrick L
    Feb 22, 2016 at 17:56
  • I'm not sure whether it's a problem at all. So far you fail to explain one.
    – drookie
    Feb 22, 2016 at 18:13
  • the problem is that when the server receives a request on its public IP that request is just forwarded with its original source IP but what I want is that the request is forwarded with the private IP 172.16.100.1 as its source
    – Patrick L
    Feb 22, 2016 at 20:32
  • That would be a total ignorance of how IP protocol works. The stack always answers from an address the request was received on. Otherwise there's no possible way of determining what packets belong to what session.
    – drookie
    Feb 22, 2016 at 20:44

1 Answer 1

Reset to default
0

adding following POSTROUTING entry has solved the problem:

iptables -t nat -A POSTROUTING -p tcp --dport 29871 -j SNAT --to-source 172.16.100.1
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .