Thanks for your reply, I appreciate it. You replied "odd" concerning my subnet-specific statement. I think I understand that so I'll elaborate:
I had a one-interface VM and added an interface via virt-manager (which, to my surprise, auto-magically appeared on the VM without rebooting) - both interfaces connect to the same router/firewall (different router interfaces, one per subnet, call one a 10. and the other a 172. subnet) The original VM interface was on the 10. subnet. When I assigned a 172. address to the new interface problems occurred.
A system on the 172 subnet couldn't ping the VM's 10. subnet interface but a system on a 192. subnet could. I believe the reason is -
When I added the 172. IP address on the VM, a route to that subnet on that interface with that address as source was added to the routing table. As a result, when a 172. address pinged the 10. address the request came in on the 10. interface and tried to go out the 172. interface.
However, there was no route entry for the 192. subnet so, when it did a ping, the request came in on the 10. interface and returned on the 10. interface because the default route was set for that interface.
Hope this makes sense.
Early
Bird Extended! Save now until July 20 on the 2018 Momentum User
Conference!
Register
here
Leroy Tennison
Network Information/Cyber Security Specialist
E: leroy@xxxxxxxxxxxxxxxx
2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com
TThis message has been sent on behalf
of a company that is part of the Harris Operating Group of
Constellation Software Inc. These companies are listed
here
.
If you prefer not to be contacted by Harris
Operating Group
please notify us
.
This message is intended exclusively for the
individual or entity to which it is addressed. This communication
may contain information that is proprietary, privileged or
confidential or otherwise legally exempt from disclosure. If you are
not the named addressee, you are not authorized to read, print,
retain, copy or disseminate this message or any part of it. If you
have received this message in error, please notify the sender
immediately by e-mail and delete all copies of the
message.
________________________________________
From: lartc-owner@xxxxxxxxxxxxxxx <lartc-owner@xxxxxxxxxxxxxxx> on behalf of Jay Vosburgh <jay.vosburgh@xxxxxxxxxxxxx>
Sent: Friday, July 13, 2018 11:26 AM
To: Grant Taylor
Cc: lartc@xxxxxxxxxxxxxxx
Subject: [EXTERNAL] Re: rp_filter
Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxxx> wrote:
>On 07/13/2018 09:23 AM, Leroy Tennison wrote:
>> Is there a definitive way to tell that rp_filter is dropping traffic (in
>> this case echo request) other than disabling it and seeing the expected
>> traffic (echo reply)? I tried an iptables packet trace but I either did
>> it wrong or it showed nothing. The only indications I have right now
>> are:
>
>Check dmesg. That's the most reliable place I've seen for logs about (so
>called) "martian" packets.
I believe they're also counted in the "in_martian_src" column of
/proc/net/stat/rt_cache.
-J
>> No firewall rules blocking traffic but no replies either.
>
>It seems like reverse path filtering operates at a lower layer before
>IPTables.
>
>> The problem is subnet-specific (only occurs on a directly-connected
>> subnet).
>
>Odd.
>
>
>
>--
>Grant. . . .
>unix || die
---
-Jay Vosburgh, jay.vosburgh@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
��.n��������+%������w��{.n����j�\�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
