0

I have a dedicated server, which I have everything running off, however the dedi lacks DDoS protection, so I have purchased a VPS that comes with it, so I can effectively use it as a proxy.

I have port forwarding setup on the VPS with the following commands:

iptables -t nat -A PREROUTING -p tcp --dport 30001 -j DNAT --to-destination DEDIIP:30001
iptables -t nat -A POSTROUTING -p tcp -d DEDIIP --dport 21 -j SNAT --to-source VPSIP

Connecting to the VPSIP works and connects me to the dedi however there is one problem. The dedi shows every connection to be coming from the same IP (the VPS) is there a way I can retain the original one?

For example:

Now:

CLIENT --> VPS --> Dedi (Shows the clients IP as the VPS)

What I need it to be like

CLIENT --> VPS --> Dedi (Shows the clients IP, just as if the VPS wasn't there)

Does anyone know how to do this, or where I have gone wrong?

Edit to provide additional information:

VPS:

Result of ip route show

default via xxx.xxx.xxx.1 dev ens3
xxx.xxx.xxx.0/24 dev ens3  proto kernel  scope link  src xxx.xxx.xxx.138

Result of ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 06:d4:28:00:08:6e brd ff:ff:ff:ff:ff:ff
    inet xxx.xxx.xxx.138/24 brd xxx.xxx.xxx.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::4d4:28ff:fe00:86e/64 scope link
       valid_lft forever preferred_lft forever

IPTables:

# Generated by iptables-save v1.6.0 on Tue Nov 29 20:18:46 2016
*nat
:PREROUTING ACCEPT [18637:1487446]
:INPUT ACCEPT [1420:143605]
:OUTPUT ACCEPT [3:228]
:POSTROUTING ACCEPT [8:496]
-A PREROUTING -p tcp -m tcp --dport 21 -j DNAT --to-destination xxx.xxx.xxx.147:30001
-A POSTROUTING -d xxx.xxx.xxx.147/32 -p tcp -m tcp --dport 30001 -j SNAT --to-source xxx.xxx.xxx.138
COMMIT
# Completed on Tue Nov 29 20:18:46 2016
# Generated by iptables-save v1.6.0 on Tue Nov 29 20:18:46 2016
*filter
:INPUT ACCEPT [16718:1768066]
:FORWARD ACCEPT [2016:3102889]
:OUTPUT ACCEPT [11789:4503936]
COMMIT

Dedi:

Result of ip route show

default via xxx.xxx.xxx.254 dev eth0 onlink
xxx.xxx.xxx.0/24 dev eth0  proto kernel  scope link  src xxx.xxx.xxx.147

Result of ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e0:cb:4e:8c:ab:5d brd ff:ff:ff:ff:ff:ff
    inet xxx.xxx.xxx.147/24 brd xxx.xxx.xxx.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:41d0:8:1a93::/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::e2cb:4eff:fe8c:ab5d/64 scope link
       valid_lft forever preferred_lft forever

IPTables:

*filter
:INPUT ACCEPT [31996807:9076994683]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [35073288:16420652529]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
COMMIT
09stephenb
  • 109
  • 4
  • 1
    it should be as simple as dropping the second rule, but you need to supply more informations: `ip route show` + `ip addr` (feel free to redact informations) on both systems and also `iptables-save`, because why would there be this rule here if there weren't also routing considerations? – A.B Nov 29 '16 at 18:32
  • @A.B Ive added some extra info (the output of those commands). – 09stephenb Nov 29 '16 at 19:02
  • I was asking for both the VPS and the dedicated behind, as well as the full iptables rules (iptables-save). But it's probably what is saying Florin Asăvoaie (can't know without the informations) – A.B Nov 29 '16 at 19:39
  • @A.B I've updated the post to include that. – 09stephenb Nov 29 '16 at 20:23
  • Hem you should also "redact" IPv6 addresses (or maybe you did I see ::/64 in the end...). To disable it *if you're not using it* `echo 1 > /proc/sys/net/ipv6/conf/eth0/disable_ipv6` – A.B Nov 29 '16 at 21:47

2 Answers2

0

The proxy needs to be the gateway for the proxied server if you want the proxied server to see the IPs.

Florin Asăvoaie
  • 6,932
  • 22
  • 35
0

Your Dedi has a default router xxx.xxx.xxx.254 that isn't the VPS, let's call it R

If you didn't use SNAT in the VPS (to have the real IP arrive to the Dedi), then here's what would happen when client C connect to FTP service on VPS IP:

C --> VPS --> Dedi
 ^            /
  \<-- R  <--/

Client C will initiate a connection to VPS, but the reply to the connection will come from an other IP C doesn't know about. Even if everything was sharing the same public IP (I don't know about this router R and how it relates to VPS), the port would still be wrong (30001 instead of 21). C will send a RST (reset) packet. Connection will never establish.

So as told before, the only way to have it work properly is to have VPS see the incoming as well as the outgoing flow between client C and Dedi. Currently it's implemented by presenting to each side its own IP, and the SNAT is needed on the Dedi side. If VPS was the default router of Dedi, then it wouldn't have to alter the client's IP to get the outgoing flow.

Now a few remarks:

  • there is no firewalling rule anywhere, everything is accepted by default. VPS forwards FTP only and nothing else so that's fine. If VPS were to be the default router, firewall rules should be added as well as NAT rules if Dedi isn't public, and default policy might have to be set to DROP
  • if you do such changes expect to lose network access to the Dedi. You'll need a direct console access provided by your hosting solution during those changes.
  • there's a lot of unknown. How many of these have public versus private IPs, in what way is VPS preventing DDoS on Dedi beside allowing only one service,...
A.B
  • 9,037
  • 2
  • 19
  • 37