Điểm:1

Server

Strongswan / Ipsec multiple roadwarrior connections different subnets

Flo

10:22, 30/07/2023

I'm trying to setup a StrongSwan VPN Server which should host multiple (Windows 10 - internal vpn client) roadwarrior connections, but different subnets, depending on the clients certificate.

root@VPN:/# ipsec version

Linux strongSwan U5.8.2/K5.4.0-26-generic

My setup has 2 pairs of public and private key, using a different CNs let's say vpn-dev.mycom.com and vpn-liv.mycom.com. The used ipsec.conf looks something like this:

conn vpn-dev
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    rekey=no
    ikelifetime=25200s
    leftid=vpn-dev.mycom.com
    leftcert=server-cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=10.100.0.0/16-10.100.254.254/16
    rightdns=8.8.8.8,8.8.4.4
    rightsendcert=never
    rightcert=ca-cert.pem
    eap_identity=%identity
    ike=aes128-sha1-modp1024


conn vpn-liv
    also=vpn-dev
    leftid=vpn-liv.mycom.com
    leftcert=liv-server-cert.pem
    rightsourceip=10.200.0.0/16-10.200.254.254/16
    rightcert=liv-ca-cert.pem

both certificate keys are also stored in the ipsec.secrets

vpn-dev.mycom.com : RSA "server-key.pem"
vpn-liv.mycom.com : RSA "liv-server-key.pem"

someuser : EAP "somepassword"

However as soon as i try to connect to the strongswan instance, the vpn-dev connection is used and strongswan is not switching to conn vpn-liv

here are the logs during a try:

Mar 30 08:47:48 VPN charon: 16[NET] received packet: from X.X.X.X[64558] to X.X.X.X[500] (1084 bytes)
Mar 30 08:47:48 VPN charon: 16[IKE] received MS NT5 ISAKMPOAKLEY v9 vendor ID
Mar 30 08:47:48 VPN charon: 16[IKE] received MS-Negotiation Discovery Capable vendor ID
Mar 30 08:47:48 VPN charon: 16[IKE] X.X.X.X is initiating an IKE_SA
Mar 30 08:47:48 VPN charon: 16[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Mar 30 08:47:48 VPN charon: 16[IKE] local host is behind NAT, sending keep alives
Mar 30 08:47:48 VPN charon: 16[IKE] remote host is behind NAT
Mar 30 08:47:48 VPN charon: 16[NET] sending packet: from X.X.X.X[500] to X.X.X.X[64558] (328 bytes)
Mar 30 08:47:48 VPN charon: 06[NET] received packet: from X.X.X.X[64596] to X.X.X.X[4500] (576 bytes)
Mar 30 08:47:48 VPN charon: 10[NET] received packet: from X.X.X.X[64596] to X.X.X.X[4500] (576 bytes)
Mar 30 08:47:48 VPN charon: 05[NET] received packet: from X.X.X.X[64596] to X.X.X.X[4500] (576 bytes)
Mar 30 08:47:48 VPN charon: 14[NET] received packet: from X.X.X.X[64596] to X.X.X.X[4500] (368 bytes)
Mar 30 08:47:48 VPN charon: 14[IKE] received cert request for "CN=PRIV VPN LIV CA"
Mar 30 08:47:48 VPN charon: 14[IKE] received 69 cert requests for an unknown ca
Mar 30 08:47:48 VPN charon: 14[CFG] looking for peer configs matching X.X.X.X[%any]...X.X.X.X[192.168.0.117]

Mar 30 08:47:48 VPN charon: 14[CFG] selected peer config 'vpn-dev' # << here it has not selected vpn-live, even if the earlier provided private key is only matching vpn-live

Mar 30 08:47:48 VPN charon: 14[IKE] initiating EAP_IDENTITY method (id 0x00)
Mar 30 08:47:48 VPN charon: 14[IKE] peer supports MOBIKE
Mar 30 08:47:48 VPN charon: 14[IKE] authentication of 'vpn-dev.mycom.com' (myself) with RSA     signature successful
Mar 30 08:47:48 VPN charon: 14[IKE] sending end entity cert "CN=vpn-dev.mycom.com"
Mar 30 08:47:49 VPN charon: 14[IKE] sending cert request for "CN=PRIV VPN DEV CA"
Mar 30 08:47:49 VPN charon: 14[IKE] sending cert request for "CN=PRIV VPN LIV CA"
Mar 30 08:47:49 VPN charon: 14[NET] sending packet: from X.X.X.X[500] to X.X.X.X[64548] (364 bytes)
Mar 30 08:47:49 VPN charon: 06[NET] received packet: from X.X.X.X[64618] to X.X.X.X[4500] (92 bytes)
Mar 30 08:47:49 VPN charon: 06[IKE] received (28) error notify

the goal is basically to host 2 vpn endpoints on one machine but provide different ip ranges depending on the login / used certificate.

The local configuration is done with (powershell)

Import-Certificate -FilePath liv-ca-cert.pem -CertStoreLocation 'Cert:\LocalMachine\Root'
Add-VpnConnection -Name 'LIV VPN' -ServerAddress 'vpn-live.mycom.com' -AuthenticationMethod Eap -IdleDisconnectSeconds 43200

am i missing something? is my setup misconfigured? or is this simply not possible with strongswan and windows 10 internal vpn client?

172

0 + 0

bức tường lửa

chia sẻ file

chuyển tiếp

thiên nga mạnh mẽ

điểm đến trang web vpn

Điểm:0

Server

Flo

14:44, 30/07/2023

Hóa ra không thể sử dụng chứng chỉ vì chúng không được sử dụng để xác định người dùng trên máy chủ.

Vì vậy, cuối cùng tôi đã sử dụng một giải pháp thay thế được mô tả trong câu trả lời này giúp đánh giá các eap_identity.

Giờ đây, khách hàng của tôi sử dụng cùng một chứng chỉ, nhưng dựa trên thông tin đăng nhập, tôi có thể quyết định họ sẽ sử dụng mạng con nào.

Ipsec.conf của tôi bây giờ trông giống như thế này:

kết nối eap-chia sẻ
   loại = đường hầm
   ike=aes128-sha1-modp1024
   rightauth=eap-mschapv2
   leftcert=server-cert.pem

kết nối eap-init
   also=eap-shared
   # cấu hình này được sử dụng để thực hiện trao đổi EAP-Identity và
   # xác thực máy khách và máy chủ
   eap_identity=%identity
   # sau đây được sử dụng để buộc chuyển đổi kết nối sau
   # xác thực hoàn tất
   rightgroups=thisseemsirrelevant
   auto=thêm

conn eap-liv
   also=eap-shared
   eap_identity=*@liv-some-domain.com
   rightsourceip=10.200.0.0/16-10.200.254.254/16
   auto=thêm

kết nối eap-dev
   also=eap-shared
   eap_identity=*@dev-some-domain.com
   rightsourceip=10.100.0.0/16-10.100.254.254/16
   auto=thêm

có thể không phải là giải pháp tao nhã nhất nhưng hoạt động trong trường hợp của tôi.

0 + 0

Điểm:0

Server

Lin

08:28, 12/09/2023

Đối với nhiều cấu hình kết nối với cùng một phương thức xác thực, Strongswan có thể chọn cấu hình phù hợp dựa trên danh tính của khách hàng.

Sử dụng hai cấu hình kết nối chẳng hạn:

Cả hai bên phải sử dụng pubkey, chúng ta có thể sử dụng phảica như ràng buộc:

    liên kết dev-network_ikev2-cert
        rightauth=pubkey
        rightca="C=CN, O=Sample, CN=Develop CA"
        rightsourceip=10.100.0.0/16
        rightdns=8.8.8.8
    
    kết nối kiểm tra-mạng_ikev2-cert
        rightauth=pubkey
        rightca="C=CN, O=Mẫu, CN=CA đang kiểm tra"
        rightsourceip=10.200.0.0/16
        rightdns=8.8.8.8

Trong thiết lập này, khách hàng có chứng chỉ do Phát triển CA sẽ chọn cấu hình dev-network_ikev2-cert trực tiếp.
Nếu khách hàng sử dụng chứng chỉ do Kiểm tra CA, Strongswan trước tiên sẽ chọn cấu hình dev-network_ikev2-cert, sau đó xuất kiểm tra ràng buộc không thành công: ngang hàng không được xác thực bởi CA 'C=CN, O=Sample, CN=Develop CA', và chọn cái tiếp theo kiểm tra-mạng_ikev2-cert.

Cả hai bên phải sử dụng eap-mschapv2, chúng ta có thể sử dụng eap_identity như ràng buộc:

    kết nối dev-network_ikev2-eap
        rightauth=eap-mschapv2
        eap_identity=*@dev.com
        rightsourceip=10.100.0.0/16
        rightdns=8.8.8.8
    
    kết nối kiểm tra-mạng_ikev2-eap
        rightauth=eap-mschapv2
        eap_identity=*@test.com
        rightsourceip=10.200.0.0/16
        rightdns=8.8.8.8

Đây là phương pháp được sử dụng bởi Flo. Strongswan sẽ thực hiện logic kiểm tra tương tự như sử dụng pubkey.

Nếu khách hàng sử dụng danh tính trong *@test.com, Strongswan trước tiên sẽ chọn dev-mạng_ikev2-eap, sau đó tìm thấy rằng kiểm tra ràng buộc không thành công: bắt buộc phải có danh tính EAP '*@dev.com', và chọn cái tiếp theo kiểm tra-mạng_ikev2-eap.

Hy vọng điều này sẽ giúp.

0 + 0

Điểm:0

Server

ecdsa

13:05, 30/07/2023

Chỉ có thể chuyển đổi kết nối dựa trên nhận dạng/chứng chỉ máy chủ nếu một trong hai

các máy khách gửi một danh tính từ xa (IDr) trong yêu cầu IKE_AUTH của họ, điều mà nhiều máy khách không có (đặc biệt là Windows), nếu không, không có danh tính nào phù hợp, vì vậy kết nối đầu tiên sẽ được sử dụng

hoặc

nếu FQDN ánh xạ tới các địa chỉ IP khác nhau, có thể được định cấu hình làm địa chỉ cục bộ cho các kết nối để sớm chọn kết nối chính xác

0 + 0

Flo

14:34, 30/07/2023

điều đó chỉ đúng một phần [như tôi đã học ở đây](https://serverfault.com/questions/908098/strongswan-clients-access-rights). Bằng cách sử dụng giải pháp thay thế `rightgroups`, bạn có thể sử dụng thuộc tính `eap_identity` để xác định người dùng.

Hồi đáp

ecdsa

08:30, 31/07/2023

Bạn có thể muốn đọc lại câu hỏi của chính mình;) Rõ ràng là về việc chọn cấu hình dựa trên danh tính/chứng chỉ máy chủ, không phải danh tính máy khách. (Ngoài ra, nếu bạn không chú ý, tôi đã viết câu trả lời khác :)

Hồi đáp

Flo

09:08, 31/07/2023

xin lỗi vì đã có sự hiểu lầm, tôi đang nói về các chứng chỉ được khách hàng sử dụng như tôi đã nói với "tùy thuộc vào chứng chỉ đăng nhập/đã sử dụng" - cũng như các cấu hình có thể cho biết với `rightcert`

Hồi đáp

ecdsa

09:21, 31/07/2023

Các máy khách không sử dụng bất kỳ chứng chỉ nào để tự xác thực, cho dù với cấu hình cũ hay mới của bạn. Dù sao đi nữa, cài đặt `rightcert` đó sẽ phá vỡ cấu hình của bạn vì không có ứng dụng khách nào sẽ xác thực bằng chứng chỉ CA thực tế. Nếu bạn muốn khách hàng xác thực bằng chứng chỉ do một CA (trung gian) cụ thể cấp, thì cài đặt chính xác sẽ là `rightca`, nhưng sau đó `rightauth` cũng sẽ phải được đặt thành `pubkey` hoặc `eap-tls` và không phải `eap-mschapv2`. Và khách hàng rõ ràng sẽ yêu cầu các khóa/chứng chỉ riêng lẻ và cấu hình phù hợp.

Hồi đáp

Flo

10:08, 31/07/2023

điều đó rõ ràng với tôi bây giờ, nhưng không phải là quan điểm của tôi. Dẫu sao cũng xin cảm ơn.

Hồi đáp

Phan Văn Trường

Câu hỏi này là trong các ngôn ngữ khác:

EN: Strongswan / Ipsec multiple roadwarrior connections different subnets

TH: Strongswan / Ipsec เชื่อมต่อ Roadwarrior หลายเครือข่ายย่อยที่แตกต่างกัน

RO: Strongswan / Ipsec conexiuni multiple roadwarrior diferite subrețele

RU: Strongswan / Ipsec несколько соединений roadwarrior с разными подсетями

VI: Strongswan / Ipsec multiple roadwarrior connections different subnets

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.