Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
On 10/02/2015 01:07 PM, Pablo Neira Ayuso wrote: > On Thu, Oct 01, 2015 at 11:07:30PM +0200, Daniel Mack wrote: > [...] >> That, however, got rejected because it doesn't work for multicast. This >> patch set implements one of the things Pablo suggested in his reply. > > People are rising valid concerns here, so far we got a RFC where you > say that you don't have a proper setup to validate performance impact. > > From the locking front, you indicated that there are possible problems > in this RFC, although you claim those can be fixed. > > No examples on how you will use this are shown, which has triggered > questions on how you plan to use this. Only one use-case that has been > described in natural language. > > Rergading inconsistent behaviour when no process are listening, your > argument is that "that can be documented". > > Frankly, I would expect you do the work from your side to justify the > inclusion of this, and that requires that your cover open fronts from > the technical side, not just arguing. Sure, I'm willing to do this of course. The purpose of this RFC was only to outline where this approach would go, and to allow discussions about possible show stoppers. I'll respin this in a new series then. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
On Thu, Oct 01, 2015 at 11:07:30PM +0200, Daniel Mack wrote: [...] > That, however, got rejected because it doesn't work for multicast. This > patch set implements one of the things Pablo suggested in his reply. People are rising valid concerns here, so far we got a RFC where you say that you don't have a proper setup to validate performance impact. >From the locking front, you indicated that there are possible problems in this RFC, although you claim those can be fixed. No examples on how you will use this are shown, which has triggered questions on how you plan to use this. Only one use-case that has been described in natural language. Rergading inconsistent behaviour when no process are listening, your argument is that "that can be documented". Frankly, I would expect you do the work from your side to justify the inclusion of this, and that requires that your cover open fronts from the technical side, not just arguing. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
On Thu, Oct 01, 2015 at 11:07:30PM +0200, Daniel Mack wrote:
> On 10/01/2015 07:13 PM, Marcelo Ricardo Leitner wrote:
> > On Wed, Sep 30, 2015 at 09:24:21AM +0200, Daniel Mack wrote:
> >> On 09/29/2015 11:19 PM, Florian Westphal wrote:
> >>> Daniel Mack wrote:
> Add a new chain type NF_INET_LOCAL_SOCKET_IN which is ran after the
> input demux is complete and the final destination socket (if any)
> has been determined.
>
> This helps filtering packets based on information stored in the
> destination socket, such as cgroup controller supplied net class IDs.
> >>>
> >>> This still seems like the 'x y' problem ("want to do X, think Y is
> >>> correct solution; ask about Y, but thats a strange thing to do").
> >>>
> >>> There is nothing that this offers over INPUT *except* that sk is
> >>> available. But there is zero benefit as far as I am concerned --
> >>> why would you want to do any meaningful filtering based on the sk at
> >>> that point...?
> >>
> >> Well, INPUT and SOCKET_INPUT are just two different tools that help
> >> solve different classes of problems. INPUT is for filtering all local
> >> traffic while SOCKET_INPUT is just for such that actually has a
> >> listener, and they both make sense in different scenarios.
> >
> > How is it better than -m socket ? It's used with tproxy, but not only,
> > and works quite well, thought it only supports TCP and UDP.
>
> Yes, but not multicast.
Right
> > Something like
> > iptables -N INPUT_SOCKET
> > iptables -I INPUT -m socket -j INPUT_SOCKET
> > would achieve similar results, if I got you right.
> >
> > -m socket implies in a double-lookup for the socket, yes, but that
> > sounds a reasonable price to pay for this while not inserting another
> > hook. I know of deployments using -m socket for tproxy and handling very
> > high rates, performance has not been a problem..
>
> I know, and my primary attempt to get this fixed was to factor out the
> early demux code from the socket matching code and make it available to
> the cgroup matcher as well:
>
>
> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/58054
>
> That, however, got rejected because it doesn't work for multicast. This
> patch set implements one of the things Pablo suggested in his reply.
Ok, thanks for the info. Makes sense, hmm.
Marcelo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
On 10/01/2015 07:13 PM, Marcelo Ricardo Leitner wrote:
> On Wed, Sep 30, 2015 at 09:24:21AM +0200, Daniel Mack wrote:
>> On 09/29/2015 11:19 PM, Florian Westphal wrote:
>>> Daniel Mack wrote:
Add a new chain type NF_INET_LOCAL_SOCKET_IN which is ran after the
input demux is complete and the final destination socket (if any)
has been determined.
This helps filtering packets based on information stored in the
destination socket, such as cgroup controller supplied net class IDs.
>>>
>>> This still seems like the 'x y' problem ("want to do X, think Y is
>>> correct solution; ask about Y, but thats a strange thing to do").
>>>
>>> There is nothing that this offers over INPUT *except* that sk is
>>> available. But there is zero benefit as far as I am concerned --
>>> why would you want to do any meaningful filtering based on the sk at
>>> that point...?
>>
>> Well, INPUT and SOCKET_INPUT are just two different tools that help
>> solve different classes of problems. INPUT is for filtering all local
>> traffic while SOCKET_INPUT is just for such that actually has a
>> listener, and they both make sense in different scenarios.
>
> How is it better than -m socket ? It's used with tproxy, but not only,
> and works quite well, thought it only supports TCP and UDP.
Yes, but not multicast.
> Something like
> iptables -N INPUT_SOCKET
> iptables -I INPUT -m socket -j INPUT_SOCKET
> would achieve similar results, if I got you right.
>
> -m socket implies in a double-lookup for the socket, yes, but that
> sounds a reasonable price to pay for this while not inserting another
> hook. I know of deployments using -m socket for tproxy and handling very
> high rates, performance has not been a problem..
I know, and my primary attempt to get this fixed was to factor out the
early demux code from the socket matching code and make it available to
the cgroup matcher as well:
http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/58054
That, however, got rejected because it doesn't work for multicast. This
patch set implements one of the things Pablo suggested in his reply.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
On Wed, Sep 30, 2015 at 09:24:21AM +0200, Daniel Mack wrote:
> On 09/29/2015 11:19 PM, Florian Westphal wrote:
> > Daniel Mack wrote:
> >> Add a new chain type NF_INET_LOCAL_SOCKET_IN which is ran after the
> >> input demux is complete and the final destination socket (if any)
> >> has been determined.
> >>
> >> This helps filtering packets based on information stored in the
> >> destination socket, such as cgroup controller supplied net class IDs.
> >
> > This still seems like the 'x y' problem ("want to do X, think Y is
> > correct solution; ask about Y, but thats a strange thing to do").
> >
> > There is nothing that this offers over INPUT *except* that sk is
> > available. But there is zero benefit as far as I am concerned --
> > why would you want to do any meaningful filtering based on the sk at
> > that point...?
>
> Well, INPUT and SOCKET_INPUT are just two different tools that help
> solve different classes of problems. INPUT is for filtering all local
> traffic while SOCKET_INPUT is just for such that actually has a
> listener, and they both make sense in different scenarios.
How is it better than -m socket ? It's used with tproxy, but not only,
and works quite well, thought it only supports TCP and UDP.
Something like
iptables -N INPUT_SOCKET
iptables -I INPUT -m socket -j INPUT_SOCKET
would achieve similar results, if I got you right.
-m socket implies in a double-lookup for the socket, yes, but that
sounds a reasonable price to pay for this while not inserting another
hook. I know of deployments using -m socket for tproxy and handling very
high rates, performance has not been a problem..
> > Drop? Makes no sense, else application would not be running in the first
> > place.
>
> Of course you can drop certain packets at this point, depending on other
> details. Say, for instance, you want to match all packets that are
> received by a certain task and that are originated from IP addresses of
> a specific subnet, and drop the rest. Rather than adding matches to your
> global firewall configuration for all the ports that tasks may or may
> not listen on, you can just do it on a higher level, from the
> perspective of an administrator. If you decide to let your web server
> listen on another port as well, no firewall rule configuration change is
> needed at all.
>
> Another use case is accounting. If you want to know how much traffic a
> certain service or application in your system has caused, you don't want
> to match all its ports to firewall rules just in order to get that
> information. Instead, you can now derive that information on a
> per-application base. With this patch set, this even works just fine for
> multicast listeners, which is something that is currently impossible to
> achieve otherwise.
Sounds like you want a boosted socket match, perhaps borrowing some of
the features from owner match.
Marcelo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
Hi Florian, On 09/30/2015 11:48 PM, Florian Westphal wrote: > Daniel Mack wrote: >> Of course you can drop certain packets at this point, depending on other >> details. Say, for instance, you want to match all packets that are >> received by a certain task and that are originated from IP addresses of >> a specific subnet, and drop the rest. Rather than adding matches to your >> global firewall configuration for all the ports that tasks may or may >> not listen on, you can just do it on a higher level, from the >> perspective of an administrator. If you decide to let your web server >> listen on another port as well, no firewall rule configuration change is >> needed at all. > > We don't have per application configurations, not even with these > patches...? > The configuration is still global/per netns? The configuration is per net_cls ID, and with a cgroup manager that assigns unique IDs to each application/service/task, this effectively becomes a per-application setting (or anything else for that matter, see below). > Application level firewall makes me think of proxies. > What exactly are we talking about? > Can you provide examples? Ok, so the term is misleading, I agree. I am talking about a possibility for userspace to install netfilter rules that match packets sent to or sent by a task, or a set of tasks (you may call that an application or service). So for example, I want a way to redirect netfilter decisions that are about tasks in net_cls cgroup 23 to a dedicated chain, so the admin can configure rules that only apply to a certain service or application. >> I really don't know if this approach is intrusive enough to make it >> qualify as sledgehammer. I'd like to see some real-world benchmarks and >> have proof there is a performance decrease for setups that don't use >> such chains. > > We have static keys for nf hooks so there is no performance decrease if > no netfilter hooks are active. > > HOWEVER, this discussion seems to hint at the opposite, namely that this > will turn into a mandatory or at least auto-enabled feature. > > But regardless, I called it a sledgehammer not because of performance > concerns but because just to get this proposed socket matching facility we > now have to put hooks into all protocol handlers and commit to keeping them > there forever. Sure, but why is that a problem exactly? I still don't understand your technical concerns. > Also, some time ago Eric suggested to allow binding to tcp ports > from packet sockets to implement userspace-driven TCP stacks (i.e. > kernel would just queue raw frames for the given quadruple withput > caring about ordering etc). > > If we allow this proposed change, we'd also have to extend that > with these hooks. In that case, the receiver socket would be the one of that userspace-driven TCP stack, and the same rules apply. The feature might not make much sense in such setups though, but that's not an issue. > Next time someone mentions that we don't have application matching > but only sk/cgroup tests. Are we then going to consider doing task lookups? cgroups are the most comprehensive notion the kernel has about a group of tasks, which may be called a service or an application. By allowing users to make netfilter rules specific to a setting in a cgroup controller, we open the doors for supporting a lot of interesting use cases. Which tasks to put into a cgroup with a certain net_cls setting is up to userspace, but it would be possible to group everything the OS considers an 'application'. >> Why so? For deterministic ingress filtering of traffic directed to a >> local socket, you can as well rely on information associated with that >> socket. And this is what application-level firewall rule sets are all about. > > Application not running -> different behaviour. I'm sure thats obvious > to you, but I'm not sure if its obvious to users that their > 'match on net clsid 42' won't work anymore when that service isn't running. That's a matter of explaining that fact in the documentation, I'd say :) In a sense, what happens is comparable to rules that are specific to an ingress interface. Depending on whether that interface is up or down, these netfilter rules are iterated or they aren't, right? Anyway, note that socket uid/gid and cgroup matches already exist for ingress today, so the exact same change in behavior that you describe is in place since a number of releases. It's just that right now, what the kernel does is to only match packets that had early demux treatment, which makes it largely unusable for users. So, what this patch set aims for is to make an existing feature actually usable. I'm open to other approaches, as long as it allows us to install netfilter rules that match against net_cls IDs. The demux target would probably be another option, but I'm not convinced yet that would be any better from a technical perspective. Pablo, what do you think? Thanks, Daniel -- To unsubscribe from this list:
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
Daniel Mack wrote: > Of course you can drop certain packets at this point, depending on other > details. Say, for instance, you want to match all packets that are > received by a certain task and that are originated from IP addresses of > a specific subnet, and drop the rest. Rather than adding matches to your > global firewall configuration for all the ports that tasks may or may > not listen on, you can just do it on a higher level, from the > perspective of an administrator. If you decide to let your web server > listen on another port as well, no firewall rule configuration change is > needed at all. We don't have per application configurations, not even with these patches...? The configuration is still global/per netns? > Another use case is accounting. If you want to know how much traffic a > certain service or application in your system has caused, you don't want > to match all its ports to firewall rules just in order to get that > information. Instead, you can now derive that information on a > per-application base. With this patch set, this even works just fine for > multicast listeners, which is something that is currently impossible to > achieve otherwise. > > So the only 'benefit' is that netcls id is available; but > > a) why is that even needed and > > It's currently the only way of realizing application-level firewalls, > and it'd be an awesome feature if it actually worked. Application level firewall makes me think of proxies. What exactly are we talking about? Can you provide examples? > > b) is such a huge sledgehammer just for net cgroup accounting > > worth it? > > I really don't know if this approach is intrusive enough to make it > qualify as sledgehammer. I'd like to see some real-world benchmarks and > have proof there is a performance decrease for setups that don't use > such chains. We have static keys for nf hooks so there is no performance decrease if no netfilter hooks are active. HOWEVER, this discussion seems to hint at the opposite, namely that this will turn into a mandatory or at least auto-enabled feature. But regardless, I called it a sledgehammer not because of performance concerns but because just to get this proposed socket matching facility we now have to put hooks into all protocol handlers and commit to keeping them there forever. Also, some time ago Eric suggested to allow binding to tcp ports from packet sockets to implement userspace-driven TCP stacks (i.e. kernel would just queue raw frames for the given quadruple withput caring about ordering etc). If we allow this proposed change, we'd also have to extend that with these hooks. Next time someone mentions that we don't have application matching but only sk/cgroup tests. Are we then going to consider doing task lookups? > > For deterministic ingress filtering you can only rely on what > > is contained in the packet. > > Why so? For deterministic ingress filtering of traffic directed to a > local socket, you can as well rely on information associated with that > socket. And this is what application-level firewall rule sets are all about. Application not running -> different behaviour. I'm sure thats obvious to you, but I'm not sure if its obvious to users that their 'match on net clsid 42' won't work anymore when that service isn't running. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
On 09/30/2015 09:40 AM, Jan Engelhardt wrote: > > On Wednesday 2015-09-30 09:24, Daniel Mack wrote: >> >>> Drop? Makes no sense, else application would not be running in the first >>> place. >> >> Of course you can drop certain packets at this point, depending on other >> details. Say, for instance, you want to match all packets that are >> received by a certain task [...] >> Another use case is accounting. If you want to know how much traffic a >> certain service or application in your system has caused > > But the sk info would be available in INPUT already, would it not? No, only for established connections, as those are subject to early demux which sets skb->sk. For all other packets, netfilter callbacks are called with skb->sk == NULL. That's the whole point of this patch set ;) Daniel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
On Wednesday 2015-09-30 09:24, Daniel Mack wrote: > >> Drop? Makes no sense, else application would not be running in the first >> place. > >Of course you can drop certain packets at this point, depending on other >details. Say, for instance, you want to match all packets that are >received by a certain task [...] >Another use case is accounting. If you want to know how much traffic a >certain service or application in your system has caused But the sk info would be available in INPUT already, would it not? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
On 09/29/2015 11:19 PM, Florian Westphal wrote:
> Daniel Mack wrote:
>> Add a new chain type NF_INET_LOCAL_SOCKET_IN which is ran after the
>> input demux is complete and the final destination socket (if any)
>> has been determined.
>>
>> This helps filtering packets based on information stored in the
>> destination socket, such as cgroup controller supplied net class IDs.
>
> This still seems like the 'x y' problem ("want to do X, think Y is
> correct solution; ask about Y, but thats a strange thing to do").
>
> There is nothing that this offers over INPUT *except* that sk is
> available. But there is zero benefit as far as I am concerned --
> why would you want to do any meaningful filtering based on the sk at
> that point...?
Well, INPUT and SOCKET_INPUT are just two different tools that help
solve different classes of problems. INPUT is for filtering all local
traffic while SOCKET_INPUT is just for such that actually has a
listener, and they both make sense in different scenarios.
> Drop? Makes no sense, else application would not be running in the first
> place.
Of course you can drop certain packets at this point, depending on other
details. Say, for instance, you want to match all packets that are
received by a certain task and that are originated from IP addresses of
a specific subnet, and drop the rest. Rather than adding matches to your
global firewall configuration for all the ports that tasks may or may
not listen on, you can just do it on a higher level, from the
perspective of an administrator. If you decide to let your web server
listen on another port as well, no firewall rule configuration change is
needed at all.
Another use case is accounting. If you want to know how much traffic a
certain service or application in your system has caused, you don't want
to match all its ports to firewall rules just in order to get that
information. Instead, you can now derive that information on a
per-application base. With this patch set, this even works just fine for
multicast listeners, which is something that is currently impossible to
achieve otherwise.
> So the only 'benefit' is that netcls id is available; but
> a) why is that even needed and
It's currently the only way of realizing application-level firewalls,
and it'd be an awesome feature if it actually worked.
> b) is such a huge sledgehammer just for net cgroup accounting
> worth it?
I really don't know if this approach is intrusive enough to make it
qualify as sledgehammer. I'd like to see some real-world benchmarks and
have proof there is a performance decrease for setups that don't use
such chains.
> Another question is what other strange things come up once we would
> open this door.
So let's discuss the possible drawbacks.
Again, the deal with this new chain type is simple: if there is no local
listener, the rules are not looked at. If you need rules that are
processed either way, put them in LOCAL_IN, as you always did.
>> listening on a specific task, the resulting error code that is sent
>> back to the remote peer can't be controlled with rules in
>> NF_INET_LOCAL_SOCKET_IN chains.
>
> Right, and that makes this even weirder.
Well, to be more specific: you can only control the resulting error code
that is sent back to the remote peer _if_ there is a local listener. You
can do _anything_ _if_ there is a local listener. This is in line with
the above description and shouldn't cause much surprises for users.
> For deterministic ingress filtering you can only rely on what
> is contained in the packet.
Why so? For deterministic ingress filtering of traffic directed to a
local socket, you can as well rely on information associated with that
socket. And this is what application-level firewall rule sets are all about.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
Daniel Mack wrote:
> Add a new chain type NF_INET_LOCAL_SOCKET_IN which is ran after the
> input demux is complete and the final destination socket (if any)
> has been determined.
>
> This helps filtering packets based on information stored in the
> destination socket, such as cgroup controller supplied net class IDs.
This still seems like the 'x y' problem ("want to do X, think Y is
correct solution; ask about Y, but thats a strange thing to do").
There is nothing that this offers over INPUT *except* that sk is
available. But there is zero benefit as far as I am concerned --
why would you want to do any meaningful filtering based on the sk at
that point...?
Drop? Makes no sense, else application would not be running in the first
place.
Allowing response packets? Can already do that with conntrack.
So the only 'benefit' is that netcls id is available; but
a) why is that even needed and
b) is such a huge sledgehammer just for net cgroup accounting
worth it?
Another question is what other strange things come up once we would
open this door.
> listening on a specific task, the resulting error code that is sent
> back to the remote peer can't be controlled with rules in
> NF_INET_LOCAL_SOCKET_IN chains.
Right, and that makes this even weirder.
For deterministic ingress filtering you can only rely on what
is contained in the packet.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
Add a new chain type NF_INET_LOCAL_SOCKET_IN which is ran after the
input demux is complete and the final destination socket (if any)
has been determined.
This helps filtering packets based on information stored in the
destination socket, such as cgroup controller supplied net class IDs.
Note that rules in such chains are not processed in case the local
listen socket cannot be determined. Hence, if no application is
listening on a specific task, the resulting error code that is sent
back to the remote peer can't be controlled with rules in
NF_INET_LOCAL_SOCKET_IN chains.
Signed-off-by: Daniel Mack
---
include/uapi/linux/netfilter.h | 1 +
net/ipv4/netfilter/iptable_filter.c | 1 +
net/ipv4/netfilter/nf_tables_ipv4.c | 4 +++-
net/netfilter/nf_tables_inet.c | 3 ++-
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/netfilter.h b/include/uapi/linux/netfilter.h
index d93f949..96c3f8b 100644
--- a/include/uapi/linux/netfilter.h
+++ b/include/uapi/linux/netfilter.h
@@ -49,6 +49,7 @@ enum nf_inet_hooks {
NF_INET_FORWARD,
NF_INET_LOCAL_OUT,
NF_INET_POST_ROUTING,
+ NF_INET_LOCAL_SOCKET_IN,
NF_INET_NUMHOOKS
};
diff --git a/net/ipv4/netfilter/iptable_filter.c
b/net/ipv4/netfilter/iptable_filter.c
index a0f3bec..d65616a5 100644
--- a/net/ipv4/netfilter/iptable_filter.c
+++ b/net/ipv4/netfilter/iptable_filter.c
@@ -21,6 +21,7 @@ MODULE_AUTHOR("Netfilter Core Team ");
MODULE_DESCRIPTION("iptables filter table");
#define FILTER_VALID_HOOKS ((1 << NF_INET_LOCAL_IN) | \
+ (1 << NF_INET_LOCAL_SOCKET_IN) | \
(1 << NF_INET_FORWARD) | \
(1 << NF_INET_LOCAL_OUT))
diff --git a/net/ipv4/netfilter/nf_tables_ipv4.c
b/net/ipv4/netfilter/nf_tables_ipv4.c
index aa180d3..abee60a 100644
--- a/net/ipv4/netfilter/nf_tables_ipv4.c
+++ b/net/ipv4/netfilter/nf_tables_ipv4.c
@@ -55,6 +55,7 @@ struct nft_af_info nft_af_ipv4 __read_mostly = {
[NF_INET_FORWARD] = nft_do_chain_ipv4,
[NF_INET_PRE_ROUTING] = nft_do_chain_ipv4,
[NF_INET_POST_ROUTING] = nft_do_chain_ipv4,
+ [NF_INET_LOCAL_SOCKET_IN] = nft_do_chain_ipv4,
},
};
EXPORT_SYMBOL_GPL(nft_af_ipv4);
@@ -96,7 +97,8 @@ static const struct nf_chain_type filter_ipv4 = {
(1 << NF_INET_LOCAL_OUT) |
(1 << NF_INET_FORWARD) |
(1 << NF_INET_PRE_ROUTING) |
- (1 << NF_INET_POST_ROUTING),
+ (1 << NF_INET_POST_ROUTING) |
+ (1 << NF_INET_LOCAL_SOCKET_IN),
};
static int __init nf_tables_ipv4_init(void)
diff --git a/net/netfilter/nf_tables_inet.c b/net/netfilter/nf_tables_inet.c
index 9dd2d21..5544196 100644
--- a/net/netfilter/nf_tables_inet.c
+++ b/net/netfilter/nf_tables_inet.c
@@ -75,7 +75,8 @@ static const struct nf_chain_type filter_inet = {
(1 << NF_INET_LOCAL_OUT) |
(1 << NF_INET_FORWARD) |
(1 << NF_INET_PRE_ROUTING) |
- (1 << NF_INET_POST_ROUTING),
+ (1 << NF_INET_POST_ROUTING) |
+ (1 << NF_INET_LOCAL_SOCKET_IN),
};
static int __init nf_tables_inet_init(void)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
