<div dir="ltr"><div dir="ltr">Hello Rajiv, thanks for the suggestions.<div><br></div><div>I added your suggested rules at the start of each chain. I also opted to add another rule at the bottom of the chain, so I could see if in fact anything was being rejected.</div><div><br></div><div>-A INPUT -j LOG --log-prefix "IPv4-In-Drop: "<br>-A INPUT -j DROP<br></div><div><br></div><div>Once I added the log statement, I can see packets being dropped in my syslog:</div><div><br></div><div>Feb  1 15:13:23 WorkRouter kernel: IPv4-In-Drop: IN=Internet OUT= MAC=bc:30:5b:e3:9f:28:20:b3:99:cc:c2:24:08:00 SRC=192.168.127.254 DST=192.168.126.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=37930 DF PROTO=ICMP TYPE=8 CODE=0 ID=23320 SEQ=25<br></div><div><br></div><div>At this point I added similar logging rules to both the OUTPUT and FORWARD chains so I could see any forward or output drops.</div><div><br></div><div>I also added</div><div><br></div><div>-A INPUT -s <a href="http://192.168.127.0/24">192.168.127.0/24</a> -d <a href="http://192.168.126.0/24">192.168.126.0/24</a> -j ACCEPT</div><div><br></div><div>to the input chain. I also added a similar rules on the home router for logging and the reverse traffic flow. </div><div><br></div><div>Sadly, this had the effect of making the input reject logging messages disappear on the ping, but no further logging messages about rejected packets despite the fact of still not being able to ping or ssh, etc. from one subnet to the other.</div><div><br></div><div>I think I am getting closer, but obviously I am still missing something, somewhere to tie it all together.</div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p><br></p>
 </div>
</blockquote></div>
</blockquote></div></div>