9

Have a look at this diagram. The green boxes are for iptables, the blue are for ebtables (ignore those). So you see that the OUTPUT chain is only traversed for packets produced by local applications, while the POSTROUTING chain is traversed by all packets, including those routed from somewhere else. There are two subcases for network address translation (...


9

The mark is a 32 bits integer value attached to a network packet. Some network parts interacting with it (see below) can do bitwise operations on this value, it can then be interpreted between one single 32 bits value up to a collection of 32 flags, or a mix of flags and smaller values, depending on how one chooses to organise its use (tc can't do this). Of ...


8

UPDATE: iptables-nft (rather than iptables-legacy) is using the nftables kernel API and in addition a compatibility layer to reuse xtables kernel modules (those described in iptables-extensions) when there's no native nftables translation available. It should be treated as nftables in most regards, except for this question that it has fixed priorities like ...


7

You must be talking of (the former) project Application Layer Packet Classifier for Linux, which was implemented as patches, for the 2.4 and the 2.6 kernels. The major problem with this project, is that the technology which it proposed to control, quickly outpaced the usefulness and efficacy of the implementation. The members of the project, also had no ...


6

Use the following code: #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,13,0) nf_register_net_hook(&init_net, reg) #else nf_register_hook(reg) #endif Reference: init_net


6

The essential rules will depend on the network as a network might instead use SLAAC instead of DHCPv6, or there can be other complications depending on tunnels, ICMP handling, etc. -A INPUT -m conntrack --ctstate NEW -m udp -p udp --dport 546 -d fe80::/64 -j ACCEPT is suitable for a DHCPv6 client. DHCP clients should not accept server port 547 traffic as ...


6

Linux' bridge filter framework has available mechanisms where the layer 2 bridge code can do an upcall to iptables (as well as arptables or ip6tables) and have filtering travel from layer 2 (bridged frames) through layer 3 (iptables with packets) and then back to layer 2. This is much beyond the use the BROUTING chain which only gives the logical choice of ...


6

You're probably missing your table or chain. nft list ruleset will give you what you are working with. If it prints out nothing, you're missing both. nft add table ip filter # create table nft add chain ip filter INPUT { type filter hook input priority 0 \; } # create chain Then you should be able to add your rule to the chain. NOTE: If you're logged in ...


5

If you want a filter to capture on packets mathing 130.190.0.0/17: tcpdump net 130.190.0.0/17


5

I think I finally understood how redirecting ingress to IFB is working: +-------+ +------+ +------+ |ingress| |egress| +---------+ |egress| |qdisc +--->qdisc +--->netfilter+--->qdisc | |eth1 | |ifb1 | +---------+ |eth1 | +-------+ +------+ +------+ My initial assumption in figure 2, that the ifb ...


5

I'm pretty sure anything coming from the local machine never goes through the PREROUTING table, as seen in this awesome ASCII figure.


5

There is a comment module for iptables which should do what you need. When adding a rule, one can add a comment like this: iptables -A INPUT -p icmp -j ACCEPT -m comment --comment "Allow incoming ICMP"


5

You're probably adding a rule intended for the nat table in the filter table block suitable for iptables-restore, and with inappropriate syntax. Until you know how to edit /etc/iptables/rules.v4 directly (by studying the output of iptables-save), you should do this instead: be careful, since the rule will be applied immediately, change the current running ...


4

yep, man page debian; [!] -o, --out-interface name Name of an interface via which a packet is going to be sent (for packets entering the FORWARD, OUTPUT and POSTROUTING chains). When the "!" argument is used before the interface name, the sense is inverted. If the interface name ends in a "+", then any interface which begins with ...


4

Usually the main criterion for SNAT is "traffic that's going out a given interface" (i.e. -o eth0). What interface a packet will go out is determined by routing, so to apply that criterion you need to run it in a POSTROUTING context. DNAT rewrites the destination address of a packet, meaning it can affect where a packet goes to — for example, a packet that ...


4

I get the same on Ubuntu 16.04. I don't have a fix, but I have some insight in to why this is happening. During the book process, the system initially boots on a RAM-based file system: initramfs. Later in the boot process, the hard disk takes over, but the modules directory from the initramfs is mounted on the modules directory of the hard disk. Note that ...


4

Yes, the string extension is still supported (see also your local man iptables-extensions documentation). No, you can’t match against encrypted payloads — they’re still encrypted in the filtering layer...


4

Given the comments, you appear to realize that netfilter is the wrong tool for the job, so I won't reiterate that here. What's actually going on here? Google Chrome isn't using the TLS Server Name Indication (SNI) extension, so none of the packets it's sending are being matched by the rules you specified since they don't contain the name of the destination ...


4

What xx-tables is the best to filter (limit, not drop) ARP packets? iptables iptables starts from IP layer: it's already too late to handle ARP. arptables While specialized in ARP, arptables lacks the necessary matches and/or targets to limit rather than just drop ARP packets. It can't be used for your purpose. ebtables ebtables can be a candidate (it ...


3

I already answered it at superuser.com Basically newer kernels ( >= 4.7 ) are deprecating the automatic helper module's port assignment in favor of explicit rules. Short fix to get the old behaviour: echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper Better long term fix (requiring more work but giving better control): See the CT target ...


3

Following are some ways to extract established connection information: cat /proc/net/ip_conntrack -> using proc filesystem conntrack -L -> command line interface for netfilter connection tracking. You can yum install it. Another way is to write an iptable rule to LOG messages (use -j LOG) after your marking rule. Since marking rule is non terminating LOG ...


3

This is something that iptables handles just fine with a "recent" kernel (anything since 2.4, that's older than 10 years). The trick is to do a "reverse natting": map the IP address of any host from your local net that is accessing the two NATted servers to the public IP of your gateway. Something like the following (that's only that NATting rules, no ...


3

Your ipset consist of IP and ports, so you need to tell iptables match for both IP and port. If you want to match with destination port use dst, otherwise use src. -A INPUT -m set --match-set public_services dst,dst -j ACCEPT


3

Let's say we have an ipset named MYTESTSET, and that this ipset is of type hash:ip. It will store just ip adresses. Then match against your IPset and after match against connlimit match extension, with the parameters you want. iptables -A INPUT -p tcp -m set --match-set MYTESTSET src -m connlimit --connlimit-above 1 --...


3

I found the reason why this is not working. You cannot rely on having the entire HTTP request on a single packet being inspected by netfilter. The same packet will not match 'GET /' and 'Host:*' since that payload is spread through several packets. Consider the following list of rules: -A OUTPUT -p tcp -m tcp --dport 80 -j URLFILTER # would be FORWARD in ...


3

For the sake of telling it's possible (but probably not that useful), yes it's possible, using a recent enough nftables and a raw payload expression. So for the inet (dual ip/ip6) table, you have to first filter the right level 4 protocol (here TCP=6 and UDP=17) using a set, then filter the port 53. That's handy, TCP and UDP have the same location for the ...


3

I looked for examples in ufw, the firewall created by Ubuntu. It seems that once you've allowed both ICMP and DHCP, there's not much else left to worry about. https://git.launchpad.net/ufw/tree/conf/before6.rules?id=release/0.35 As thrig points out, it seems that there's a lot of different ICMP codes to look at. Your current rules avoid doing so by ...


3

This will popably not work. The Firewall surely will track the TCP setup packets (SYN,SYN-ACK,ACK) needed for a correct TCP Connection, which are missing if you just use altered UDP Packets. What you could do is: Write a small Application which picks up UDP on the one side, connects to the other side via TCP, and another application which accepts the ...


3

I doubt iptables alone will be enough, as TCP and UDP are fundamentally different protocols. You can forget setting up an IPsec VPN with such scenario (ISP blocking all UDP ports). Tunnel all the traffic via ICMP. (best old school solution I know of. Lots of organizations still do not filter out any kind of ICMP) see https://github.com/DhavalKapil/icmptunnel ...


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