From: Stephen Clark <hidden> Date: 2011-08-17 17:03:20
Hello List,
Firstly thank you for your patience. I am replacing a bunch of FreeBSD vpn/fw/routers
with a Linux based system.
I have run into a situation where if I ping our HQ the response comes back on a different
interface than what the request went out on. FreeBSD is happy and says it got the response,
Linux is not and gives no indication it got a response.
So is FreeBSD wrong or is Linux wrong?
Or is there some sysctl I can fiddle with on Linux to make it see the response. This happens
with the iptables set to accept on all chains.
Thanks again for your indulgence. I googled this and didn't find anything germane.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
From: Emil S Tantilov <hidden> Date: 2011-08-17 17:10:34
On Wed, Aug 17, 2011 at 10:03 AM, Stephen Clark [off-list ref] wrote:
Hello List,
Firstly thank you for your patience. I am replacing a bunch of FreeBSD
vpn/fw/routers
with a Linux based system.
I have run into a situation where if I ping our HQ the response comes back
on a different
interface than what the request went out on. FreeBSD is happy and says it
got the response,
Linux is not and gives no indication it got a response.
Try enabling ARP filtering:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
Thanks,
Emil
Le mercredi 17 août 2011 20:03:18 Stephen Clark, vous avez écrit :
I have run into a situation where if I ping our HQ the response comes
back on a different
interface than what the request went out on. FreeBSD is happy and says
it got the response,
Linux is not and gives no indication it got a response.
So is FreeBSD wrong or is Linux wrong?
Most distributions enable reverse path filtering by default.
It can be disabled:
# echo -n 0 > /proc/sys/net/ipv4/conf/all/rp_filter
But you should probably fix the configuration instead (e.g. /etc/sysctl.conf).
--
Rémi Denis-Courmont
http://www.remlab.net/http://fi.linkedin.com/in/remidenis
From: Stephen Clark <hidden> Date: 2011-08-17 17:51:26
On 08/17/2011 01:10 PM, Emil S Tantilov wrote:
On Wed, Aug 17, 2011 at 10:03 AM, Stephen Clark[off-list ref] wrote:
quoted
Hello List,
Firstly thank you for your patience. I am replacing a bunch of FreeBSD
vpn/fw/routers
with a Linux based system.
I have run into a situation where if I ping our HQ the response comes back
on a different
interface than what the request went out on. FreeBSD is happy and says it
got the response,
Linux is not and gives no indication it got a response.
Just tried it - made no difference.
Thanks.
[root@L101111 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_filterL101111:~
$ ping -I 172.21.76.150 172.21.232.55
PING 172.21.232.55 (172.21.232.55) from 172.21.76.150 : 56(84) bytes of data.
^C
--- 172.21.232.55 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8238ms
L101111:~
$ sudo tcpdump -nli eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:19:13.808262 IP 172.21.232.55 > 172.21.76.150: ICMP echo reply, id 19545, seq 6, length 64
13:19:14.807541 IP 172.21.232.55 > 172.21.76.150: ICMP echo reply, id 19545, seq 7, length 64
^C
From: Stephen Clark <hidden> Date: 2011-08-17 19:44:03
On 08/17/2011 01:17 PM, Rémi Denis-Courmont wrote:
Le mercredi 17 août 2011 20:03:18 Stephen Clark, vous avez écrit :
quoted
I have run into a situation where if I ping our HQ the response comes
back on a different
interface than what the request went out on. FreeBSD is happy and says
it got the response,
Linux is not and gives no indication it got a response.
So is FreeBSD wrong or is Linux wrong?
Most distributions enable reverse path filtering by default.
It can be disabled:
# echo -n 0> /proc/sys/net/ipv4/conf/all/rp_filter
But you should probably fix the configuration instead (e.g. /etc/sysctl.conf).
Sorry that didn't help either.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On 08/17/2011 01:17 PM, Rémi Denis-Courmont wrote:
quoted
Le mercredi 17 août 2011 20:03:18 Stephen Clark, vous avez écrit :
quoted
I have run into a situation where if I ping our HQ the response comes
back on a different
interface than what the request went out on. FreeBSD is happy and says
it got the response,
Linux is not and gives no indication it got a response.
So is FreeBSD wrong or is Linux wrong?
Neither is right or wrong. It partly depends whether you want to enforce
so-called "weak" or "strong" host model.
quoted
Most distributions enable reverse path filtering by default.
It can be disabled:
# echo -n 0> /proc/sys/net/ipv4/conf/all/rp_filter
But you should probably fix the configuration instead (e.g. /etc/sysctl.conf).
Sorry that didn't help either.
Since some kernel version the logic of this sysctl has changed from
AND(all, $interface) to MAX(all, $interface). So you must set
net/ipv4/conf/$interface/rp_filter to 0 too to disable it.
Or set net/ipv4/conf/all/rp_filter to 2 to make it weaker.
From: Stephen Clark <hidden> Date: 2011-08-18 12:42:37
On 08/17/2011 04:15 PM, Pascal Hambourg wrote:
Hello,
Stephen Clark a écrit :
quoted
On 08/17/2011 01:17 PM, Rémi Denis-Courmont wrote:
quoted
Le mercredi 17 août 2011 20:03:18 Stephen Clark, vous avez écrit :
quoted
I have run into a situation where if I ping our HQ the response comes
back on a different
interface than what the request went out on. FreeBSD is happy and says
it got the response,
Linux is not and gives no indication it got a response.
So is FreeBSD wrong or is Linux wrong?
Neither is right or wrong. It partly depends whether you want to enforce
so-called "weak" or "strong" host model.
quoted
quoted
Most distributions enable reverse path filtering by default.
It can be disabled:
# echo -n 0> /proc/sys/net/ipv4/conf/all/rp_filter
But you should probably fix the configuration instead (e.g. /etc/sysctl.conf).
Sorry that didn't help either.
Since some kernel version the logic of this sysctl has changed from
AND(all, $interface) to MAX(all, $interface). So you must set
net/ipv4/conf/$interface/rp_filter to 0 too to disable it.
Or set net/ipv4/conf/all/rp_filter to 2 to make it weaker.
I guess I don't really understand what reverse path filter stuff is all about, much less making it weaker.
But using 2 made the pings responses be seen.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
From: Chris Friesen <hidden> Date: 2011-08-19 16:19:05
On 08/18/2011 06:42 AM, Stephen Clark wrote:
I guess I don't really understand what reverse path filter stuff is all
about, much less making it weaker.
But using 2 made the pings responses be seen.
It's described in RFC3704. The idea is to block spoofed packets.
From 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 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.
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
From: Stephen Clark <hidden> Date: 2011-08-19 19:10:21
On 08/19/2011 12:18 PM, Chris Friesen wrote:
On 08/18/2011 06:42 AM, Stephen Clark wrote:
quoted
I guess I don't really understand what reverse path filter stuff is all
about, much less making it weaker.
But using 2 made the pings responses be seen.
It's described in RFC3704. The idea is to block spoofed packets.
From 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 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.
Thanks for taking the time to explain this. Much appreciated.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)