<div dir="ltr"><div dir="ltr">Hi<div><br></div><div>If your setup is as below:</div><div><br></div><div><br> (192.168.127.2)PC1----(127.254)[Home]====ipsec tunnel====[workrouter](126.254)-----PC2(192.168.126.2)<br></div><div><br></div><div>1. Then, with the tunnel established (or send traffic from PC1 to PC2 or vice-versa to bringup the tunnel), try with traffic (ping, etc) between PC1 and PC2</div><div><br></div><div>2. I see that in the logs the Ping is between 192.168.127.254 and 192.168.126.254...meaning you are pinging from homerouter to the internal-lan-interface ipaddr of workrouter</div><div>For this specific traffic-scenario (wherein you are accessing the internal-interface of the ipsec-peergw) to work, you will need to also additionally use the option below in the children section of swanctl on both gateways</div><div><br></div><div>hostaccess = yes</div><div><br></div><div>Note: This basically corresponds to similar option used in "ipsec.conf" files - "lefthostaccess=yes"</div><div><br></div><div>This will result in 2 permit rules being added by the updown script in INPUT and OUTPUT chains, and ONLY then you will be able to ping/other-supported-traffic to the internal-lan-interface of the remote ipsec-peergw (from local-ipsec-peergw or from the lan-hosts behind-it )</div><div><br></div><div><br></div><div>thanks & regards</div><div><br></div><div><br></div><div> </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 2, 2022 at 1:57 AM Michael Deignan <<a href="mailto:michael.p.deignan@gmail.com">michael.p.deignan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">192.168.127.0/24</a> -d <a href="http://192.168.126.0/24" target="_blank">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>
</blockquote></div></div>