1

I have a VPS with Ubuntu 16.0.4 installed on it. Every time I connected to it through SSH, the next times I attempted to connect would end up in time out errors along with any other kind of connection attempts (http, git, ping, port 8080).

I figured this means that the IP gets blocked. But couldn't find any signs of it on the system. Even stopped the whole "ufw" to no effect.

Eventually I referred to system logs and ran tcpdump as follows:

tcpdump -i ens3 icmp and icmp[icmptype]=icmpecho

Then tried pinging from a blocked IP, but nothing showed up. Note that I could see some regular pings from my VPS provider servers and also when I pinged from a not blocked device, it would appear.

Does this mean that the problem exists outside of the VPS I have acquired? Or is there any other place on it I could look up for possible blocking happening?

The Ubuntu installation is almost raw and no other firewall is installed on it as much as I checked except for the 'ufw'.

3
  • Is fail2ban installed? – Panki Aug 29 '19 at 7:42
  • @Panki no it's not. I actually looked up a list of known firewalls for Ubuntu. And checked them all to make sure none is installed. – Yashar PourMohammad Aug 29 '19 at 8:49
  • Does your hosting provider implement this? Check their FAQ – Panki Aug 29 '19 at 9:48
1

tcpdump does see packets before they reach the local port filtering. If you see an incoming packet in tcpdump but it doesn't reach an application that you're sure is listening to it, it means the packet is being dropped or modified by the firewall. But if you don't see the incoming packet with tcpdump at all, it means the packet was dropped before it reaches your machine.


Here's a bit more information about Linux firewalling which won't help you here, but which would help to investigate if the packets were dropped on your machine.

Ufw is one firewall manipulation tool. The firewall mechanism is netfilter. You can list netfilter rules with the iptables command. The complete mechanism involves many parts, but to investigate port blocking, you only need to look at the INPUT chain:

iptables -nvxL INPUT

Each line represents one rule, and the rules are executed in order until once takes a decision on the packet (such as ACCEPT or DROP it). Chains can involve other chains as “subroutines”. If no rule take a decision, the chain's policy applies. iptables -nvxL with no arguments lists all the chains. There's a packet count next to each rule, and if you're sending a packet and wondering where it gets lost, checking the counter values before and after is often a cheap way of finding out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.