[HOWTO] Tunnel DDoS protected OVH IP to VM's in other datacenter

jordynegen11

Hi,

If you have some VPS nodes and you like to make DDoS protection available for your VM's (kvm) then you are on the right page!

We are going to route DDoS protected IP's from OVH (or any other ISP). to our unprotected servers elsewhere, so you can use those IP addresses on your VM.

Things you need to know

• I use libvirt/kvm to virtualize
• I already setup a bridged network for my VM's and my VM's are trying to get a network via this bridge. (br0)
• I do not use any firewall
• Please update the linux kernel to the lastest one possible (Windows + GRE routing are not friends on lower kernels)
• Do NOT use the inbuild libvirt bridge option! But make an own bridge interface because the libvirt one is buggy!!!

First we have to create a GRE tunnel between the 2 servers (The OVH server and the VM host).
I use Centos 7 but you can do this on almost every linux OS.

Public IPv4 server 1: 185.113.88.21
Public IPv4 server 2: 93.95.39.20
IP block I want to use on server 2: 191.80.60.128/26
Bridge interface server2: br0

Run this on server 1:

ip tunnel add gre1 mode gre remote 93.95.39.20 local 185.113.88.21 ttl 255
ip link set gre1 up

Run this on server 2:

ip tunnel add gre1 mode gre remote 185.113.88.21 local 93.95.39.20 ttl 255
ip link set gre1 up

Then we need to create a route on server 1 that will route the IP traffic over the GRE tunnel

Run this on server 1:

ip route add 191.80.60.128/26 dev gre1

The next step is to route data from the GRE tunnel to the bridge and back.

Run this on server 2:

ip rule add from 191.80.60.128/26 table 666
ip route add default dev gre1 table 666
ip route add 191.80.60.128/26 dev br0 table 666

Last thing to do is to add the a IP the to bridge. This is gonna be the gateway for you VM's!
Use the second IP of the range!

Run this on server 2:

ip addr add 191.80.60.129/26 dev br0

You should be able to ping 191.80.60.129 now..

Use the following network config in the adapter of your VM:

IP address: 191.80.60.130
Mask: 255.255.255.192 (depends on the subnet)
Gateway: 191.80.60.129

Your VPS will have a working internet connection now! Hope this will help you out...

Special thanks to @malik for helping me with this!

Lutung

Thanks

love you bro

MrEd

Hi, just for your own safety, I hope these IPs are fake? You shouldn't use your production IPs for makeing examples

jordynegen11

@MrEd said:
Hi, just for your own safety, I hope these IPs are fake? You shouldn't use your production IPs for makeing examples

They are fake

ehab

nice, what about a permanent solution? if you reboot all the above is lost.

dahartigan

@ehab said:
nice, what about a permanent solution? if you reboot all the above is lost.

You should be able to use post-up and post-down in your etc network interfaces file to make it permanent

Tr33n

Keep in mind that GRE is not encrypted. I would just make a stretched lan with openvpn, then you do not need to mess around with custom gateways and IPs works on every server on the same network.

Actavus

Thank you very much @jordynegen11 for posting this.

QuantumCore

Thanks for the guide!

jordynegen11

@Tr33n said:
Keep in mind that GRE is not encrypted. I would just make a stretched lan with openvpn, then you do not need to mess around with custom gateways and IPs works on every server on the same network.

hmm mabe I take a look at that Thx! But for now I spend 4 days figure this out, so I gonna stick with this for a while xD

FHR

@Tr33n said:
Keep in mind that GRE is not encrypted.

You don't need encryption, you're tunelling public internet over the public internet

@ehab said:
nice, what about a permanent solution? if you reboot all the above is lost.

You can shove most of this stuff to ifcfg files (on RHEL).

Tr33n

FHR said: You don't need encryption, you're tunelling public internet over the public internet

I think that can not be generalized. There are certainly cases in which the traffic is sent unencrypted, because somebody would think, the traffic will stay just local.

As an example, if you have 2 servers, and both IPs are tunneled:
When Server A communicates with Server B, the traffic flows over the Internet. Without a tunnel, the traffic would only be within the data center (and depending on the topology, it would not even leave the same physical switch).

Of course, this depends very much on what is being done and for the private purpose, that would be no problem. But no hosting provider should come up with the idea of creating an unencrypted tunnel over the internet to provide clients with DDoS protected IPs and assume that the data remains private and there are no disadvantages in data security.

jordynegen11

@Tr33n said:

FHR said: You don't need encryption, you're tunelling public internet over the public internet

I think that can not be generalized. There are certainly cases in which the traffic is sent unencrypted, because somebody would think, the traffic will stay just local.

As an example, if you have 2 servers, and both IPs are tunneled:
When Server A communicates with Server B, the traffic flows over the Internet. Without a tunnel, the traffic would only be within the data center (and depending on the topology, it would not even leave the same physical switch).

Of course, this depends very much on what is being done and for the private purpose, that would be no problem. But no hosting provider should come up with the idea of creating an unencrypted tunnel over the internet to provide clients with DDoS protected IPs and assume that the data remains private and there are no disadvantages in data security.

If that's the case, why are so many (big) companies offering a ddos protected GRE tunnels? For example voxility and other big anti ddos providers. There are so many businesses protecting their offices like this.

So I don't think you're right. Also those ddos tunnels are ment for the public internet and not for internal ise.

jordynegen11

Please be sure that you check your MTU settings. For us, it gave problems with https.

Our perfect number was 1476. (max packet size + 28)

For Libvirt: You can simply add the option in the XML.

If you're running CentOS: You first have to update QEMU and Libvirt manual or this option isn't available.

FHR

@jordynegen11 said:
Please be sure that you check your MTU settings. For us, it gave problems with https.

Our perfect number was 1476.

For Libvirt: You can simply add the option in the XML.

If you're running CentOS: You first have to update QEMU and Libvirt manual or this option isn't available.

Just do MSS clamping on edges.

This "perfect number" can also be easily calculated, it's networking 101. Please don't blindly guess.

jordynegen11

@FHR said:

@jordynegen11 said:
Please be sure that you check your MTU settings. For us, it gave problems with https.

Our perfect number was 1476.

For Libvirt: You can simply add the option in the XML.

If you're running CentOS: You first have to update QEMU and Libvirt manual or this option isn't available.

Just do MSS clamping on edges.

This "perfect number" can also be easily calculated, it's networking 101. Please don't blindly guess.

That's correct. I believe it's the max packet size + 28.

FHR

@jordynegen11 said:

@FHR said:

@jordynegen11 said:
Please be sure that you check your MTU settings. For us, it gave problems with https.

Our perfect number was 1476.

For Libvirt: You can simply add the option in the XML.

If you're running CentOS: You first have to update QEMU and Libvirt manual or this option isn't available.

Just do MSS clamping on edges.

This "perfect number" can also be easily calculated, it's networking 101. Please don't blindly guess.

That's correct. I believe it's the max packet size + 28.

1500 is "standard Ethernet" MTU.
Subtract 20 bytes for IPv4 headers (or 40 bytes if GRE6), 4 bytes for GRE. 1476/1456 (GRE/GRE6) is resulting link MTU.

This can be verified by sending large ICMP ping packets with the "DON'T FRAGMENT" flag. "Packet too large" responses mean it couldn't fit.

To get TCP MSS, subtract another 20/40 bytes (v4/v6 headers) and another 20 bytes for TCP.

moderncloudhosting

OVH DDoS to filter traffic very logical. Thanks.

marvel

There's a guide on buyvm how to do this as well.

Also if you run an existing iptables config, connection tracking needs to be enabled or it won't work.

That's the downside when you run e.g. game servers on UDP like me, any DDoS will eat away the CPU because of the connection tracking.

jordynegen11

@marvel said:
There's a guide on buyvm how to do this as well.

Also if you run an existing iptables config, connection tracking needs to be enabled or it won't work.

That's the downside when you run e.g. game servers on UDP like me, any DDoS will eat away the CPU because of the connection tracking.

This is the BuyVM guide: https://wiki.buyvm.net/doku.php/gre_tunnel

But the BuyVM tut only works for 1 IPv4 and this tutorial will work for an entire IPv4 block.

BigBigWolf

Marked.

LayerVPS

Is there anyway to do this with a /32 ?

doghouch

@LayerVPS said:
Is there anyway to do this with a /32 ?

You mean a single address?

LayerVPS

@doghouch said:

@LayerVPS said:
Is there anyway to do this with a /32 ?

You mean a single address?

Yes

doghouch

@LayerVPS said:

@doghouch said:

@LayerVPS said:
Is there anyway to do this with a /32 ?

You mean a single address?

Yes

Any reason why LayerVPS.cc has a nulled installation of WHMCS?

cybertech

No.

LayerVPS

@doghouch said:

@LayerVPS said:

@doghouch said:

@LayerVPS said:
Is there anyway to do this with a /32 ?

You mean a single address?

Yes

Any reason why LayerVPS.cc has a nulled installation of WHMCS?

It's not nulled?

PieHasBeenEaten

@LayerVPS your whmcs is nulled and then you flag the post to say we are slandering you. What gives? The truth hurts dont it. Well have a nice day . I would personally ban you but this on @doghouch. I'm off to see the wizard.

LayerVPS

@PieHasBeenEaten said:
@LayerVPS your whmcs is nulled and then you flag the post to say we are slandering you. What gives? The truth hurts dont it. Well have a nice day . I would personally ban you but this on @doghouch. I'm off to see the wizard.

You did a License check during when there is a License issue.

And please go ahead and ban me, would never use a cracked billing software, is completely pointless. when I can buy a License.

teamacc

@layervps if everything is above board, you might wanna work with whmcs to get your license listed as valid in the license check utility.

The image you posted includes your whmcs license key, maybe not a good idea to post that in plain sight.

doghouch

@LayerVPS said:

@PieHasBeenEaten said:
@LayerVPS your whmcs is nulled and then you flag the post to say we are slandering you. What gives? The truth hurts dont it. Well have a nice day . I would personally ban you but this on @doghouch. I'm off to see the wizard.

You did a License check during when there is a License issue.

See — if you just said that there was an issue, I would’ve given you the benefit of the doubt. Unfortunately, you posted the following right after:

And please go ahead and ban me, would never use a cracked billing software, is completely pointless. when I can buy a License

As such, I’ve granted your request.