[strongSwan] Routing on clients

Discussion:

Christian Salway

2018-08-07 07:07:59 UTC

Hello all,

After several months of using strongSwan, I still can't get the routing to work correctly on the clients. I have run out of pages to read on the strongswan website so I hope you can help me out.

The problem is when I connect to strongSwan, the routing is not configured correctly on the clients (OSX and Windows) - using native (built-in) clients. All updated with the latest patches/updates.

OSX will set up a route based on the local_ts but when I open a simultaneous connection to another strongSwan server, it removes the route from the first VPN connection and adds it's own based on the local_ts.

WINDOWS doesnt add the route at all.

In either cause, I normally have to manually add the routes in.

Has anyone had any success? Can they please shed some light as to how they achieved it?

Kind regards,

Christian Salway
IT Consultant - Naimuri

T: +44 7463 331432
E: ***@naimuri.com
A: Naimuri Ltd, Chandlers Point, Manchester M50 2UW

Christian Salway

2018-08-08 20:33:20 UTC

Permalink

So, I've just finished doing that and it's not working

I set up an IP alias because the DHCP wouldnt give out IP addresses unless I "owned" 172.31.0.x

-----------------------------------------------------------------------------------------------------------------------
#ifconfig eth0:0 172.31.0.1

eth0 Link encap:Ethernet HWaddr 0a:b6:4a:7d:61:a4
inet addr:10.0.1.193 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::8b6:4aff:fe7d:61a4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1
RX packets:127072 errors:0 dropped:0 overruns:0 frame:0
TX packets:76073 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:124506235 (124.5 MB) TX bytes:12274603 (12.2 MB)

eth0:0 Link encap:Ethernet HWaddr 0a:b6:4a:7d:61:a4
inet addr:172.31.0.1 Bcast:172.31.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1
-----------------------------------------------------------------------------------------------------------------------

I then installed isc-dhcp-server (had no luck with dnsmasq) and set up the dhcp config file like so

-----------------------------------------------------------------------------------------------------------------------
option rfc3442-classless-static-routes code 121 = array of integer 8;
option ms-classless-static-routes code 249 = array of integer 8;

ddns-update-style none;

default-lease-time 600;
max-lease-time 7200;

authoritative;

subnet 172.31.0.0 netmask 255.255.255.0 {
range 172.31.0.5 172.31.0.250;
option subnet-mask 255.255.255.0;

option rfc3442-classless-static-routes 24, 192, 168, 123, 10, 10, 10, 1;
option ms-classless-static-routes 24, 192, 168, 123, 10, 10, 10, 1;
}
-----------------------------------------------------------------------------------------------------------------------

and then configured ipsec

-----------------------------------------------------------------------------------------------------------------------
conn %default
ike=aes256-sha256-prfsha256-ecp256-modp2048-modp1024!
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2

leftfirewall=yes
rightsourceip=172.31.0.0/24
rightid=%any

conn localnet
leftid=localnet
leftsubnet=10.0.0.0/20
rightsourceip=%dhcp
authby=secret
auto=start
-----------------------------------------------------------------------------------------------------------------------
dhcp {

force_server_address = no
identity_lease = no
interface = eth0
load = yes
server = 172.31.255.255
}
-----------------------------------------------------------------------------------------------------------------------

..... which actually assigns IP addresses to clients (HUZZAH)

-----------------------------------------------------------------------------------------------------------------------
07[IKE] peer requested virtual IP %any
07[KNL] using 172.31.0.1 as address to reach 172.31.255.255/32
07[CFG] sending DHCP DISCOVER to 172.31.255.255
10[CFG] received DHCP OFFER 172.31.0.14 from 10.0.1.193
07[KNL] using 172.31.0.1 as address to reach 172.31.255.255/32
07[CFG] sending DHCP REQUEST for 172.31.0.14 to 10.0.1.193
11[CFG] received DHCP ACK for 172.31.0.14
07[IKE] assigning virtual IP 172.31.0.14 to peer '192.168.0.31'
-----------------------------------------------------------------------------------------------------------------------

- not quite, the routes arent passed through to the clients

-----------------------------------------------------------------------------------------------------------------------
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 84 0 en0
10/20 link#6 UCSc 0 0 utun2
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 28 7617856 lo0
169.254 link#6 UCS 0 0 en0
192.168.0 link#6 UCS 5 0 en0
192.168.0.1/32 link#6 UCS 1 0 en0
192.168.0.1 40:d:10:73:1f:90 UHLWIir 26 26 en0 1196
192.168.0.10 f4:5f:d4:fb:24:4a UHLWI 0 86 en0 1127
192.168.0.23 dc:a9:4:2a:21:db UHLWI 0 4 en0 60
192.168.0.24 3c:cd:93:6d:78:32 UHLWI 0 8 en0 1122
192.168.0.31/32 link#6 UCS 0 0 en0
192.168.0.42 a4:77:33:b2:d7:34 UHLWIi 1 779 en0 1038
192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 1 en0
224.0.0/4 link#6 UmCS 2 0 en0
224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 314 en0
255.255.255.255/32 link#6 UCS 0 0 en0

-----------------------------------------------------------------------------------------------------------------------
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.2.2 10.0.2.15 25
10.0.2.0 255.255.255.0 On-link 10.0.2.15 281
10.0.2.15 255.255.255.255 On-link 10.0.2.15 281
10.0.2.255 255.255.255.255 On-link 10.0.2.15 281
18.130.229.77 255.255.255.255 10.0.2.2 10.0.2.15 26
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
172.31.0.0 255.255.0.0 On-link 172.31.0.1 26
172.31.0.1 255.255.255.255 On-link 172.31.0.1 281
172.31.255.255 255.255.255.255 On-link 172.31.0.1 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 10.0.2.15 281
224.0.0.0 240.0.0.0 On-link 172.31.0.1 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 10.0.2.15 281
255.255.255.255 255.255.255.255 On-link 172.31.0.1 281
===========================================================================
Persistent Routes:
None
-----------------------------------------------------------------------------------------------------------------------

Hello Christian,
I guess the native Mac OSX client just doesn't support being connected to more than one server, so this can't be solved with it.
For Windows, you need to setup and run a DHCP server on the VPN server, which answers the DHCP requests that Windows (uniquely and only Windows!) sends over the VPN. You can use that to push routes to the client. Just use the same options as with "real" DHCP clients, requesting configuration from/on the LAN. This is described in the article about Windows interoperability[1].
[1] https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#Split-routing-on-Windows-10-and-Windows-10-Mobile <https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#Split-routing-on-Windows-10-and-Windows-10-Mobile>
Kind regards
Noel

Post by Christian Salway
Hello all,
After several months of using strongSwan, I still can't get the routing to work correctly on the clients. I have run out of pages to read on the strongswan website so I hope you can help me out.
The problem is when I connect to strongSwan, the routing is not configured correctly on the clients (OSX and Windows) - using native (built-in) clients. All updated with the latest patches/updates.
OSX will set up a route based on the local_ts but when I open a simultaneous connection to another strongSwan server, it removes the route from the first VPN connection and adds it's own based on the local_ts.
WINDOWS doesnt add the route at all.
In either cause, I normally have to manually add the routes in.
Has anyone had any success? Can they please shed some light as to how they achieved it?
Kind regards,
*Christian Salway*
IT Consultant - *Naimuri*
T: +44 7463 331432
A: Naimuri Ltd, Chandlers Point, Manchester M50 2UW

Christian Salway

2018-08-09 06:07:47 UTC

Permalink

Perhaps the answer is to set the attr DHCP to the IP of the DHCP server inside the VPN but then still, how does the client know how to route to the IP address.

There doesn’t seem to be a solution for this even though all the parts are there.

Christian Salway

2018-08-09 08:16:45 UTC

Permalink

Hi Noel,

If I am providing a Virtual IP to the client, why would the client then request from a DHCP server....

I thought maybe I could set DHCP(6) in attr but its not supported by Windows....

# Win10 supports ADDR(1) DNS(3) NBNS(4) SRV ADDR6(8) DNS6(10) SRV6
# OSX supports ADDR DHCP(6) DNS MASK(2) ADDR6 DHCP6(12) DNS6 DNS_DOMAIN(25)

You say "You must *not* use the dhcp plugin of strongSwan to request the IP" then what is the option rightsourceip=%dhcp for?

Have you had any success at this working and have the configuration because I spent a *solid* 20 hours yesterday and countless days before trying to get this to work.

Kind regards,

Christian Salway
IT Consultant - Naimuri

T: +44 7463 331432
E: ***@naimuri.com
A: Naimuri Ltd, Chandlers Point, Manchester M50 2UW

It's because you're doing it wrong. You must *not* use the dhcp plugin of strongSwan to request the IP. Have Windows do a DHCP request over the VPN (according to the article it should do that). The dhcp plugin does something completely different.

Post by Christian Salway
Perhaps the answer is to set the attr DHCP to the IP of the DHCP server inside the VPN but then still, how does the client know how to route to the IP address.
There doesnât seem to be a solution for this even though all the parts are there.

Christian Salway

2018-08-09 11:30:00 UTC

Permalink

https://wiki.strongswan.org/issues/1098 <https://wiki.strongswan.org/issues/1098>

Tobias Brunner <https://wiki.strongswan.org/users/8> almost 3 years <https://wiki.strongswan.org/projects/strongswan/activity?from=2015-09-07> ago

Status changed from New to Feedback
Priority changed from High to Normal
There is a DHCP plugin <https://wiki.strongswan.org/projects/strongswan/wiki/DHCPPlugin> to assign virtual IPs and DNS servers to clients that are requested by the strongSwan server via DHCP on behalf of the clients. If you are considering DHCP over IPsec there is a configuration attribute called INTERNAL_IP4_DHCP but strongSwan has no support for that as client (i.e. it won't request it). And as server you can only assign it globally via the attr <https://wiki.strongswan.org/projects/strongswan/wiki/Attrplugin> or the attr-sql <https://wiki.strongswan.org/projects/strongswan/wiki/Attrsql> plugins. Also

Kind regards,

Christian Salway
IT Consultant - Naimuri

T: +44 7463 331432
E: ***@naimuri.com
A: Naimuri Ltd, Chandlers Point, Manchester M50 2UW

Christian Salway

2018-08-10 07:23:53 UTC

Permalink

Sorry to upset you. It's all very frustrating when their isn't enough clear documentation available.

Windows wasn't sending any DHCP requests through the CHILD_SA however it doesn't matter because it turns out the leftsubnet gets added to the routing table. So where I had the VPN server on 10.0.0.0/20 and the inner network on 10.0.64.0/20 and the clients on 172.31.0.0/20, the clients couldnt route through to 10.0.64.0/20 without manually adding a route in windows. However, if I set the clients in the 10.0.64.0/20 subnet, then they can route through
leftsubnet=10.0.64.0/20
rightsourceip=10.0.76.5-10.0.79.254
Will be a problem when a clients network is also on the same subnet, but for now, it solves the problem.

Kind regards,

Christian Salway
IT Consultant - Naimuri

T: +44 7463 331432
E: ***@naimuri.com
A: Naimuri Ltd, Chandlers Point, Manchester M50 2UW

What do you intend to say with that? I already wrote that what Windows does has nothing to do with the "dhcp" plugin.
Look, I did not participate in the developing of the Windows Agile VPN client and I also don't know why they did it. I just tell you how it is.
After the CHILD_SA is up, Windows starts sending DHCP DISCOVER messages over the CHILD_SA. That's what it does. I don't know *why* it does that and/or who thought that was a good idea, but it does that.
It does *not* do anything over IKE and it has *no* relation to what the "dhcp" plugin of strongSwan does (which is the *responder* (*not* the inititator) requesting an IP and DNS/WINS settings over DHCP).

Post by Christian Salway
https://wiki.strongswan.org/issues/1098
Tobias Brunner <https://wiki.strongswan.org/users/8> almost 3 years <https://wiki.strongswan.org/projects/strongswan/activity?from=2015-09-07> ago
* *Status* changed from /New/ to /Feedback/
* *Priority* changed from /High/ to /Normal/
There is a DHCP plugin <https://wiki.strongswan.org/projects/strongswan/wiki/DHCPPlugin> to _assign virtual IPs and DNS servers to clients_ that are requested by the strongSwan server via DHCP on behalf of the clients. If you are considering DHCP over IPsec there is a configuration attribute called |INTERNAL_IP4_DHCP| but strongSwan has no support for that as client (i.e. it won't request it). And as server you can only assign it globally via the attr <https://wiki.strongswan.org/projects/strongswan/wiki/Attrplugin> or the attr-sql <https://wiki.strongswan.org/projects/strongswan/wiki/Attrsql> plugins. Also
Kind regards,
*Christian Salway*
IT Consultant - *Naimuri*
T: +44 7463 331432
A: Naimuri Ltd, Chandlers Point, Manchester M50 2UW