Reverse Path filtering--reverse path filter

Original address: Reverse path filtering--reverse path filter PWP_CU

Reverse Path filtering--reverse path filter

First, the principle
First introduce the concept of asymmetric routing
Refer to "Understanding Linux Network Internals" Chapter 30,
30.2. Essential Elements of Routing
Symmetric routes and asymmetric routes
Usually, the route taken from host A to Host B are the same as the route used to get back from Host B to host A; The route is then called symmetric. In complex setups, the route is different; In the It is asymmetric.

For reverse path filtering, refer to "Understanding Linux Network Internals" chapter 31,
31.7. Reverse Path Filtering
We saw what a asymmetric route is in the sections "Essential Elements of Routing in Chapter 30. Asymmetric routes is not common and may is necessary in certain cases. The default behavior of Linux is to consider asymmetric routing suspicious and therefore to drop any packet whose source I P address is not reachable through the device the packet were received from, according to the routing table.
However, this behavior can is tuned via/proc on a per-device basis, as we'll see in Chapter 36. See also, "Input Routing" in Chapter 35.

Second, the inspection process
If a host (or router) receives a packet from interface A, its source address and destination address are 10.3.0.2 and 10.2.0.2, respectively.
That is, if you enable the reverse path filtering feature, it will look for the keyword to find the routing table, if the resulting output interface is not a, then the reverse path filter check failed, it will discard the package.

With regard to reverse path filtering, there is a parameter in IPv4, and the description of this parameter is in Documentation/networking/ip-sysctl.txt.
Rp_filter-integer
0-no source Validation.
1-strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the interface
Is isn't the best reverse path the packet check would fail.
By default failed packets is discarded.
2-loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet ' s source address is also tested against the FIB
And if the source address is not a reachable via any interface
The packet check would fail.

Current recommended practice in RFC3704 are to enable strict mode
To prevent IP spoofing from DDos attacks. If Using Asymmetric routing
or other complicated routing, then loose mode is recommended.

The max value from Conf/{all,interface}/rp_filter is used
When doing source validation on the {interface}.

Default value is 0. Note that some distributions enable it
In startup scripts.

Third, source code analysis
git commit 373da0a2a33018d560afcb2c77f8842985d79594

Net/ipv4/fib_frontend.c
192 int Fib_validate_source (struct sk_buff *skb, __be32 src, __be32 DST, U8 tos,
193 int oif, struct net_device *dev, __be32 *spec_dst,
194 u32 *itag)
195 {
Whether to enable reverse path filtering
216/* Ignore Rp_filter for packets protected by IPSEC. */
217 RPF = secpath_exists (SKB)? 0:in_dev_rpfilter (In_dev);

Check the routing table
Note that the source address here is the reverse of the destination address,
See how other functions Call Fib_validate_source () to understand.
227 if (fib_lookup (NET, &fl4, &res))
228 goto Last_resort;

Run here to show that the reverse route is up to
Here are two things to check if the output device is the input device
237 #ifdef Config_ip_route_multipath
When Multipath is enabled, it is used for any match.
238 for (ret = 0; ret < res.fi->fib_nhs; ret++) {
239 struct FIB_NH *nh = &res.fi->fib_nh[ret];
240
241 if (Nh->nh_dev = = Dev) {
242 Dev_match = true;
243 break;
244}
245}
246 #else
247 if (Fib_res_dev (RES) = = DEV)
248 Dev_match = true;
249 #endif
if (Dev_match) {
Reverse path filtering check succeeded, return
251 ret = FIB_RES_NH (RES). Nh_scope >= Rt_scope_host;
252 return ret;
253}
254 if (NO_ADDR)
255 goto Last_resort;
Run here, indicating that the reverse path check was unsuccessful,
If RPF is 1, the reverse path check must succeed in order to return normally.
Otherwise you have to return an error.
if (RPF = = 1)
257 goto E_RPF;
278 E_RPF:
279 Return-exdev;

Iv. examples
The network has three machines, R1, R2 and PC, the subnet mask is 255.255.0.0.
R2 (10.1.0.2)----(10.1.0.1) R1 (10.3.0.1)----(10.3.0.2) PC
R2 (10.2.0.2)----(10.2.0.1) R1

Note that the default route for setting R2 is 10.1.0.1
Now, you can ping the 10.1.0.2 from the PC, but the ping does not pass the 10.2.0.2.
Tcpdump shows that the R2 receives the ICMP request, but does not send an ICMP reply.

Pc
$ IP A
inet 10.3.0.2/16 BRD 10.3.255.255 Scope Global eth0
$ IP R
10.3.0.0/16 Dev eth0 proto kernel scope link src 10.3.0.2
Default via 10.3.0.1 Dev eth0

R1
$ IP A
inet 10.1.0.1/16 BRD 10.1.255.255 Scope Global eth1
inet 10.2.0.1/16 BRD 10.2.255.255 Scope Global eth2
inet 10.3.0.1/16 BRD 10.3.255.255 Scope Global ETH3
$ IP R
10.1.0.0/16 Dev eth1 proto kernel scope link src 10.1.0.1
10.2.0.0/16 Dev eth2 proto kernel scope link src 10.2.0.1
10.3.0.0/16 Dev eth3 proto kernel scope link src 10.3.0.1

R2
$ IP A
inet 10.1.0.2/16 BRD 10.1.255.255 Scope Global eth1
inet 10.2.0.2/16 BRD 10.2.255.255 Scope Global eth2

$ IP R
10.1.0.0/16 Dev eth1 proto kernel scope link src 10.1.0.2
10.2.0.0/16 Dev eth2 proto kernel scope link src 10.2.0.2
Default via 10.1.0.1 Dev eth1

Excuse me, what is the reason?
You can go back and think about it for 5 minutes ...

My answer is:
Assume that the R2 two interfaces are a (10.1.0.2), B (10.2.0.2), respectively.
When pinging 10.2.0.2 from a PC, the package path is pc-->10.3.0.1-->10.2.0.2,
At this time the package,
To perform a reverse path check to get the output device A,
Because the destination address is 10.3.0.2, only the default route can be used. A!=b, reverse path check failed,
Discard the package!

Five, how to solve
Two methods:
1 on R2:
IP route add 10.3.0.0/16 via 10.2.0.2
Add a route about the 10.3.0.0/16 subnet.

2 on R2:
/etc/sysctl.conf
Net.ipv4.conf.default.rp_filter = 0
Disables reverse path checking.

Reverse Path filtering--reverse path filter