<div dir="ltr">Does the client connect to <a href="http://10.252.16.0/20" rel="noreferrer" target="_blank" style="font-size:12.8px">10.252.16.0/20</a> by directly or through the IPSec tunnel?<div>Maybe you need a passthrough policy:</div><div><br></div><div>conn bypass</div><div> left =<span style="font-size:12.8px"> </span><a href="http://10.252.16.0/20" rel="noreferrer" target="_blank" style="font-size:12.8px">10.252.16.0/20</a></div><div> right = <a href="http://10.252.16.0/20" rel="noreferrer" target="_blank" style="font-size:12.8px">10.252.16.0/20</a></div><div> type = passthrough</div><div> auto = route</div><div><br></div><div>and disable the farp plugin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 19, 2015 at 5:45 AM, Heiko Wundram <span dir="ltr"><<a href="mailto:modelnine@modelnine.org" target="_blank">modelnine@modelnine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
</span>Hello Noel,<br>
<span class=""><br>
Am 18.10.2015 um 03:36 schrieb Noel Kuntze:<br>
> Am 18.10.2015 um 02:55 schrieb Heiko Wundram:<br>
>> /sbin/ip route add default dev eth1 metric 1 table uplink<br>
> Try giving that a next hop over the next router. You also need to<br>
> set the rp_filter for the involved interfaces to "2". Furthermore,<br>
> you need to stuff packets from the other side into the same table<br>
> or funky things might happen the next time you change the routing<br>
> on that box.<br>
<br>
</span>thanks for the hint concerning rp_filter for the outgoing interface,<br>
that was part one of the solution. :-) It made no difference putting<br>
either the next-hop or the interface route on the default route, I<br>
forgot to note that yesterday (and it was part of what I already<br>
tried, before settling for using the interface route directly due to<br>
the fact that I also need to transport an IPv6-network with default<br>
gateway in this fashion).<br>
<br>
Anyway, what I was missing: ipcomp was on for the IKE-SA, so that both<br>
ends of the connection needed an additional iptables INPUT match to<br>
actually unpack the "small packets". I just tested the connection with<br>
an IPv4 ping, which is "too small" to compress properly and as such is<br>
transported as ipencap (proto 4) instead of being compressed, and the<br>
firewall at both ends didn't like accepting that and just dropped them<br>
on INPUT (which was of course the part I didn't check, I did check<br>
with a -j LOG on the FORWARD chain, where the packets weren't<br>
showing). Oh, well, now I know. :-)<br>
<span class=""><br>
>> dpdaction=restart auto=start<br>
> Use auto=route.<br>
>> 220: from all lookup 220<br>
> Mind showing us that routing table (even if it should be empty,<br>
> just checking.)<br>
<br>
</span>Irrelevant now, but:<br>
<br>
root@gw:/etc# ip route show table 220<br>
root@gw:/etc# ip -6 route show table 220<br>
root@gw:/etc#<br>
<br>
I did check that. ;-)<br>
<br>
Thanks again for the hint with rp_filter (which I deemed unecessary,<br>
as there was a default route on the interface anway in another table),<br>
which did part of the trick, and for the rest: the documentation did<br>
actually have something on this if you knew where to look! ;-)<br>
<br>
- --<br>
Heiko Wundram.<br>
<span class="">-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
</span>iQIcBAEBCAAGBQJWJBMXAAoJEJ/eyTFUqXhdi80QAIRpZAx8SOK1Ts+47xU9UPBL<br>
0oM/yMm4mN3Vx9lJVm6BD+R1T0rhph6bsObm8K9O58X/acZSIgxVQ7Vg3ZIG8agZ<br>
qzFMaOGFgwU2OTtRjwcnbnp+w6kYXLlnj34GPpCXB/p4tS+mQYU3PQtIySG0amrZ<br>
grrsVq5wc2vKTmR33kf3O3LHrPReLbbdTfQep+FLzrRf8rAPdddmmM6djTzt/7fL<br>
gF4clS3JaOauiSO9yOSMVcfcoF6Q+DhPwEJ2L+0yugAuneKhd17DpcrvCY3GPNZL<br>
arLJW43qoG4p20mOtiLYLT+wG/WawZHblAOTVYcfHW1KjHq4iOc5b97/XixE8s0i<br>
ipFM7swYqk4GcOKh4kOcZBTwydmku788aOQANXaQz89dG+lWxmNEg4iXEe0BnDb+<br>
MsYy5rdsgq/EJk+9gJXqBfefup2CfLyfyXcsoq/e3iR/msoB3rc5lL3GL+ocil6P<br>
MXFsE90reOIEof4iRQRywJG8zviyRpUhQCs2ve5bDlRC5wE2V9bOMTgyIF5uSsSX<br>
QWTx6cuQ0E07KqdaOJ0b9iiOSmArAVFP7AQzdUmndtdSQf6F0bUnQWmsso55T0MH<br>
AI+caYorTUGHMJvVoTi1iu3wNEV4dgxqI0qki5uQan+WDbzVvDSHVILQyFSLvoKI<br>
7u7+GH34b04rYHkkAQJz<br>
=64ou<br>
<div class="HOEnZb"><div class="h5">-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a><br>
<a href="https://lists.strongswan.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>