[strongSwan] Problem getting default route over IPsec tunnel

[Heiko Wundram]

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