All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
GRE Help Please
I have a small dedi in the same Vegas DC as @Francisco (thanks @qps). My plan is to run cPanel/WHM on part of it, and use buyvm's ddos protection via GRE.
So I got OvZ running fine, created a container, gave it an IP, all is well. IP assigned to the VM (venet0:0) is (making this up) 141.211.164.7
I setup GRE per buyvm's doc: http://wiki.buyvm.net/doku.php/gre_tunnel
So there's a gre1 on the box with an IP of 192.168.168.2 and it can talk to 192.168.168.1, which is on a BuyVM VPS.
Now here's my Q: when I run the cPanel installer it's going to use the default route to connect to the Internet for licensing purposes, and hence discover 141.211.164.7. If I run
wget http://www.cpanel.net/showip.cgi -q -O -
Then I get 141.211.164.7. But I want it to be 209.141.38.x, which is my BuyVM filtered IP.
What I want is for my gre to be the default gateway...in other words, all traffic flows through that.
I tried this:
ip route del default
ip route add default dev gre1
But then networking stopped working altogether and I was sad.
I see the BuyVM doc discusses NATting but I'm not sure that would work...the OvZ container has a public IP and by default that's what it's going to use.
Comments
ip route add default dev gre1
You need to add a route to the /24 your gre tunnel connects to.
SOmeone perhaps make a nice little script or tutorial?
Didn't make a difference, though maybe I'm not understanding.
Here is what I'm doing...on the dedi:
("100 BUYVM" is already in /etc/iproute2/rt_tables)
At that point, I can ping 192.168.168.1 just fine. Routing table:
Now if I add 192.168.168.1 (the BuyVM IP) as a default route:
Networking stops working - in fact, can't ping 192.168.168.1 even.
Tried 192.168.168.2 as well but no difference.
Restarting the container and skipping the last two commands at the top ("ip rule add" and "ip route add") makes no difference. If I restore the original default device ("ip route del default && ip route add default dev venet0") then networking is fine though of course that's not GRE'd.
Just set up a GRE tunnel and confirm it is working, by pinging both sides, because as far as I understand even the GRE is not working properly?
I recommend not using an openvz VPS for this. Get a KVM instead. Actually i am not sure if this kind of routing can work on OpenVZ at all.
Just did it last night by the book and didn't have any trouble. I'd probably just start over.
So if I do this:
Then the GRE tunnel is working fine. I can ping 192.168.168.1 from .2, and .2 from .1
The problem is this:
This shows my dedi IP. I need it to show my BUYVM-filtered IP. In other words, I want all traffic to go through GRE.
On which side do you mean?
On BuyVM's side. Get a KVM VPS with several filtered IPs and use it to gre the filtered IPs to your own dedi.
But what setup would be different? Wouldn't I be using the same commands?
To be clear, this works fine when run on the OvZ on my dedicated server:
That shows my BuyVM filtered IP.
But without the --bind-address, I get my dedicated server's OvZ VPS's address:
This shows my dedicated server's OvZ VPS IP address.
Seems like all I need to do is change the default route inside my dedicated server's OvZ VPS - but I can't seem to figure out how to do that.
Find me on skype, same nick name, i will try to help you.
Hmmm that sounds promising. But alas...
Here is what I did on BuyVM side:
And then on the OvZ:
At that point, I could ping 192.168.168.1 and ping other internet hosts.
But then when I changed default route...it stopped working:
At that point I couldn't ping internet hosts, couldn't ping 192.168.168.1, etc.
Also tried "ip route add default via 192.168.168.1" instead with no change.
BTW, I don't have any GRE configuration on the host node. There is a gre0 device from the ip_gre modprobe but that's it.
OpenVZ containers don't have normal networking like a KVM or Xen VPS might.
I believe you need to go like this:
OVZ Container -> Host Node -> BuyVM
Not quite sure I follow.
So let's say I setup as this:
Host Node:
eth0 is an unrelated IP I don't want to mess with
eth0:0 is 141.211.164.7 - that's an available public IP
gre1 is 192.168.168.3
BuyVM:
gre1 is 192.168.168.1
I set that up and I can talk back and forth on 192.168.168.{1,3}
Now what IP do I assign to the OvZ VPS? I assigned 192.168.168.2/255.255.255.248
From the VM I can ping 192.168.168.1 and 192.168.168.3, but not the internet, so something is still not correct as far as routing.
Yes, that's the guide I linked in my original post.
So I did this:
But not:
iptables -A FORWARD -p tcp -d 192.168.168.3 --dport 25565 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
I was hoping to avoid having to create a bunch of rules for every port...and I'm not 100% sure this would work as cPanel refuses to run on non-public IPs. I'm pretty sure it would be grossly confused when it came to managing DNS.
Youch. Maybe this is not the best idea :-)
From what I understand you want all traffic to go through the tunnel, correct?
In this case, the key sentence in BuyVM's guide is: "While it would be possible to use a KVM based VPS with a purchased /29 allocation, this guide doesn't cover that."
That key sentence doesn't indicate that anything would be particularly different in the way it works, however. Would it be?
Moreover, it appears this will not work with cPanel/WHM regardless without a "rewrite the DNS zones every minute through cron" type of hack.
I guess if you get a /29 you can use the public IPs for the GRE tunnel, instead of private addresses and set it as main IP in cPanel?
btw can you try:
If you get a KVM I can static route your filtered IP, then you can bind it properly on the other end.
If you want to update DNS all the time then the nat option works.
What is cPanel binding to? It should be binding to the internal IP of the host node (192.168.168.x)
Right.
And cpanel would update all the DNS to the 192.x.x.x IP automatically. cPanel doesn't support any sort of NAT setup to allow for users to provide an 'external' IP automatically which is silly since it stops users from using large scale load balancers.
I can static route a single IP but you'd need to have a KVM to do it.
Francisco
@raindog308
Let's assume You have set up all needed routes for local interfaces.
Let's assume You have set up the default gateway route add default gw x.y.z.k
Check the configuration ip route show
If everything is okay then connect the GRE connection and after successful connection add:
route add 0.0.0.0/1 gw [greserverip]
route add 128.0.0.0/1 gw [greserverip]
It should work, it worked for me, and i found it in the openvpn client configuration too, it's either that or emptying the default gateway route, and adding only one route for the server and defining the rest statically after maintaining GRE connection which is not that efficient way.
I had written a script, but it wasn't that recent if i find it i'll send it.