[strongSwan] Tunnels with dynamic IP and another route issue
dusan at comhem.se
Thu Apr 27 00:43:02 CEST 2017
I tried something like this, so that only the VPN-client subnet are
marked differently from ordinary traffic on vlan847, but it doesn't seem
iptables -t mangle -I PREROUTING -s VPN-clientIP -i vlan847 -m policy
--dir in --pol ipsec --proto esp -j M
ARK --set-mark 0x200/0xf00
Below is the rule that I would like to reference, cause this rule uses
the correct WAN-interface.
122: from all fwmark 0x200/0xf00 lookup WAN2
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,
> 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,
>>> 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?
>> Users mailing list
>> Users at lists.strongswan.org
More information about the Users