IPsec Tunnel between OPN and UTM not working

[raider2k23]

Hi,

I try to get an IPsec Tunnel between a UTM (9.716) and ONSense 23.7.3

The log on UTM shows:

Code: [Select]

initiator cookie:
01 d6 0b 09 e4 37 be 33
responder cookie:
00 00 00 00 00 00 00 00
next payload type: ISAKMP_NEXT_SA
ISAKMP version: ISAKMP Version 1.0
exchange type: ISAKMP_XCHG_IDPROT
flags: none
message ID: 00 00 00 00
***emit ISAKMP Security Association Payload:
next payload type: ISAKMP_NEXT_VID
DOI: ISAKMP_DOI_IPSEC
****emit IPsec DOI SIT:
IPsec DOI SIT: SIT_IDENTITY_ONLY
****emit ISAKMP Proposal Payload:
next payload type: ISAKMP_NEXT_NONE
proposal number: 0
protocol ID: PROTO_ISAKMP
SPI size: 0
number of transforms: 1
*****emit ISAKMP Transform Payload (ISAKMP):
next payload type: ISAKMP_NEXT_NONE
transform number: 0
transform ID: KEY_IKE
******emit ISAKMP Oakley attribute:
af+type: OAKLEY_LIFE_TYPE
length/value: 1
[1 is OAKLEY_LIFE_SECONDS]
******emit ISAKMP Oakley attribute:
af+type: OAKLEY_LIFE_DURATION
length/value: 7800
******emit ISAKMP Oakley attribute:
af+type: OAKLEY_ENCRYPTION_ALGORITHM
length/value: 7
[7 is AES_CBC]
******emit ISAKMP Oakley attribute:
af+type: OAKLEY_HASH_ALGORITHM
length/value: 1
[1 is HMAC_MD5]
******emit ISAKMP Oakley attribute:
af+type: OAKLEY_KEY_LENGTH
length/value: 256
******emit ISAKMP Oakley attribute:
af+type: OAKLEY_AUTHENTICATION_METHOD
length/value: 1
[1 is pre-shared key]
******emit ISAKMP Oakley attribute:
af+type: OAKLEY_GROUP_DESCRIPTION
length/value: 5
[5 is MODP_1536]
emitting length of ISAKMP Transform Payload (ISAKMP): 36
emitting length of ISAKMP Proposal Payload: 44
emitting length of ISAKMP Security Association Payload: 56
out_vendorid(): sending [strongSwan]
***emit ISAKMP Vendor ID Payload:
next payload type: ISAKMP_NEXT_VID
emitting 16 raw bytes of V_ID into ISAKMP Vendor ID Payload
V_ID 88 2f e5 6d 6f d2 0d bc 22 51 61 3b 2e be 5b eb
emitting length of ISAKMP Vendor ID Payload: 20
out_vendorid(): sending [Cisco-Unity]
***emit ISAKMP Vendor ID Payload:
next payload type: ISAKMP_NEXT_VID
emitting 16 raw bytes of V_ID into ISAKMP Vendor ID Payload
V_ID 12 f5 f2 8c 45 71 68 a9 70 2d 9f e2 74 cc 01 00
emitting length of ISAKMP Vendor ID Payload: 20
out_vendorid(): sending [XAUTH]
***emit ISAKMP Vendor ID Payload:
next payload type: ISAKMP_NEXT_VID
emitting 8 raw bytes of V_ID into ISAKMP Vendor ID Payload
V_ID 09 00 26 89 df d6 b7 12
emitting length of ISAKMP Vendor ID Payload: 12
out_vendorid(): sending [Dead Peer Detection]
***emit ISAKMP Vendor ID Payload:
next payload type: ISAKMP_NEXT_VID
emitting 16 raw bytes of V_ID into ISAKMP Vendor ID Payload
V_ID af ca d7 13 68 a1 f1 c9 6b 86 96 fc 77 57 01 00
emitting length of ISAKMP Vendor ID Payload: 20
out_vendorid(): sending [RFC 3947]
***emit ISAKMP Vendor ID Payload:
next payload type: ISAKMP_NEXT_VID
emitting 16 raw bytes of V_ID into ISAKMP Vendor ID Payload
V_ID 4a 13 1c 81 07 03 58 45 5c 57 28 f2 0e 95 45 2f
emitting length of ISAKMP Vendor ID Payload: 20
out_vendorid(): sending [draft-ietf-ipsec-nat-t-ike-03]
***emit ISAKMP Vendor ID Payload:
next payload type: ISAKMP_NEXT_VID
emitting 16 raw bytes of V_ID into ISAKMP Vendor ID Payload
V_ID 7d 94 19 a6 53 10 ca 6f 2c 17 9d 92 15 52 9d 56
emitting length of ISAKMP Vendor ID Payload: 20
out_vendorid(): sending [draft-ietf-ipsec-nat-t-ike-02]
***emit ISAKMP Vendor ID Payload:
next payload type: ISAKMP_NEXT_VID
emitting 16 raw bytes of V_ID into ISAKMP Vendor ID Payload
V_ID cd 60 46 43 35 df 21 f8 7c fd b2 fc 68 b6 a4 48
emitting length of ISAKMP Vendor ID Payload: 20
out_vendorid(): sending [draft-ietf-ipsec-nat-t-ike-02_n]
***emit ISAKMP Vendor ID Payload:
next payload type: ISAKMP_NEXT_VID
emitting 16 raw bytes of V_ID into ISAKMP Vendor ID Payload
V_ID 90 cb 80 91 3e bb 69 6e 08 63 81 b5 ec 42 7b 1f
emitting length of ISAKMP Vendor ID Payload: 20
out_vendorid(): sending [draft-ietf-ipsec-nat-t-ike-00]
***emit ISAKMP Vendor ID Payload:
next payload type: ISAKMP_NEXT_NONE
emitting 16 raw bytes of V_ID into ISAKMP Vendor ID Payload
V_ID 44 85 15 2d 18 b6 bb cd 0b e8 a8 46 95 79 dd cc
emitting length of ISAKMP Vendor ID Payload: 20
emitting length of ISAKMP Message: 256
HA System: can not delete ha_state #10
2023:09:02-16:42:26 fw01 pluto[12839]: |
*received 40 bytes from 185.x.x.2:500 on eth4
**parse ISAKMP Message:
initiator cookie:
01 d6 0b 09 e4 37 be 33
responder cookie:
b0 25 be f0 20 51 d5 15
next payload type: ISAKMP_NEXT_N
ISAKMP version: ISAKMP Version 1.0
exchange type: ISAKMP_XCHG_INFO
flags: none
message ID: c3 c7 7c b7
length: 40
***parse ISAKMP Notification Payload:
next payload type: ISAKMP_NEXT_NONE
length: 12
DOI: ISAKMP_DOI_IPSEC
protocol ID: 1
SPI size: 0
Notify Message Type: NO_PROPOSAL_CHOSEN
packet from 185.x.x.2:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
info:
what is the problem? I´m new to OPNSense, just managed UTM or XG until now and these IPsec Tunnels were working fine

[Monviech (Cedrik)]

Notify Message Type: NO_PROPOSAL_CHOSEN

That means that in phase 1 of the ipsec connection there were no matching proposals. Both sides need the same proposals for the ike key exhange to happen.

A popular combination would be aes256-sha256-modp2048

You can also check the /var/log/ipsec/latest.log for the opnsense side of ipsec log messages.

I posted a working config sometime, its german though:

https://forum.opnsense.org/index.php?topic=33464.msg166383#msg166383

[raider2k23]

Hi,

ich habe es nun nach deiner Config versucht, aber erhalte noch immer den gleichen Fehler.

Hier die config des OPNSense:

Code: [Select]

# This file is automatically generated. Do not edit
connections {
    7cc9a15f-b7e6-411f-ad32-89b748b67332 {
        proposals = aes256-sha256-modp2048
        unique = replace
        aggressive = no
        version = 1
        mobike = no
        local_addrs = 185.32.xxx.2
        remote_addrs = 212.144.xxx.34
        encap = no
        rekey_time = 28800
        send_certreq = no
        keyingtries = 0
        local-dc55fd10-ae2f-4528-abbe-xxxxxxxxxxxx {
            round = 0
            auth = psk
            id = 185.32.xxx.2
        }
        remote-a701c8e0-8a2f-4301-9bb6-xxxxxxxxxxxx {
            round = 0
            auth = psk
            id = 212.144.xxx.34
        }
        children {
            212f8e76-5c22-4df2-a0e1-xxxxxxxxxxxx {
                reqid = 130
                esp_proposals = aes256-sha256-modp2048
                sha256_96 = no
                start_action = start
                close_action = none
                dpd_action = clear
                mode = tunnel
                policies = yes
                local_ts = 192.168.30.0/24,192.168.60.0/24,172.16.3.0/24,192.168.88.0/24
                remote_ts = 192.168.10.0/24,192.168.20.0/24,192.168.111.0/24
                rekey_time = 3600
                updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child 212f8e76-5c22-4df2-a0e1-e32bc299f6ef
            }
        }
    }
}
pools {
}
secrets {
    ike-1eb47195-1c2f-4b1c-a528-942b4504cf38 {
        id-0 = 185.32.xxx.2
        id-1 = 212.144.xxx.34
        secret = xxxxxxxxxxxx
}
}
Hier die Config der Sophos Policy:
IKE encryption AES 256
IKE authentication alogrithm SHA2 256
IKE SA lifetime 28800
IKE DH group group 14 MODP2048
IPsec encryption algorithm AES 256
IPsec authentication algorithm SHA2 256
IPsec Lifetime 3600
IPsec PFS group group 14 MODP2048
Strict policy off
compression off

Hast du noch eine Idee, woran es hängen könnte?

[Monviech (Cedrik)]

Can you post the part of the ipsec log of the opnsense where it shows the connection initiation until failure?

/var/log/ipsec/latest.log

[raider2k23]

Code: [Select]

[meta sequenceId="2729"] 08[ENC] <7cc9a15f-b7e6-411f-ad32-89b748b67332|1> generating ID_PROT request 0 [ SA V V V V V ]
[meta sequenceId="2730"] 08[NET] <7cc9a15f-b7e6-411f-ad32-89b748b67332|1> sending packet: from 185.32.xxx.2[500] to 212.144.xxx.34[500] (180 bytes)
[meta sequenceId="2731"] 04[NET] error writing to socket: Can't assign requested address
[meta sequenceId="2732"] 08[IKE] <7cc9a15f-b7e6-411f-ad32-89b748b67332|1> sending retransmit 1 of request message ID 0, seq 1
[meta sequenceId="2733"] 08[NET] <7cc9a15f-b7e6-411f-ad32-89b748b67332|1> sending packet: from 185.32.xxx.2[500] to 212.144.xxx.34[500] (180 bytes)
[meta sequenceId="2734"] 04[NET] error writing to socket: Can't assign requested address
[meta sequenceId="2735"] 08[IKE] <7cc9a15f-b7e6-411f-ad32-89b748b67332|1> sending retransmit 2 of request message ID 0, seq 1
[meta sequenceId="2736"] 08[NET] <7cc9a15f-b7e6-411f-ad32-89b748b67332|1> sending packet: from 185.32.xxx.2[500] to 212.144.xxx.34[500] (180 bytes)
[meta sequenceId="2737"] 04[NET] error writing to socket: Can't assign requested address
[meta sequenceId="2738"] 08[NET] <125> received packet: from 212.144.xxx.34[500] to 192.168.88.253[500] (256 bytes)
[meta sequenceId="2739"] 08[ENC] <125> parsed ID_PROT request 0 [ SA V V V V V V V V V ]
[meta sequenceId="2740"] 08[IKE] <125> no IKE config found for 192.168.88.253...212.144.xxx.34, sending NO_PROPOSAL_CHOSEN
[meta sequenceId="2741"] 08[ENC] <125> generating INFORMATIONAL_V1 request 1957370062 [ N(NO_PROP) ]
[meta sequenceId="2742"] 08[NET] <125> sending packet: from 192.168.88.253[500] to 212.144.xxx.34[500] (40 bytes)

[Monviech (Cedrik)]

<7cc9a15f-b7e6-411f-ad32-89b748b67332|1> sending packet: from 185.32.xxx.2[500] to 212.144.xxx.34[500] (180 bytes)
[meta sequenceId="2734"] 04[NET] error writing to socket: Can't assign requested address

Is the IP Address 185.32.xxx.2 really bound to the WAN interface of the Opnsense?

meta sequenceId="2738"] 08[NET] <125> received packet: from 212.144.xxx.34[500] to 192.168.88.253[500] (256 bytes)

Here it looks like the Opnsense is behind a NAT, is that true?

[raider2k23]

so now I have found one Issue, I´ve had the WAN IP with no virtual IP for public IP, so with the private IP it couldn´t work..
but now a new Issue, "no connection has been authorized with policy=PSK"

Code: [Select]

2023:09:03-14:20:14 fw01 pluto[30529]: |af+type: OAKLEY_AUTHENTICATION_METHOD
2023:09:03-14:20:14 fw01 pluto[30529]: | length/value: 1
2023:09:03-14:20:14 fw01 pluto[30529]: | ******parse ISAKMP Oakley attribute:
2023:09:03-14:20:14 fw01 pluto[30529]: | af+type: OAKLEY_LIFE_TYPE
2023:09:03-14:20:14 fw01 pluto[30529]: | length/value: 1
2023:09:03-14:20:14 fw01 pluto[30529]: | ******parse ISAKMP Oakley attribute:
2023:09:03-14:20:14 fw01 pluto[30529]: | af+type: OAKLEY_LIFE_DURATION
2023:09:03-14:20:14 fw01 pluto[30529]: | length/value: 31680
2023:09:03-14:20:14 fw01 pluto[30529]: | preparse_isakmp_policy: peer requests PSK authentication
2023:09:03-14:20:14 fw01 pluto[30529]: packet from 185.32.xxx.2:263: initial Main Mode message received on 212.144.xxx.34:500 but no connection has been authorized with policy=PSK
2023:09:03-14:20:35 fw01 pluto[30529]: |
2023:09:03-14:20:35 fw01 pluto[30529]: | *received 40 bytes from 185.32.xxx.2:500 on eth4
2023:09:03-14:20:35 fw01 pluto[30529]: | **parse ISAKMP Message:
2023:09:03-14:20:35 fw01 pluto[30529]: | initiator cookie:
2023:09:03-14:20:35 fw01 pluto[30529]: | 3b c5 b5 fc d6 1b 00 f5
2023:09:03-14:20:35 fw01 pluto[30529]: | responder cookie:
2023:09:03-14:20:35 fw01 pluto[30529]: | cc 39 11 b9 d1 3a 21 b8
2023:09:03-14:20:35 fw01 pluto[30529]: | next payload type: ISAKMP_NEXT_N
2023:09:03-14:20:35 fw01 pluto[30529]: | ISAKMP version: ISAKMP Version 1.0
2023:09:03-14:20:35 fw01 pluto[30529]: | exchange type: ISAKMP_XCHG_INFO
2023:09:03-14:20:35 fw01 pluto[30529]: | flags: none
2023:09:03-14:20:35 fw01 pluto[30529]: | message ID: eb e0 75 f2
2023:09:03-14:20:35 fw01 pluto[30529]: | length: 40
2023:09:03-14:20:35 fw01 pluto[30529]: | ***parse ISAKMP Notification Payload:
2023:09:03-14:20:35 fw01 pluto[30529]: | next payload type: ISAKMP_NEXT_NONE
2023:09:03-14:20:35 fw01 pluto[30529]: | length: 12
2023:09:03-14:20:35 fw01 pluto[30529]: | DOI: ISAKMP_DOI_IPSEC
2023:09:03-14:20:35 fw01 pluto[30529]: | protocol ID: 1
2023:09:03-14:20:35 fw01 pluto[30529]: | SPI size: 0
2023:09:03-14:20:35 fw01 pluto[30529]: | Notify Message Type: NO_PROPOSAL_CHOSEN
2023:09:03-14:20:35 fw01 pluto[30529]: packet from 185.32.xxx.2:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
2023:09:03-14:20:35 fw01 pluto[30529]: | info:

[Monviech (Cedrik)]

Now comes the fun part that everybody has to do when creating IPsec tunnels between different vendors, and everybody hates the same.

Keep the log open on both sides and change settings until it works.

Make sure that the local and remote ID on both sides are the same. And that the IPsec PSK is actually matching on phase1 on both sides. It looks like the UTM cant match the psk to the ipsec policy.

[raider2k23]

ok, it seems to be the NATing problem.

On UTM it is possilbe to masq private WAN IP to Public IP.. is this possible on OPNsense too?

WAN private IP 192.168.88.253 / Public IP 185.230.xxx.2.. how can I translate private IP to public? The solution with virtual IP assigned to WAN interface didn´t work

[Monviech (Cedrik)]

Of course it's possible. Thats in Firewall: NAT: Outbound.

I don't understand why you would need that though. The Opnsense should have a public IP on its WAN interface. Thats the endpoint of the IPsec tunnel.

If one side is behind NAT (So for example there is a router in front of the Opnsense that NATs the public IP to an internal IP and the Opnsense is behind that Router and has an internal IP on its WAN interface) , you need to enable NAT Traversial and probably UDP Encapsulation on both sides for the IPSec Tunnel.
Edit
And you have to set the Site thats behind NAT to Start so it initiates the connection and the Site without NAT to TRAP so it acts as a responder only.

Edit: It looks like an infrastructure problem. I can't continue to help cause there are too many unknown factors involved. It's not an IPsec problem.

[raider2k23]

The wan should have public IP, thats why I want to NAT it on the OPNsense from private to public IP.
The router in front of OPNsense is a Mikrotik. May I hve to setup NAT on it to do some sort of exposed-host from Mikrotik to OPNsense?