I have found the issue! Not a Strongswan one after all :)
This is my ip rules output:
# ip rule
0: from all lookup local
100: from 85.24.x.x lookup WAN1
101: from 90.225.x.x lookup WAN2
102: from 10.248.x.x lookup WAN3
104: from 46.195.x.x lookup WAN4
121: from all fwmark 0x100/0xf00 lookup WAN1
122: from all fwmark 0x200/0xf00 lookup WAN2
123: from all fwmark 0x300/0xf00 lookup WAN3
124: from all fwmark 0x400/0xf00 lookup WAN4
220: from all lookup main
32766: from all lookup main
32767: from all lookup default
When deleting rule 121 my VPN clients starts respecting the multipath
routes on the gateway and get routed out on ppp0 (WAN3) as wanted.
However, then my specific policy rules (marked with 0x100) stops going
out on vlan847 (WAN1) of course, which is not wanted. Do you have any
suggestion how I could make both work? I'm just guessing here, but
probably all incoming traffic on each of the WAN interfaces gets marked
with the above marks, so that return traffic goes out the same interface
which if the right behaviour, however not in my VPN remote access case!
Den 2017-04-26 kl. 23:19, skrev Noel Kuntze:
Hello Dusan,
In general, charon does not route any packets of the kernel. Charon is out of
the loop there,
however, it installs routes into routing table 220 by default to make sure the
packets
that are going to be protected with IPsec reach the remote subnet.
This means that when charon picks the wrong route, the traffic that is
forwarded or
sent by the kernel to the remote subnet is going to be routed over the last
fitting route that
the kernel-netlink plugin finds, as Tobias wrote.
In order to prevent this from happening, you have to disable the installation
of routes.
You do this by setting "charon.install_routes" to "no" in strongswan.conf or try
to set charon.plugins.kernel-netlink.fwmark to a mark value you don't use.
Kind regards,
Noel
On 26.04.2017 22:23, Dusan Ilic wrote:
Hi again Tobias,
After reading your post once more I suspect we are talking about different
things. I see you qouted my question why the last multipath is being chosen by
Strongswan when configuring left=%any and initiating the connection, however Im
talking about the route Strongswan chooses to forward remote clients out on the
Internet. Do you think the problem is the same? My remote clients are
connecting to Public IP on vlsn847, and when accessing the internet
(leftsubnet=0.0.0.0/0) they are being always routed out the same interface,
that is vlsn847. What I expect is that Strongswan will hand over the vpn
clients traffic to the Linux kernel, which will do a normal route lookup and
route the clients out on interface ppp0. Isnt this possible? Is it maybe
something in Strongswan that makes it forward incoming traffic out on the
Internet through the same interface?
---- Tobias Brunner skrev ----
Hi Dusan,
default
nexthop via 90.225 <tel:90.225>.x.x dev vlan845 weight 1
nexthop via 10.248 <tel:10.248>.x.x dev ppp0 weight 256
nexthop via 85.24 <tel:85.24>.x.x dev vlan847 weight 1
nexthop via 46.195 <tel:46.195>.x.x dev ppp1 weight 1
My gateway is configured to use 10.248.0 <tel:10.248.0>.x as "default route"
(highest
weight/priority), but when Strongswan tried to initiate the tunnel it
seems to always default too the last route, 46.195 <tel:46.195>.x.x, and this
wont
work as the remote peer is expecting 85.24 <tel:85.24>.x.x.
These kinds of multipath routes (via RTA_MULTIPATH) are currently not
supported by strongSwan when looking up source addresses/nexthops. The
kernel-netlink plugin only sees one of these via RTA_GATEWAY and
RTA_OIF. You could try to switch to the kernel's default route lookup
by setting either charon.install_routes=no (disables route installation
by strongSwan altogether, only works with 5.5.2 <tel:5.5.2>), or by setting
charon.plugins.kernel-netlink.fwmark
<http://charon.plugins.kernel-netlink.fwmark> to an arbitrary number not used
yet
as firewall mark (this works since 5.3.3 <tel:5.3.3>). However, I'm not sure if
that will return different values in RTA_GATEWAY/RTA_OIF or if it would
still be necessary to parse RTA_MULTIPATH. How exactly do these kind of
kind of multipath routes compare to multiple routes with different
priorities/metrics? In your case you have multiple paths with the same
weight, how is the actual nexthop/interface chosen by the kernel?
Round-robin? Random?
Regards,
Tobias
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
