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

[ValdikSS]

Thanks for the solution.
IPv6 problem can be solved in a very similar way—by sending Router Advertisement to the Router Solicitation.
https://wiki.strongswan.org/issues/817#note-4

I think I'll add these Windows oddities to wiki.

On 06/15/2016 10:14 AM, Peter Bieringer wrote:
> 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:
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160824/dd6af94c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160824/dd6af94c/attachment.sig>