[strongSwan] Problem getting default route over IPsec tunnel

[Rayson Zhu]

Does the client connect to 10.252.16.0/20 by directly or through the IPSec
tunnel?
Maybe you need a passthrough policy:

conn bypass
  left = 10.252.16.0/20
  right = 10.252.16.0/20
  type = passthrough
  auto = route

and disable the farp plugin


On Mon, Oct 19, 2015 at 5:45 AM, Heiko Wundram <modelnine at modelnine.org>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello Noel,
>
> Am 18.10.2015 um 03:36 schrieb Noel Kuntze:
> > Am 18.10.2015 um 02:55 schrieb Heiko Wundram:
> >> /sbin/ip route add default dev eth1 metric 1 table uplink
> > Try giving that a next hop over the next router. You also need to
> > set the rp_filter for the involved interfaces to "2". Furthermore,
> > you need to stuff packets from the other side into the same table
> > or funky things might happen the next time you change the routing
> > on that box.
>
> thanks for the hint concerning rp_filter for the outgoing interface,
> that was part one of the solution. :-) It made no difference putting
> either the next-hop or the interface route on the default route, I
> forgot to note that yesterday (and it was part of what I already
> tried, before settling for using the interface route directly due to
> the fact that I also need to transport an IPv6-network with default
> gateway in this fashion).
>
> Anyway, what I was missing: ipcomp was on for the IKE-SA, so that both
> ends of the connection needed an additional iptables INPUT match to
> actually unpack the "small packets". I just tested the connection with
> an IPv4 ping, which is "too small" to compress properly and as such is
> transported as ipencap (proto 4) instead of being compressed, and the
> firewall at both ends didn't like accepting that and just dropped them
> on INPUT (which was of course the part I didn't check, I did check
> with a -j LOG on the FORWARD chain, where the packets weren't
> showing). Oh, well, now I know. :-)
>
> >> dpdaction=restart auto=start
> > Use auto=route.
> >> 220:    from all lookup 220
> > Mind showing us that routing table (even if it should be empty,
> > just checking.)
>
> Irrelevant now, but:
>
> root at gw:/etc# ip route show table 220
> root at gw:/etc# ip -6 route show table 220
> root at gw:/etc#
>
> I did check that. ;-)
>
> Thanks again for the hint with rp_filter (which I deemed unecessary,
> as there was a default route on the interface anway in another table),
> which did part of the trick, and for the rest: the documentation did
> actually have something on this if you knew where to look! ;-)
>
> - --
> Heiko Wundram.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWJBMXAAoJEJ/eyTFUqXhdi80QAIRpZAx8SOK1Ts+47xU9UPBL
> 0oM/yMm4mN3Vx9lJVm6BD+R1T0rhph6bsObm8K9O58X/acZSIgxVQ7Vg3ZIG8agZ
> qzFMaOGFgwU2OTtRjwcnbnp+w6kYXLlnj34GPpCXB/p4tS+mQYU3PQtIySG0amrZ
> grrsVq5wc2vKTmR33kf3O3LHrPReLbbdTfQep+FLzrRf8rAPdddmmM6djTzt/7fL
> gF4clS3JaOauiSO9yOSMVcfcoF6Q+DhPwEJ2L+0yugAuneKhd17DpcrvCY3GPNZL
> arLJW43qoG4p20mOtiLYLT+wG/WawZHblAOTVYcfHW1KjHq4iOc5b97/XixE8s0i
> ipFM7swYqk4GcOKh4kOcZBTwydmku788aOQANXaQz89dG+lWxmNEg4iXEe0BnDb+
> MsYy5rdsgq/EJk+9gJXqBfefup2CfLyfyXcsoq/e3iR/msoB3rc5lL3GL+ocil6P
> MXFsE90reOIEof4iRQRywJG8zviyRpUhQCs2ve5bDlRC5wE2V9bOMTgyIF5uSsSX
> QWTx6cuQ0E07KqdaOJ0b9iiOSmArAVFP7AQzdUmndtdSQf6F0bUnQWmsso55T0MH
> AI+caYorTUGHMJvVoTi1iu3wNEV4dgxqI0qki5uQan+WDbzVvDSHVILQyFSLvoKI
> 7u7+GH34b04rYHkkAQJz
> =64ou
> -----END PGP SIGNATURE-----
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20151019/2ba2ca88/attachment.html>