Why does Red Hat Enterprise Linux 6 and above invalidate / discard packets when the route for outbound traffic differs from the route of incoming traffic?

Solution Verified - Updated -


  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Networking


  • Why does Red Hat Enterprise Linux 6 invalidate / discard packets when the route for outbound traffic differs from the route of incoming traffic?
  • Why does Red Hat Enterprise Linux 6 differ from Red Hat Enterprise Linux 5 in handling asymmetrically routed packets?
  • Why does Red Hat Enterprise Linux 7 not respond to connection attempts to a second NIC?


To accept asymmetrically routed (outgoing routes and incoming routes are different) packets set rp_filter = 2

Temporary change

This can be changed during runtime by running the following commands:

# echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter
# echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter

Persistent change

To make this behaviour persistent across reboots, modify /etc/sysctl.conf and make the following change prior to reboot:

net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2

Root Cause

RHEL6's (and RHEL7's) default setting is more strict than RHEL5's, as RHEL6 follows the Strict Reverse Path Forwarding filtering recommended in RFC 3704 - Ingress Filtering for Multihomed Networks.

Diagnostic Steps

The sysctl net.ipv4.conf.default.rp_filter selects the default RPF filtering setting for IPv4 networking. (It can be overridden per network interface through net.ipv4.conf.INTERFACE.rp_filter).

RHEL7, RHEL6, and RHEL5 ship with a default /etc/sysctl.conf that sets this sysctl to 1, but the meaning of this value is different between the RHEL6 and the RHEL5 kernel.

In RHEL5, the sysctl is documented as follows:


rp_filter - BOOLEAN
        1 - do source validation by reversed path, as specified in RFC1812
            Recommended option for single homed hosts and stub network
            routers. Could cause troubles for complicated (not loop free)
            networks running a slow unreliable protocol (sort of RIP),
            or using static routes.

        0 - No source validation.

        conf/all/rp_filter must also be set to TRUE to do source validation
        on the interface

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

whereas in RHEL6 and RHEL7 there are three possible values for this setting:


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 not the best reverse path the packet check will fail.
            By default failed packets are 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 reachable via any interface
            the packet check will fail.

        Current recommended practice in RFC3704 is 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.

with the value 2 corresponding to the behaviour that value 1 provided in RHEL5.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.


It would be nice to get some additional tags added.  The problem I had was specific to iscsi and was difficult to find the correlation.

Thank you for your feedback. If you can describe your problem and how you found the resolution useful, we could try and incorporate that into this article or in another article for your future reference. If you have access to Red Hat support, you can even open a ticket for this and have a support technician actively work on this with you.



Global Support Services, Red Hat

Thanks for publishing this. I have a host with a leg in both a DMZ and a LAN, and packets coming in through the firewall (NAT) to the DMZ address would get dropped on the floor (since the leg in the LAN space had the same address). It was necessary to set rp_filter=0 in this case (2 did not work). Also, after setting conf/default/rp_filter and restarting networking, the existing devices' setting was not changed. Setting them manually worked, as did conf/default via sysctl.conf on reboot.

For temporary change, the two commands

    # echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter  
    # service network restart

are not sufficient.

You need

    # echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter  
    # echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter  


    # sysctl -w "net.ipv4.conf.default.rp_filter=2" 
    # sysctl -w "net.ipv4.conf.all.rp_filter=2"

network restart is not needed.

Thanks for (correct) feedback, solution already updated.

The following command lines mentioned above:

# echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter
# service network restart

hardly could be recognizes as "good practice" or even acceptable good style of system/network administration.

First, it is bad idea to use echo for changing values in /proc. The following command line:

# sysctl -w "net.ipv4.conf.default.rp_filter=2"

is more safety and effective replacement of

# echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter

Please note that most of the network init scripts in RHEL6 (see /etc/sysconfig/network-scripts) are adapted to use sysctl tool and echos are removed.

Secondly, there is no need to restart the service network in this particular case. Yes, if the only command line executed so far is:

# sysctl -w "net.ipv4.conf.default.rp_filter=2"

all the interfaces must be re-initialized in order to read the newly set default option. But there is very simple woraround to do this on-the-fly, without losing any conectivity. The execution of the command line:

# sysctl -w "net.ipv4.conf.all.rp_filter=2"

(change all to a particular interface named, if needed) will solve the problem with re-configuring the interfaces and it will flush all the current source tracking.

Pfff, took me half a day to work this out after upgrading a firewall with IPIP tunneling from RHEL 5 to RHEL 6!
A-symmetric routed packets just disappear in the dark hole of Linux networking .. no logging to turn to.

Thank you for this. This all worked out perfectly for me.

After a long time I came to know about this...
Very very thankful information,,,

Tip: to see if rp_filter is affecting traffic for you, enable martian logging:

sysctl -w net.ipv4.conf.all.log_martians=1