Project

General

Profile

Issue #3176

strongSwan-Windows routing troubles when accessing server's physical IP address

Added by Alexey Ivanov 10 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Category:
interoperability
Affected version:
5.8.1
Resolution:
No change required

Description

I have some troubles with strongswan-windows connection.
I need protected connection between hosts:
linux-10.7.0.4
windows server 2019 - 10.2.0.4. (Virtual IP - 10.8.0.8)

Windows connects properly and shows "connected", but seems as if policy doesn't work.

When I ping 10.8.0.8 I see (using wireshark) inbound ESP packets and ICMP on VPN interface (both: request/reply), but seems as if windows doesn't know that packets to 10.7.0.4 must be encrypted. If I try to ping 10.7.0.4 packets go unencrypted.
When I set metric to 1 for VPN interface I can see ICMP requests to 10.7.0.4 on VPN interface but nothing on real one.

https://pastebin.com/u/koraven


Related issues

Has duplicate Issue #3255: Split Tunneling on Windows 10Closed

History

#1 Updated by Tobias Brunner 10 months ago

  • Category changed from windows to interoperability
  • Status changed from New to Feedback

Windows might not be able to protect data sent to the server's physical IP (other clients, e.g. macOS, can't do that either because they explicitly route that traffic directly). So try adding a virtual IP to the server (just assign an IP to any local interface and adjust local_ts accordingly). Also read the notes on split-tunneling with Windows here.

#2 Updated by Alexey Ivanov 10 months ago

Tobias Brunner wrote:

Windows might not be able to protect data sent to the server's physical IP (other clients, e.g. macOS, can't do that either because they explicitly route that traffic directly). So try adding a virtual IP to the server (just assign an IP to any local interface and adjust local_ts accordingly). Also read the notes on split-tunneling with Windows here.

Thanks. It works.
But I think it makes sense to update documentation on this page (or may be I missed something there).
https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients
I spent about two days trying to understand if my server configuration is right or not and trying to configure routes on windows. And after all the solution is that simple.
I think it might save a lot of time for other people.

#3 Updated by Tobias Brunner 10 months ago

  • Subject changed from Strongswan-Windows routing troubles to strongSwan-Windows routing troubles when accessing server's physical IP address
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

But I think it makes sense to update documentation on this page (or may be I missed something there).

I guess many people don't access the VPN server directly but use the connection to reach other hosts/the Internet. I also wonder if it's a general problem or maybe related to the /32 traffic selector (i.e. if it would work if everything is routed via VPN server). Anyway, I added a note on said page.

I spent about two days trying to understand if my server configuration is right or not and trying to configure routes on windows. And after all the solution is that simple.
I think it might save a lot of time for other people.

They might find this issue.

#4 Updated by Alexey Ivanov 10 months ago

I guess many people don't access the VPN server directly but use the connection to reach other hosts/the Internet. I also wonder if it's a general problem or maybe related to the /32 traffic selector (i.e. if it would work if everything is routed via VPN server). Anyway, I added a note on said page.

It is host-to-host case, right? It is on strongswan github page and really useful in my case.

Thank you very much

#5 Updated by Tobias Brunner 10 months ago

It is host-to-host case, right? It is on strongswan github page and really useful in my case.

Well, the agile VPN client in Windows is not really designed for host-to-host scenarios, but rather for classic roadwarrior setups (i.e. host-to-net or host-to-everything). There are other IPsec clients built-in, though (e.g. in the advanced firewall). I'm also not sure how the server editions differ here, but I imagine there might be even more options.

#6 Updated by Tobias Brunner 8 months ago

  • Has duplicate Issue #3255: Split Tunneling on Windows 10 added

Also available in: Atom PDF