<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Hard lockup when inserting nft rules (esp. ct rule)"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1082">1082</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Hard lockup when inserting nft rules (esp. ct rule)
</td>
</tr>
<tr>
<th>Product</th>
<td>nftables
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86_64
</td>
</tr>
<tr>
<th>OS</th>
<td>Debian GNU/Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>blocker
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>kernel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>pablo@netfilter.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>larkwang@gmail.com
</td>
</tr></table>
<p>
<div>
<pre>We are switching from openvpn to strongswan (ipsec) for our branch offices to
headquarter VPN link.
We use nftables for better performance and clean ruleset. The ruleset is
-----snip-----
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
set allowed_addr {
type ipv4_addr
elements = { <about 40+ IPs> }
}
set allowed_port {
type inet_service
elements = { 80,443,<other about 10 ports> }
}
chain forward {
type filter hook forward priority 0;
ip saddr { 10.xx.210.0-10.xx.217.255, 10.xx.0.12 } ip daddr
10.xx.0.0/16 counter accept
ip saddr 10.xx.0.0/16 ip daddr @allowed_addr tcp dport
@allowed_port counter accept
ip saddr 10.xx.0.0/16 ip daddr { 10.xx.254.0/24, 10.xx.yy.zz }
counter accept
ip saddr 10.xx.0.0/16 ip daddr 10.0.0.0/8 ip protocol tcp ct
state invalid,new counter reject
}
}
-----snip-----
The vpn server (debian jessie with bpo) uses these:
linux-image 4.6.4-1~bpo8+1 (also 4.5.5-1)
nftables 0.6-1~bpo8+1
libnftnl4 1.0.6-1~bpo8+1
libmnl0 1.0.3-5
The ruleset is loaded without problem before we begin to transit vpn links.
After we transit all links, we want to update the ruleset to add a new open IP.
But loading the modified ruleset causes this machine hard lockup immediately.
Then we had to revert the high load vpn link to openvpn server. With remaining
vpn links, we can reproduce hard lockup 100%.
After quick pinpoints, we are sure:
1. The unmodified ruleset can cause lockup too
2. The lockup is caused by the last "ct state" rule (if commented, no lockup)
We move most of vpn links to a backup server after work time, which has the
same hardware and software. Loading ruleset in this backup server doesn't cause
hard lockup. Loading ruleset in the aforementioned now unloaded server doesn't
cause hard lockup, either.
We are sure:
3. Certain traffic load is a factor for the hard lockup
Please look into this issue.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>