<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thanks for the solution.<br>
IPv6 problem can be solved in a very similar way—by sending Router
Advertisement to the Router Solicitation.<br>
<a class="moz-txt-link-freetext"
href="https://wiki.strongswan.org/issues/817#note-4">https://wiki.strongswan.org/issues/817#note-4</a><br>
<br>
I think I'll add these Windows oddities to wiki.<br>
<br>
On 06/15/2016 10:14 AM, Peter Bieringer wrote:<br>
<blockquote
cite="mid:a6784f2d-5396-4777-1bc7-256c2aba9309@bieringer.de"
type="cite">
<pre wrap="">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:
</pre>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>
<a class="moz-txt-link-freetext" href="https://lists.strongswan.org/mailman/listinfo/users">https://lists.strongswan.org/mailman/listinfo/users</a></pre>
</blockquote>
<br>
</body>
</html>