Merge branch 'inet_fwmark_reflect'
authorDavid S. Miller <davem@davemloft.net>
Tue, 13 May 2014 22:35:18 +0000 (18:35 -0400)
committerDavid S. Miller <davem@davemloft.net>
Tue, 13 May 2014 22:35:18 +0000 (18:35 -0400)
commitb6bd26c4de0141d0736a51487e4ca37390fcae03
treeb8040290a249b8242767c1bb7f433deb40b4e6e0
parent87e067cda6df60b55cea0239c2f3cee81e9f46df
parent84f39b08d7868ce10eeaf640627cb89777f0ae93
Merge branch 'inet_fwmark_reflect'

Lorenzo Colitti says:

====================
Make mark-based routing work better with multiple separate networks.

Mark-based routing (ip rule fwmark 17 lookup 100) combined with
either iptables marking (iptables -j MARK --set-mark 17) or
application-based marking (the SO_MARK setsockopt) are a good
way to deal with connecting simultaneously to multiple networks.

Each network can be given a routing table, and ip rules can
be configured to make different fwmarks select different
networks. Applications can select networks them by setting
appropriate socket marks, and iptables rules can be used to
handle non-aware applications, enforce policy, etc.

This patch series improves functionality when mark-based routing
is used in this way. Current behaviour has the following
limitations:

1. Kernel-originated replies that are not associated with a
   socket always use a mark of zero. This means that, for
   example, when the kernel sends a ping reply or a TCP reset,
   it does not send it on the network from which it received the
   original packet.
2. Path MTU discovery, which is triggered by incoming packets,
   does not always work correctly, because the routing lookups it
   uses to clone routes do not take the fwmark into account and
   thus can happen in the wrong routing table.
3. Application-based marking works well for outbound connections,
   but does not work well for incoming connections. Marking a
   listening socket causes that socket to only accept
   connections from a given network, and sockets that are
   returned by accept() are not marked (and are thus not routed
   correctly).

sysctl. This causes route lookups for kernel-generated replies
and PMTUD to use the fwmark of the packet that caused them.

which causes TCP sockets returned by accept() to be marked with
the same mark that sent the intial SYN packet.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>