<div dir="ltr"><div><div><div><div>So, I put mark=%unique and local broadcast 255.255.255.255 to ipsec.conf.<br>But for my tests, local broadcasg 255.255.255.255 was necessary to put to leftsubnet only and enough so.<br>I didn' t put 255.255.255.255 to rightsubnet and I didn' t put net broadcast 192.168.0.255 to any subnets all worked.<br><br>But there are 2 questions again. :)<br><br>First: <br>Double password query is appeared. That is thw right password at my Win7 connection, but after it passes for the first time, there is<br><br>parsed IKE_AUTH request 2 [ EAP/RES/MSCHAPV2 ]<br>05[IKE] EAP-MS-CHAPv2 username: '%any'<br>05[IKE] no EAP key found for hosts '%any' - '%any'<br>05[IKE] EAP-MS-CHAPv2 verification failed, retry (1)<br>10[MGR] ignoring request with ID 2, already processing<br>05[ENC] generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]<br><br>and password query is appeared again and after pass password secondly connection is established.<br>There wasn' t it before.<br>Quite strange, I turned forecast off but such doubled passwording remained.<br>But I didn' t change anything except settings for forecast, even I discarded left and rightsubnets to state before.<br><br>Second: Intinially there is no nbns at strongswan.conf, that is Wins server is not appeared at Windows client connection properties.<br>But after 'reinject' value is set, Wins server is appeared at appropriate properties.<br>Moreover, after comment out the value and reistablishing connection, Wins server is not disappeared.<br></div><div>And after comment out all plug-in values, Wins server remained at properties.<br></div>Is it right behaviour ? I think no.<br></div>I disabled forecast at load line at strongswan.conf. After it without reinject turning on, Wins server is not appeared.<br></div><div>But after second time connection is appeared again.<br><br></div><div>By the way, Wins presented or not at Windows connection properties changes NetBios behaviour quite strong.<br></div><div>As following, it it very important.<br></div></div><div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2015-01-23 11:52 GMT+03:00 Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
> 0.2131s / 2079 times in lock created at: dumping 7 stack frame addresses:<br>
> /usr/lib/ipsec/libstrongswan.so.0 @ 0xb7708000 [0xb774aee5]<br>
<br>
</span>This is a lock profiler backtrace. It is usually required only if you<br>
want to find lock bottlenecks, but for normal operation/testing you<br>
should build without the --enable-lock-profiler ./configure option.<br>
<br>
> leftsubnet=<a href="http://192.168.0.0/24" target="_blank">192.168.0.0/24</a><br>
> rightsourceip=192.168.0.201-192.168.0.215<br>
<br>
First, the forecast plugin requires that you set mark=%unique on the<br>
connection you want to forward broadcasts to/from. Second, your traffic<br>
selectors must include the broadcast/multicast addresses you want to<br>
forward in each direction, as IPsec policy matching is still in place.<br>
Refer to the configuration of moon in the forecast test case [1] for an<br>
example. Windows sends some broadcasts as 255.255.255.255 over the IPsec<br>
tunnel, so you might want to include that address as well.<br>
<br>
Regards<br>
Martin<br>
<br>
[1]<a href="http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=f1c218d6" target="_blank">http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=f1c218d6</a><br>
<br>
</blockquote></div><br></div></div></div></div></div></div>