Project

General

Profile

Issue #3686

Site to clients IPsec and private IP

Added by Cyril DUBUS 8 months ago. Updated 8 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.9.1
Resolution:

Description

Hi,

I'm trying to configure IPsec to work in a "one server multiple clients" scenario to encrypt an UDP exchange on port 37809

I've read https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp and https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection and at this point, I'm not able to find a solution on my own.

My scenario

My clients can be linux OS, windows OS and routers like mikrotiks or ursalink routers. They all can be behind a NAT or directly connected to the internet.
My server is a linux server with strongswan

My problem

The only way I managed to make IPsec work was by using the private IP of my clients on the "leftsourceip" configuration field. But since this is private IP, two clients can have the same private IP and it will fail on server side (?) Or worse, when a client change its IP (by just reconnecting to another wifi for example) then the configuration client side is becoming obsolete because the private IP is part of the configuration.

I tried to distribute a VirtualIP with IPsec but it's not adding the IP by itself to the interface (at least on linux, I have to add it manually) and for the other clients (embedded) I don't know what will be the behavior with the VirtualIP. I would like the experience to be as light as possible.

I feel like I'm missing something or I got something wrong. Did I ? What would be the right way to configure IPsec in my case ?

Configurations

Server side :

config setup
    charondebug="ike 1, knl 1, cfg 0" 
    uniqueids=no

conn ikev2-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    esp=aes256-sha256-modp4096!
    ike=aes256-sha256-modp4096!
    rekey=no
    left=a.b.c.d # public IP
    leftsourceip=a.b.c.d # public ip
    leftid=@server-name
    leftcert=server.crt
    leftsendcert=always
    leftauth=pubkey
    leftprotoport=17/37809
    right=%any
    rightsourceip=%config
    rightid=%any
    rightauth=pubkey
    rightprotoport=17/37809

Client side :

config setup
    charondebug="ike 1, knl 1, cfg 0" 
    uniqueids=no

conn ikev2-vpn
    auto=route
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    esp=aes256-sha256-modp4096!
    ike=aes256-sha256-modp4096!
    rekey=no
    right=server.url
    rightid=%any
    rightauth=pubkey
    rightprotoport=17/37809
    left=%defaultroute
    leftid=%any
    leftauth=pubkey
    leftcert=user.crt
    leftsendcert=always
    leftprotoport=17/37809
    leftsourceip=10.0.0.60 # private IP

As a reminder, the above configuration is working and my traffic is encrypted, but I need to put in my private IP and I fear it will cause me some troubles later.

Many thanks !

History

#1 Updated by Tobias Brunner 8 months ago

  • Status changed from New to Feedback

If there is a chance of conflicts, this probably won't work without virtual IPs (i.e. assign an IP from a distinct subnet to your clients and don't use their real private IPs). While the connmark plugin could maybe help (if you'd use Transport Mode), it probably needs assistance from the application so response traffic is properly marked (see the section about Windows L2TP there).

#2 Updated by Cyril DUBUS 8 months ago

Thank you for your answer. I'll have a look into conntrack as a last resort because I'm not really comfortable with that (I have no control on the application side and on what goes through that UDP connexion)

I tried for the past few days to setup properly a configuration where IPsec distribute a VirtualIP to my clients (I don't really need it but at least I'm sure there won't be any conflicts) and all the traffic get encrypted, but I failed doing so.

Here is my current server configuration :

config setup
    charondebug="ike 1, knl 1, cfg 0" 
    uniqueids=no

conn ikev2-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    esp=aes256-sha256-modp4096!
    ike=aes256-sha256-modp4096!
    rekey=no
    left=a.b.c.d #server public ip
    leftsourceip=10.253.0.1
    leftid=@a.b.c.d
    leftcert=server.crt
    leftsendcert=always
    leftauth=pubkey
    leftprotoport=17/37809
    right=%any
    rightsourceip=10.253.0.2-10.253.0.10
    rightid=%any
    rightauth=pubkey
    rightprotoport=17/37809

And here is a current client configuration :

config setup
    charondebug="ike 1, knl 1, cfg 0" 
    uniqueids=no

conn ikev2-vpn
    auto=start
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    esp=aes256-sha256-modp4096!
    ike=aes256-sha256-modp4096!
    rekey=no
    right=server.url
    rightid=%any
    rightauth=pubkey
    rightprotoport=17/37809
    left=%defaultroute
    leftid=%any
    leftauth=pubkey
    leftcert=user.crt
    leftsendcert=always
    leftprotoport=17/37809
    leftsourceip=%config

The IPsec tunnel is comming up and the IP is distributed (10.253.0.2 for example) to the client and installed on the right interface. But when I start a communication on port udp/37809 it does not go through the tunnel.

I think this is because the tunnel is between 10.253.0.2/32 <=> a.b.c.d/32 and my local communication is between 10.0.0.60/32 <=> a.b.c.d/32 (with 10.0.0.60/32 being the private IP of the card). I tried a lot to play with subnet to understand what they do but I feel like I only need a tunnel between simple /32 IP since I don't want to route anything into that tunnel. I just want my connexion between my multiple clients and my server being encrypted.

I tried some stuff with the routing and with the POSTROUTING table and I think I may be able to get it but again, is it the right way to to some odd network stuff like that ? Or Am I missing something in my understanding and my configuration files ?

Thanks

#3 Updated by Tobias Brunner 8 months ago

The IPsec tunnel is comming up and the IP is distributed (10.253.0.2 for example) to the client and installed on the right interface. But when I start a communication on port udp/37809 it does not go through the tunnel.

Oh, I forgot. That won't work directly because if you configure protocol/port, there won't be a route in table 220 that forces the virtual IP as source (because that affects all traffic, not just that for the configured protocol/port, strongSwan doesn't automatically install such route).

I tried some stuff with the routing and with the POSTROUTING table and I think I may be able to get it but again, is it the right way to to some odd network stuff like that ? Or Am I missing something in my understanding and my configuration files ?

Yeah, you could NAT to the virtual IP (e.g. only the traffic with that protocol/port) or you could install your own route (maybe in a separate table with a routing rule that, based on e.g. marks, only affects traffic with that protocol/port). Or you don't configure left|rightprotoport, so a route is installed, and configure a mark instead, which you then set on matching traffic via iptables.

#4 Updated by Cyril DUBUS 8 months ago

Thank you again for your detailled answer.

I glad to see I'm not completely off ;) I think I can figure it out on Linux with iptables, but I really worry about my other clients such as Windows Clients or specific devices like industrial routers. For industrial routers ... there is not much we can do but pray but do you have any idea for windows clients ?

Have a nice day

#5 Updated by Tobias Brunner 8 months ago

there is not much we can do but pray but do you have any idea for windows clients ?

If you can't use random/arbitrary ports on one side, you are basically in the same boat as the L2TP users on Windows (i.e. see connmark again). You might want to consider using IPv6 to avoid the NAT issue.

#6 Updated by Cyril DUBUS 8 months ago

Ok thanks, seeing the experimental solution, I would have say the same hell ^^

#7 Updated by Cyril DUBUS 8 months ago

Quick update for future readers, it worked with that rule on client side :

iptables -t nat -A POSTROUTING -o eth0 -p udp --dport 37809 -j SNAT --to-source 10.253.0.2

Also available in: Atom PDF