VPS ip address blocked

Question

I have a Debian based VPS which runned fine until recently. Yesterday, i was working at programming websites when the server just didnt respond anymore. I have done some research and to be short, right now it does respond when I access it with the ipv6 address but not when I access with the ipv4 address. When I pingtrace the address, I don't get response after the server of the hosting company. I suspected that my firewall could've caused the problem so I flushed the IPtables. That wasn't the solution. I contacted the hosting company and they said that they don't give technical support because it's a self-managed VPS. I hope the issue will not be at their server.

Can someone think of something I didn't see?

Update ifconfig has the ipv4 address and the ipv6 address in eht0 so that should be okay. And I'm able to connect to ipv6. When I stop iptables, I still cannot ping. I have CSF running in Webmin. When I do service csf stop and service lfd stop, my iptables -L is:

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination

    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination

    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination

Also, when I ping to google.com from my vps, I get

unknown host www.google.com

update 2 I just discovered Bcast and Default gw is different. (Still learning... ) route -n results in:

    [ipaddress]     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Should that be different? How can I discover what I need?

Could u stop iptables and see? If your default input filter is drop all then flush will not help Do attach iptables -L output so that community can be helpful to you — kalyan, Jan 15 '17 at 08:37

Jay M · Accepted Answer · 2017-01-17T17:34:12.543

If your VPS has a management console,. it may have a means to perform a console login over the web. Or, as you say IPV6 works, perform a console login over IPV6.

Treat this as a generic network setup test guide.

Once you have a console login:

Verify the IPV4 interface is up and has the correct address - information on correct network setup should have been given on opening the VPS account. (ifconfig command)
Verify that your IPV4 routing table is intact in that it has a correct default route. (route command)
Ping the address of the default route. (ping )
Ping a global IPV4 address (ping www.google.com)

A. If (3) works but not (4), the issue is with your VPS providers' network. Give them the above info. If they don't or won't answer, change suppliers - I can recommend Afterburst as they are very good at answering queries and are low cost.

B. If (3) does not work look at your firewall (disable it temporarily). Also check default route with the VPS provider. If disabling the firewall makes it works, then that is your issue.

C. If (4) works then the problem is not with your VPS but your local network - there's your issue.

Example commands

user@srv0:~$ sudo ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:3c:a8:3f:bd
          inet addr:55.135.9.135  Bcast:55.135.9.191  Mask:255.255.255.192
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:63541656 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54202238 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:28787095338 (28.7 GB)  TX bytes:144380431303 (144.3 GB)

user@srv0:~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         55.135.9.129    0.0.0.0         UG    0      0        0 eth0
55.135.9.128    0.0.0.0         255.255.255.192 U     0      0        0 eth0

This tells us:
- eth0 IPV4 is globally routable (it's not an RFC1918 address)
- eth0 IPV4 address is 55.135.9.135 with a 26 bit subnet mask (255.255.255.192)
- eth0 broadcast address is 55.135.9.191
- The default gateway is 55.135.9.129, this is where we send anything not covered by any other route.

We logically AND the known device IPs with the subnet mask we see that it's on the same subnet as us, e.g.

055.135.009.135  (eth0 address)
255.255.255.192  (subnet mask)
----------------AND
055.135.009.128

055.135.009.129  (gw address)
255.255.255.192  (subnet mask)
----------------AND
055.135.009.128

As the result is the same we should be able to get to it directly as the default gateway is normally directly accessible on the local subnet.

So, if we ping the gatway we should see it.

user@srv0:~$ sudo ping 55.135.9.135
PING 55.135.9.135 (55.135.9.135) 56(84) bytes of data.
64 bytes from 55.135.9.135: icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from 55.135.9.135: icmp_seq=2 ttl=64 time=0.026 ms
64 bytes from 55.135.9.135: icmp_seq=3 ttl=64 time=0.026 ms
^C
--- 55.135.9.135 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.024/0.028/0.036/0.004 ms

If this works we should see the hardware address of our gateway in the arp list

user@srv0:~$ sudo arp -a
? (55.135.9.129) at 00:21:59:cd:6a:48 [ether] on eth0

If all is good, then ignoring any firewall issues we should be able to contact external hosts. Any failure to do this must be caused by the default gateway and/or the upsream network from the default gateway.

As you can see in my updated question, I really dont know what the solution might be. Like you suggested, I am considering moving to another host. But moving all domain names will not be great... :) — Hendrik Hamming, Jan 16 '17 at 12:26
Did you try all the steps? also cat /etc/resolv.conf, that should show your DNS server. Ping the address of the DNS, though DNS does not need to work for ping to work. — Jay M, Jan 16 '17 at 13:46
Thank you for your reply. Is Bcast the same as default route? ping -b [ipaddress] says 15packets transmitted, 100% packet loss. Nameserver ping: network is unreachable. Tried both actions again with firewall down, same results. I added 8.8.8.8 as nameserver and pinged to google, still same result as mentioned in the updated message. — Hendrik Hamming, Jan 16 '17 at 14:15
No. Bcast is broadcast. It's an address shared all the devices on the same subnet. The default route tells the routing system what do do with packets that are not covered by any other route. Follow the example and update your question with results. I'll update answer with exact commands and example results. — Jay M, Jan 17 '17 at 16:56
With some help from you and some others I managed to resolve the problem. If I did route -n, there was one line, in your example it would be `55.135.9.128 0.0.0.0 255.255.255.192 U 0 0 0 eth0. ` I checked the info of nano /etc/network/interfaces and there was actually a gateway. And the first line of `auto eth0` was `iface eth0 inet static`. I changed that to iface `eth0 inet dhcp` and commented `address`, `netmask` and `gateway`. That was the solution. Right now I cannot add an answer to this post but thank your very much for your help, I appreciate it! — Hendrik Hamming, Jan 19 '17 at 14:47

VPS ip address blocked

1 Answers1