Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - ServerCat

Pages: [1]

Virtual private networks / Re: ipsec rekeying not working

« on: April 09, 2024, 02:32:21 pm »

I have it! Im using Ubuntu as an client. The Network-Manager Addon don't use the Perfect Forward Secrecy (PFS) by default. This mean no DH Group have to be configurated in the server side proposal settings. This was the reason for proposal missmatching.

So i can either use the "insecure" aes256-sah256 proposal on the server in the child or define an proposal on client side. On Ubuntu is a little bit hidden, on the bottom of Identity Tab, click at Algorithms.

PFS description on strongswan website https://docs.strongswan.org/docs/5.9/config/rekeying.html

German - Deutsch / Re: IKEv2 läuft mit Windows aber nicht mit Android

« on: April 04, 2024, 04:57:25 pm »

Sieht für mich ganz in Ordnung aus. Kann schon sein mit dem IP6. Du hast jedoch keinen v6 Pool definiert. Lösch am besten den ::/0 Eintrag aus dem Child heraus.
Eventuell könnte das an den Policies liegen. Im Dashboard unter "VPN->IPsec-> Security Policy Database" Wenn du mit dem Android verbindest sollten dort zwei Einträge erstellt werden.
source <Pool-IP>, destination 0.0.0.0/0[any] und umgekehrt
source 0.0.0.0/0[any] , destination <Pool-IP>

Wenn das so erstellt wird sollte ipsec richtig funktionieren. Falls dann trotzdem der Ping in dein 192.168.1.0/24 Netz nicht geht, würde ich auf Firwall-Rules tippen.

German - Deutsch / Re: IKEv2 läuft mit Windows aber nicht mit Android

« on: April 03, 2024, 08:57:00 am »

Hi,

Ich nehme an du verwendest die neue Konfiguraton, die mit den Connections? Kannst du die swanctl.conf mal posten?

Code: [Select]

cat /usr/local/etc/swanctl/swanctl.conf

Virtual private networks / ipsec rekeying not working

« on: April 02, 2024, 06:32:13 pm »

The IPsec tunnel dont rekeying. So after 1 hour the connection get lost.

The Server log some proposal problem.

Code: [Select]

2024-04-02T17:58:06	Informational	charon	16[CFG] < 2de0136f-6cbc-421a-80aa-3729176f844e|421> configured proposals: ESP:AES_GCM_16_256/MODP_2048/NO_EXT_SEQ	
2024-04-02T17:58:06	Informational	charon	16[CFG] < 2de0136f-6cbc-421a-80aa-3729176f844e|421> received proposals: ESP:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQ

The client log the same.

This is the config.

Code: [Select]

# This file is automatically generated. Do not edit
connections {
    2de0136f-6cbc-421a-80aa-3729176f844e {
        proposals =  aes256gcm16-sha256-modp2048
        unique = no
        aggressive = no
        version = 2
        mobike = no
        local_addrs = my.address.com
        encap = yes
        rekey_time = 600
        dpd_delay = 30
        pools = PoolA
        send_certreq = yes
        keyingtries = 0
        local-fc3a7fbe-732d-4ee4-890b-f725d40125e8 {
            round = 0
            auth = pubkey
            id = my.address.com
            certs = 654269e2e801b.crt
        }
        remote-544f43ac-e76a-4d3a-9db6-57ff389b5b0f {
            round = 0
            auth = eap-radius
            id = ConnectionA
            eap_id = %any
            groups = GroupA
        }
        children {
            cab66875-3b0a-456c-ab01-e5af7fd9a621 {
                esp_proposals = aes256gcm16-sha256-modp2048
                sha256_96 = no
                start_action = trap|start
                close_action = trap
                dpd_action = clear
                mode = tunnel
                policies = yes
                local_ts = 192.168.10.0/24,192.168.100.0/24,192.168.50.0/24
                rekey_time = 3600
                updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child cab66875-3b0a-456c-ab01-e5af7fd9a621
            }
        }
    }
}
pools {
    PoolA {
        addrs = 10.30.150.0/24
        dns = 192.168.10.1
    }
}
secrets {
}
# Include config snippets
include conf.d/*.conf

I have been tryed diffrent child proposals. But i didn't can find a right one. In my opinion there is an match with AES_GCM_16_256.

Any ideas?

Virtual private networks / Re: IPsec blocked for multiple User on Connection

« on: March 25, 2024, 12:25:07 pm »

It seems that I have solved the problem. I like to share the solution.
The mistake was in the child and the definition of the remote_ts. Because i define an network, strongswan was creating an policy for it.
192.168.10.0/24 192.168.100.0/24 192.168.50.0/24 === 10.30.150.0/24
When an other client connect. The same policy was created. Then two policies was there with the same IP-addresses. I think for the IPsec server it was not possible to distinguish to which client an answer, eg to 10.30.150.1 should be sent. I assume that the policy is taken with the first match to 10.30.150.0/24. And it seems so with the last one created.
The solution is just, clean the "Remote" feld in the children selection. This end up that the remote_ts entry is no more reprensent into the swanctl.conf.

Code: [Select]

        children {
            cab66875-3b0a-456c-ab01-e5af7fd9a621 {
                esp_proposals = aes256-sha256-modp2048,aes256gcm16-modp2048,aes256gcm16-ecp521,aes256gcm16-x25519,aes256gcm16-x448,aes128gcm16-modp2048,aes128gcm16-ecp521,aes128gcm16-x25519,aes128gcm16-x448,aes256gcm16-sha256-x25519,aes256gcm16-sha256-x448
                sha256_96 = no
                start_action = trap|start
                close_action = trap
                dpd_action = clear
                mode = tunnel
                policies = yes
                local_ts = 192.168.10.0/24,192.168.100.0/24,192.168.50.0/24

                rekey_time = 600
                updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child cab66875-3b0a-456c-ab01-e5af7fd9a621
            }

With this config, the policies look like,
192.168.10.0/24 192.168.100.0/24 192.168.50.0/24 === 10.30.150.1/32
192.168.10.0/24 192.168.100.0/24 192.168.50.0/24 === 10.30.150.2/32

And everything works.

Virtual private networks / IPsec blocked for multiple User on Connection

« on: March 21, 2024, 10:56:16 am »

Hello

I am new here and hope you are all doing well!

I face an problem with an IPsec implementation. It is probably due to the configuration. As a basis I followed this : guidehttps://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html

Implementaion:
I created two Connections and distinguish with the id Value in the Remote Authentication wihch connection is used. The Authentication is with EAP over Radius. The Radius put the Group into the Class Object. I just need to create an group with the same name on the firewall. I can also chose this group in the Groups field in the Remote authentication.

Til here everything work well. I can login with user in groupA and have access to the networks, wihch defined in Child of Connection A. Same with user in groupB

The problem:
I can understand this as follows

1. An User_A1 connect to ConnectionA.
2. Everthing work. User_A can access all the networks they definded.
2. User_A2 connect to ConnectionA. (Then 2 User are connected)
3. User_A1 can now no longer reach the networks. It looks as if the VPN is blocked. But User_A2 can work.
4. When User_A2 disconnect. Then User_A can work agin.

It looks as if the connection is passed on from user_A to user_B. When he logs out again, the connection is returned to user_A.

Wath i tryed:
May be strongswan looks every user as the same, because %any is in the EAP Identity. But in the leases section on the OPNsense GUI, every user have an own ip address from the pool. Into the docs i found (https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html) "EAP or XAuth authentication is involved, the EAP-Identity or XAuth username is used to enforce the uniqueness policy instead." I tryed diffrent values for <conn>.unique. But nothing changed.

I played around with start_action and dpd_action. But nothing changed.

The swanctl.conf

Code: [Select]

# This file is automatically generated. Do not edit
connections {
    2de0136f-6cbc-421a-80aa-3729176f844e {
        proposals = aes256gcm16-sha256-modp2048,aes256gcm16-sha512-modp2048,aes256gcm16-sha512-x25519,aes256gcm16-sha512-x448,aes256gcm16-sha256-modp4096,aes256gcm16-sha256-modp6144,aes256gcm16-sha256-modp8192,aes256gcm16-sha512-modp4096,aes256gcm16-sha512-modp6144,aes256gcm16-sha512-modp8192
        unique = no
        aggressive = no
        version = 2
        mobike = no
        local_addrs = my.address.com
        encap = yes
        rekey_time = 600
        dpd_delay = 30
        pools = PoolA
        send_certreq = yes
        keyingtries = 0
        local-fc3a7fbe-732d-4ee4-890b-f725d40125e8 {
            round = 0
            auth = pubkey
            id = my.address.com
            certs = 654269e2e801b.crt
        }
        remote-544f43ac-e76a-4d3a-9db6-57ff389b5b0f {
            round = 0
            auth = eap-radius
            id = ConnectionA
            eap_id = %any
            groups = GroupA
        }
        children {
            cab66875-3b0a-456c-ab01-e5af7fd9a621 {
                esp_proposals = aes256-sha256-modp2048,aes256gcm16-modp2048,aes256gcm16-ecp521,aes256gcm16-x25519,aes256gcm16-x448,aes128gcm16-modp2048,aes128gcm16-ecp521,aes128gcm16-x25519,aes128gcm16-x448,aes256gcm16-sha256-x25519,aes256gcm16-sha256-x448
                sha256_96 = no
                start_action = trap|start
                close_action = trap
                dpd_action = clear
                mode = tunnel
                policies = yes
                local_ts = 192.168.10.0/24,192.168.100.0/24,192.168.50.0/24
                remote_ts = 10.30.150.0/24
                rekey_time = 600
                updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child cab66875-3b0a-456c-ab01-e5af7fd9a621
            }
        }
    }
    2591fb58-5dad-43d9-a103-9d7b7c7da312 {
        proposals = aes256-sha256-modp2048,aes256gcm16-sha256-modp2048,aes256gcm16-sha256-x25519,aes256gcm16-sha512-x25519,aes256gcm16-sha256-x448,aes256gcm16-sha512-x448
        unique = replace
        aggressive = no
        version = 2
        mobike = no
        local_addrs = my.address.com
        encap = yes
        rekey_time = 2400
        dpd_delay = 30
        pools = PoolB
        send_certreq = yes
        local-5aaf9149-b04e-4a70-90cf-de79dec755c6 {
            round = 0
            auth = pubkey
            id = my.address.com
            certs = 654269e2e801b.crt
        }
        remote-c624fb9c-4af8-4942-97ee-2f2bcc66a161 {
            round = 0
            auth = eap-radius
            id = ConnectionB
            eap_id = %any
            groups = GroupB
        }
        children {
            d07262da-5444-4a2d-aaf9-63867367459d {
                esp_proposals = aes256-sha256-modp2048,aes256gcm16-x25519,aes256gcm16-x448,aes128gcm16-x25519,aes128gcm16-x448,aes256gcm16-sha256-modp4096,aes256gcm16-sha256-x25519,aes256gcm16-sha256-x448
                sha256_96 = no
                start_action = start
                close_action = none
                dpd_action = clear
                mode = tunnel
                policies = yes
                local_ts = 192.168.10.0/24,192.168.100.0/24
                remote_ts = 10.30.151.0/24
                rekey_time = 3500
                updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child d07262da-5444-4a2d-aaf9-63867367459d
            }
        }
    }
}
pools {
    PoolA {
        addrs = 10.30.150.0/24
        dns = 192.168.10.1
    }
    PoolB {
        addrs = 10.30.151.0/24
        dns = 192.168.10.1
    }
}
secrets {
}
# Include config snippets
include conf.d/*.conf

Versions: OPNsense 24.1.4-amd64 and strongswan package 5.9.13_1

Pages: [1]