Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a server running several VMs via two bridges and want to secure the host via iptables.

So I have the defaults for IN/OUTPUT: drop and FORWARD: accept, and some IN/OUTPUT rules to allow me ssh access.

Now the Problem is with this setup that ssh-sessions are seemingly freezing when a command produces some lines of output. For example date works, but iptables -L or top will hang in the middle of their output. I can kill the session with ~., login again, set iptables back to default and everything works again.

Also after setting the iptables rules it takes a while before the problem arises. I haven't been able to determine the exact timeframe, has been between 5-20 minutes i think.

Any idea what could cause such a problem or how one would go about diagnosing it?

share|improve this question

migrated from Jan 22 '10 at 21:59

This question came from our site for computer enthusiasts and power users.

Whats with cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count? High number like 64k here? – Michuelnik Aug 21 '12 at 18:01

Try running iptables -L -n (add the -n option). Name resolution can cause iptables -L to hang.

share|improve this answer

Are you blocking ICMP completely? If so, you may have created a PMTU black hole.

share|improve this answer

Do you have a iptable rule to allow established traffic through?

iptables -A OUTPUT -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

I've also seen this issue due to a split horizon on the network but that doesn't sound like your issue due to the issue going away when you remove the iptable rules

share|improve this answer

This could be an MTU black-hole problem.

MTU is maximum transmission unit; how large a packet each side can handle. Ethernet defaults to 1500 bytes but that is by far not the only possibility.

short commands work because they're below both MTU sizes. Longer ones don't because they aren't.

If both ends of the connection are not using the same MTU, or if the network in the middle has a smaller MTU, your systems will need to figure this out somehow; the process is called Path MTU Discovery.

The way this happens is with ICMP messages. If you're blocking all ICMP, well, you're blocking useful stuff.

More info here: Why not block ICMP?

Also note that if the small-MTU network in the middle is layer 2 (e.g., the bridges you've configured), path MTU discovery won't work; the packets will just be dropped and show up as errors on the switch/bridge and/or on the ethernet interfaces.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.