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�����٥