Hi, No. As I previously wrote, this is a system intrinsic problem.
Kind regards Noel On 25.09.2017 15:03, Aleksey Kravchenko wrote: > Hello. I managed to solve the problem with routes on windows and macos. For > this purpose, a second white IP was used. > p.s. Are there any ways or tricks to solve this problem with the same IP > address? > > 2017-09-14 11:03 GMT+03:00 Aleksey Kravchenko <[email protected] > <mailto:[email protected]>>: > > Hello, Noel. Thanks for the answer. Unfortunately, there is no way to > bypass.As a solution we can use the second white IP for Strongswan, and the > web server on the 1st IP. > > 2017-09-13 22:17 GMT+03:00 Noel Kuntze > <[email protected] > <mailto:[email protected]>>: > > Hi, > > That is because Windows and MacOS implement crappy route based IPsec > which conceptually can not protect traffic to the IKE peer's > address (unless policy based routing is used, which neither Windows > nor MacOS implement). > > Kind regards > > Noel > > On 13.09.2017 17:14, Aleksey Kravchenko wrote: > > Hello.I need your advice. > > The work of Strongswan + IKEv2 is configured. Everything works fine > (on iOS, macOS, windows, linux), but I noticed strange behavior in VPN's > work. There is a server on which Strongswan and Nginx are installed.When you > connect to the VPN and go to the site which is located in the same place as > the strongswan daemon, the nginx log shows different addresses for > connections. For instance:android / linux -> login from the address issued by > the VPN (for example, 192.168.1.2). > > windows / macos -> login from the usual address (provider address). > > But if you go to the IP detection server, the result for all > devices is the same: you logged in from the VPN server.Maybe you have any > thoughts about this? Thank you! > > >
signature.asc
Description: OpenPGP digital signature
