When RHEL has multiple IPs configured, only one is reachable from a remote network. Or why does RHEL ignore packets when the route for outbound traffic differs from the route of incoming traffic?
Environment
- Red Hat Enterprise Linux (RHEL) 6 and later
Issue
- 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 not respond to connection attempts to a second NIC?
- Why can't a server be pinged if net.ipv4.conf.all.rp_filter is set on the server?
- Problem configuring two NICs on different subnets
- I have a server with 2 Network Interfaces and I configured both the NICs on 2 different subnets. Workstations with just one NIC can communicate with the server on the shared network, but not on the other network.
- When I bring assign a IP to new network interface the system stops communicating ?
Resolution
Before making this change please see the Root Cause section of this article to understand what it does and review alternative solutions.
Set the net.ipv4.conf.all.rp_filter
kernel tunable parameter value to 2
:
sysctl -w net.ipv4.conf.all.rp_filter=2
To make this change persistent across reboots, add the tunable to the /etc/sysctl.conf
or /etc/sysctl.d/99-custom.conf
file. Refer to How to set sysctl variables on Red Hat Enterprise Linux for the detail.
IPv6
In case of the IPv6 protocol the firewalld daemon applies Reverse Path Filtering by default. The setting can be checked in the /etc/firewalld/firewalld.conf file. You can change the firewalld behavior by setting the IPv6_rpfilter option.
Root Cause
-
RHEL 6 and above are configured by default to apply Strict Reverse Path Forwarding filtering recommended in RFC 3704 - Ingress Filtering for Multihomed Networks.
-
Strict filtering means that when a packet arrives on the system, the kernel takes the source IP of the packet and makes a lookup of its routing table to see if the interface the packet arrived on is the same interface the kernel would use to send a packet to that IP. If the interfaces are the same then the packet has passed the strict filtering test and it is processed normally. If the interfaces are not the same then the packet is discarded without any further processing and in RHEL 7+, the
IPReversePathFilter
counter is incremented. -
The main effect of strict filtering is that for a given remote IP, the system will only communicate with it via a specific interface. Set up static routes to control which interface responds to a given remote IP or network.
-
The filtering method is controlled globally by the
sysctl
net.ipv4.conf.all.rp_filter
described in the kernel documentation: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt. RHEL 6+ override the kernel default value of 0 (disabled) for this parameter and set it to 1 (strict).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.
-
The most simple way to disable the strict check is to set the
sysctl
net.ipv4.conf.all.rp_filter
to 2 (loose) as this will override the interface-specific settings. Settingnet.ipv4.conf.all.rp_filter
to 0 (disabled) does not override interface-specific settings so is not recommended. -
Note that without the strict check, the system may respond to a packet via a different interface than it arrived on. Whether this will result in the expected connectivity depends on many factors external to the system such as physical network topology and firewall policies.
-
An alternate way to configure a system to function with
rp_filter
in strict mode is to set up policy based routing: How can I route network traffic such that the packets go out via the same interface they came in? -
Note that in RHEL 5 and earlier, the kernel did not support strict filtering. So in these older releases, the
net.ipv4.conf.all.rp_filter
parameter only has two possible values, 0 (disabled) and 1 (loose). The default is 1 (loose).
Diagnostic Steps
-
Check the value of the
rp_filter
sysctls:$ sysctl -a 2>/dev/null | grep "\.rp_filter" net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.enp0s31f6.rp_filter = 0 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.tun0.rp_filter = 0 net.ipv4.conf.virbr0.rp_filter = 0 net.ipv4.conf.virbr0-nic.rp_filter = 0 net.ipv4.conf.virbr1.rp_filter = 0 net.ipv4.conf.virbr1-nic.rp_filter = 0 net.ipv4.conf.wlp58s0.rp_filter = 0
-
For RHEL 7 and above, check the
IPReversePathFilter
SNMP counter. If packets are being ignored due to strict filtering then this counter will increment each time it happens:$ nstat -rsz | grep IPReversePathFilter TcpExtIPReversePathFilter 52537 0.0 $ netstat -s | grep IPReversePathFilter IPReversePathFilter: 52537
-
For a given remote IP whose packets appear to be ignored by the system, perform a route lookup to see which interface the system will use to reach that remote IP. If this is not the same interface the remote IP's packets are arriving on then strict enforcing will discard them:
$ ip route get <remote IP>
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.
Comments