[strongSwan] Support of forwarding of client DHCP requests in strongswan?

[Peter Bieringer]

Hi all,

problem solved by following workaround (IP addresses are examples,
server has 172.16.1.254 and clients out of 172.16.1.0/24):

1) patching ISC DHCP daemon to be usable also on tunnel interfaces like
ipsec0 (small patch, basic code is already included for "infiniband"
support), attached

2) create DHCP config which overwrites the default route of W10 by 2
more narrowed routes:
	0.0.0.0/1 via 172.16.1.254
	128.0.0.0/1 via 172.16.1.254

by using DHCP option
    ms-classless-static-routes 1, 0, 172, 16, 1, 254, 1, 128, 172, 16,
1, 254;

3) configuring following startup-actions in strongswan
3a) configure an IPv4 address on the ipsec0 interface
3b) start patched DHCP daemon with related config

4) watch with tcpdump on ipsec0

5) Connect with Windows (Phone) 10 via IKEv2, see incoming DHCP inform
request (see original posting) and outgoing DHCP inform response:

08:13:20.551382 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 328)
    172.16.1.254.bootps > 172.16.1.1.bootpc: BOOTP/DHCP, Reply, length
300, htype 8, hlen 0, xid ***, secs 1536, Flags [none]
	  Client-IP 172.16.1.1
	  Vendor-rfc1048 Extensions
	    Magic Cookie ***
	    DHCP-Message Option 53, length 1: ACK
	    Server-ID Option 54, length 4: 172.16.1.254
	    Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Classless-Static-Route-Microsoft Option 249, length 12:
(0.0.0.0/1:172.16.1.254),(128.0.0.0/1:172.16.1.254)

6) tcpdump should now show a lot of traffic, much more than without
sending the routes via DHCP inform response.


Open issues: if IPv6 is also available on the link (e.g. WLAN or via
Cellular Data) then IPv6 traffic is bypassing VPN - but that is a
general VPN topic, heard that also commercial VPN clients (at least for
Windows) have such issues, too.


If strongswan team is interested to have this documented in detail in
the strongswan Wiki, please point me to the (new) page where to add.

I would also add the attached ISC DHCP daemon patch there.

Hope this helps!

Regards,
	Peter


Am 06.06.2016 um 07:41 schrieb Peter Bieringer:
> Hi Michael,
> 
> IPv4 address is already passed to WP10 by strongswan and accepted
> withouth external DHCP.
> 
> The problem is that WP10 (and I would assume also other Windows System)
> is starting afterwards on the new link "DCHP Inform" to get additional
> information, and this can't be served by strongswan so far as I can see
> and therefore need to be catched and forwarded to a sophisticated DHCP
> server.
> 
> And in my scenario (Split Tunneling = false) I want to feed new routes
> into WP10 via DCHP response to "Classless-Static-Route-Microsoft".
> 
> Regards,
> 	Peter
> 
> Am 05.06.2016 um 21:56 schrieb Michael Schwartzkopff:
>> Am Sonntag, 5. Juni 2016, 19:41:30 schrieb Peter Bieringer:
>>> Hi,
>>>
>>> after some hours of playing around and digging through Google I need now
>>> support...
>>>
>>> Initial problem: Windows Phone 10 VPN client where "Split Tunneling =
>>> false" can't be set (unlike Windows 10 where Powershell command will help)
>>>
>>> Probable solution: distribute routes to WP 10 via DHCP reply by
>>> responding with proper routes to the received DHCP inform message:
>>>
>>> Received on ipsec0 interface (tcpdump):
>>>
>>>     172.16.1.1.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request,
>>> length 300, htype 8, hlen 0, xid 0x5b8e69a6, secs 1536, Flags [none]
>>> 	  Client-IP 172.16.1.1
>>> 	  Vendor-rfc1048 Extensions
>>> 	    Magic Cookie 0x63825363
>>> 	    DHCP-Message Option 53, length 1: Inform
>>> 	    Client-ID Option 61, length 17: "***"
>>> 	    Hostname Option 12, length 13: "Windows-Phone"
>>> 	    Vendor-Class Option 60, length 8: "MSFT 5.0"
>>> 	    Parameter-Request Option 55, length 6:
>>> 	      Domain-Name-Server, Netbios-Name-Server, Vendor-Option, Subnet-Mask
>>> 	      Classless-Static-Route-Microsoft, Domain-Name
>>>
>>>
>>> But I get now stucked, I haven't found any solution so far to feed this
>>> DHCP message received via ipsec0 to a DHCP server (tried ISC and dnsmasq
>>> listening on a tap interface with iptables NAT PREROUTING hints).
>>> dhcrelay also won't work, interface ipsec0 is not liked by any dhcp
>>> server...
>>>
>>> Has anyone a working example for strongswan how to feed DHCP client
>>> messages received after IPsec is established to a DCHP server and
>>> respond proper with additional information?
>>>
>>> e.g. something like a broadcast forwarding/snooper based on layer 2.
>>>
>>> BTW: IPsec setup is IKEv2, system is running on Virtuozzo, so briding of
>>> interfaces is not an option, only tun/tap interfaces are available.
>>
>> As far as I understand, IKE2 should be possible to hand out it own IP 
>> adresses. 
>>
>> See:
>> https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp
>> https://wiki.strongswan.org/projects/strongswan/wiki/Dhcpplugin
>>
>> Is this an otion in your setup? Or do the IP addresses really have to be 
>> passed on to the central DHCP server?
>>
>> Mit freundlichen Grüßen,
>>
>> Michael Schwartzkopff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dhcp-4.2.5.patched.diff
Type: text/x-patch
Size: 2550 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160615/294119f1/attachment.bin>