Tag Info

Hot answers tagged

6

Going off your comment that it was the nf_conntrack full problem, you can either increase the conntrak table: sysctl -w net.netfilter.nf_conntrack_max=131072 Or if you are already behind a firewall you can just exempt HTTP traffic from connection tracking: # iptables -L -t raw Chain PREROUTING (policy ACCEPT) target prot opt source ...


4

ss and netstat show connections terminated at that host, i.e. either outgoing connections created by a process on the host, or incoming connections handled by a process on the host. (Technically these show you sockets.) conntrack shows connections known by the connection tracking system, which includes connections being routed by but not terminated by that ...


3

I think that sysctl parameter is for viewing only. You'll want to use the /sys/module/nf_conntrack/parameters/hashsize interface for runtime changes, and the hashsize module option to set it during initial module load. You'd want an entry in a /etc/modprobe.d/ file that looks something like this: options nf_conntrack hashsize=XXXXX


3

conntrack is an utility to see and modify the conntrack tables - but they are unrelated as far as dependencies go. The fact that you have conntrack tables (that's what you're seeing in /proc) doesn't imply you must have this utility: the tables are part of Linux itself, you could say, but the utility is just that - an utility - and indeed it's more likely ...


2

The conntrack tool won't return a flow because, by the time your ping command has ended the flow has been terminated. Create a persistent TCP connection to something on the Internet and do a conntrack -L and you'll see a flow. You could also send some ping requests to an Internet host that doesn't respond-- you'll see a flow created (waiting for the ICMP ...


2

Further to Andrew B's answer: For some reason, the RHEL documentation recommends putting an executable shell script with a name like nf_conntrack_hashsize.modules extension into /etc/sysconfig/modules instead. I have no idea why. Contents would look like: #!/bin/sh exec /sbin/modprobe nf_conntrack hashsize=262144


2

Do you have access to physical OpenVZ node? If yes, you should enable connection tracking using this command: vzctl set XXX --netfilter stateful --save And restart container: vzctl restart XXXX Where XXX is your container ID. If you don't have any access to physical server, you may send this command to your administrator or hosting provider because ...


2

To answer your question you can set net.netfilter.nf_conntrack_tcp_timeout_established in sysctl.conf The default is like 5 days, which can be dramatically lowered with out affecting any likely 443 traffic. net.ipv4.netfilter.ip_conntrack_max can also be bumped up.


2

I may have a clue. The timeout field from conntrack -L has several values that are in the 430,000 second range. This looks suspiciously close to the default value of nf_conntrack_tcp_timeout_established. I've tuned nf_conntrack_tcp_timeout_established down to 300, and all new entries in the table have a timeout value less than 300. This seems to suggest ...


2

Conntrack just enables you to view and manipulate the stateful data about connections. It doesn't manipulate the the TCP packets flowing as part of that ssh connection. If you want to break the ssh session, and you just delete that connection's state data, a new connection will begin being tracked. Just as when the ssh session was initially detected as a ...


2

You might be missing a module (I think is nf_conntrack) You should check if you have it on other machines and try to load it (modprobe). If it solves your problem, do not forget to add it to /etc/modules, so it will be loaded at next reboot. Hope it helps.


2

modprobe ip_conntrack lsmod |grep conn -- if you see entries it means modules have been loaded correctly sysctl -w -- to write the changes you made under /etc/sysctl.conf sysctl -p -- to view the changes and see if it was actually loaded. That is all you need


1

The solution is given here. I've got a similar task — to delete specific conntrack entries related to UDP connections going to specific Internet host and being SNAT'ed, so I created the following script: #!/bin/sh set -e -u HUB=AAA.BBB.CCC.DDD # target host's IP address value() { echo ${1#*=} } /usr/sbin/conntrack -L conntrack -p udp -d $HUB ...


1

You will be looking at the --hitcount switch. --hitcount [hits] match requiring a certain number of hits within a specific time frame. The maximum value for the hitcount parameter is given by the "ip_pkt_list_tot" You will also be interested in the --seconds switch. I believe a sample rule using port 80 and restricting connections to 50 ...


1

The bug you linked was closed as a duplicate of bug 552522. That bug then links to RHBA-2012:0255-1, which states the issue was fixed in iptables-1.3.5-9.1.el5. Unfortunately, you didn't tell us what version of iptables your system has installed, so you'll have to do the comparison yourself. Make sure you have actually installed this or a later version.


1

Depends on your priorities. It will make it better in the sense of that your machine doesn't die, because once the net.ipv4.netfilter.ip_conntrack_max is reached, the machine will simply stop accepting connections instead of getting overloaded. It will make it worse in the sense of that your machine stops accepting connections. On most of my own high ...


1

NAT'ing SIP+RTP is not an easy task. (doubly so when the source/dest IPs change) There is much more that needs to be tweaked than simply the source and destination address. In the actual SIP session itself, there are bits that also must be mangled (which is what the conntrack module does). SIP is used to negotiate the source and destination each peer ...


1

Matching ESTABLISHED packets would match all packets of a connection after handshake, right? Right ! Not sure what you mean by "capture". iptables is a thing, network packet capture (tcpdump) is another thing. Assuming that my understanding is "log only new connections", you will have to log only rules matching the NEW state. Let's use a sample ...


1

You can't do what you're looking for with stock iptables. You'd need to write some layer 7 inspection code. An alternative, if you're willing to put up with some post processing, would be to capture traffic with tcpdump into PCAP files, parse them for the packets you're looking for, and throw away the rest. I know that Wireshark's SSL dissector and a ...


1

You can achieve your goal using (abusing) iptables, to be more specific: connbytes match and NFQUEUE target. connbytes allows you to match the Nth packet in the connection and NFQUEUE is a mechanism for passing packets matching an iptables rule to userspace program. Furthermore: you'll have to use some program which whill be receiving relevant packets from ...


1

This is from experience - I haven't done research to verify this information: I have seen a few systems where this same error is in the system logs and there is nothing in /proc/sys/net/ipv4/ip_conn* or /proc/sys/net/ipv4/netfilter. I would also like to know why - but that dosn't remain very important once you find a fix for the original symptoms. ;) The ...


1

You are going right way. In modern kernels this parameter is called "nf_conntrack_max". Check Guntis's link at pc-freak.net , it would be useful for you.



Only top voted, non community-wiki answers of a minimum length are eligible