push routes to clients

[mw-cyrano]

As documented here, one can configure a NAT to the server's private network.

Works fine. But by default, the vpn clients aren't given a static route to this network via DHCP. So they don't know about it and try to reach the private network via their default gateway, not to the vpn server.

The builtin xl2tpd dhcp would need a SendOption for that or it needs to be disabled and you'd need a separate DHCP server.

What's the best practice for this? I checked the man pages and didn't find an option for either way.

[hwdsl2]

@mw-cyrano Hello! Unfortunately I am not sure about this. Please ask in the relevant community or the Libreswan/strongSwan users mailing list. As you mentioned, the current working solution is to configure a NAT for this use case.

[mw-cyrano]

No, there is no working solution, as you'd have to configure the route to the network on each client, which isn't even possible on Mac via the graphical interface. How do others in the project work around this? I feel as if I'm missing something here, as the project is rather useless without a workaround for this.

[hwdsl2]

Others are welcome to comment on this issue if you have thoughts. @mw-cyrano When I tested this using these instructions I added [1], I did not need to add static routes on the VPN clients for it to work. By default, when connected to the VPN, clients send all traffic through the VPN server, so the NAT rules added should take care of this.

[1] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/advanced-usage.md#access-vpn-servers-subnet

[mw-cyrano]

By default, when connected to the VPN, clients send all traffic through the VPN server, so the NAT rules added should take care of this.

That is one way to configure it, but you'll route all traffic including the video conferences through your company network, which is unnecessary and a bottle neck.

We usually configure a VPN only for our internal services. So the default route doesn't point into the VPN.

But it is good to know, that you're using the project with a default route and that explains at least, why you don't experience this issue and why there's no solution for this.

I've read at multiple locations online, that you'd have to configure a proper DHCP server, as ipsec can't push routes.

Could we leave this open as a bug? Maybe I can open a new one and properly phrase it, so we leave unnecessary info out of it?

[hwdsl2]

@mw-cyrano That makes sense. Yes I can leave this open for a period of time, so others have a chance to comment if they have thoughts on your use case.

[letoams]

On Sun, 13 Nov 2022, Lin Song wrote: Others are welcome to comment on this issue if you have thoughts. @mw-cyrano When I tested this using these instructions I added [1], I did not need to add static routes on the VPN clients for it to work. By default, when connected to the VPN, clients send all traffic through the VPN server, so the NAT rules added should take care of this.

Instead of 0.0.0.0/0 you can set a smaller network to split the tunnel for only corporate resources. Specifying more than one subnet currently is tricky and might not work for all cases.

[mw-cyrano]

The NAT is not the problem. You can NAT an arbitrary amount of networks on the server. The problem are the routes on the clients. They do not know anything about the company's private IP space.

Example:
transport network in the vpn: 192.168.42.0/24
company network: 10.99.0.0/16

A vpn client will have a routing table like this:
default via <your home router's ip>
192.168.42.1 dev ppp0 #device route vpn adapter
via <home router's ip>

And that's about it. Everything destined to 10.99.0.0/16 will go along the default route. Not your vpn server, as the clients do not know the route. Yes, you can set them manually, but proprietary solutions like Sophos do not require that. They push the routes via DHCP-options. And I fail to do that as xl2tpd brings a crippled DHCP server, that doesn't seem to be able to do that.

Cross reference: xelerance/xl2tpd#251

[wilkolazki]

This superuser answer suggest using Add-VpnConnectionRoute to achieve this goal.

I have incorporated this in the client setup script by adding:

echo Setting routes...
powershell -command "Add-VpnConnectionRoute -ConnectionName '%conn_name%' -DestinationPrefix 172.26.0.0/16"
if !errorlevel! neq 0 (
  echo ERROR: Could not set routing configuration for the IKEv2 VPN connection.
  goto :Done
)

... after Set-VpnConnectionIPsecConfiguration call.

This way was able to add a route to my nework, but the windows vpn client still tried to push all traffic throgh VPN.
I needed to alter the call to Add-VpnConnection that creates the connection by adding -SplitTunneling parameter:

echo Creating VPN connection...
powershell -command "Add-VpnConnection -ServerAddress '%server_addr%' -Name '%conn_name%' -TunnelType IKEv2 -AuthenticationMethod MachineCertificate -EncryptionLevel Required -PassThru -SplitTunneling "

Now I can access the Internet directly and my remote subnet via VPN.

[mw-cyrano]

This again seems to be a client based workaround. We have that working, we are not looking for a workaround. We are trying to resolve the issue properly. And the proper solution is to push the routes from the dhcp-server. And therefore we need to setup a proper DHCP-server. But we can't, because xl2tpd has this documented layer violation and provides a buildin dhcp server. I am looking for a way to use isc-dhcp, kea or systemd-dhcp with xl2tpd.

[hwdsl2]

Thanks all for contributing ideas. @mw-cyrano For your use case (split tunneling and push routes to clients), it looks like the VPN setup scripts couldn't support it, as the issue may be on the xl2tpd side. I see that you've opened xelerance/xl2tpd#251. I'll go ahead and close this issue, you can follow up on the linked xl2tpd issue.