ancwrd1
commented
4 months ago Hello, could you try the IPSec tunnel with the latest version? I am not sure the SSL tunnel could be used with both certificate and password authentication at the same time.
Closed Znuff closed 4 months ago
ancwrd1
commented
4 months ago Hello, could you try the IPSec tunnel with the latest version? I am not sure the SSL tunnel could be used with both certificate and password authentication at the same time.
Znuff
commented
4 months ago I've tried IPSec with all versions, in all of them I'm getting "No CCC session in reply!":
2024-07-31T13:52:52.086915Z TRACE isakmp::transport: Received message: IsakmpMessage {
cookie_i: 15121821750522300887,
cookie_r: 17469804346980390903,
version: 16,
exchange_type: Transaction,
flags: IsakmpFlags(
ENCRYPTION,
),
message_id: 6985227,
payloads: [
Hash(
BasicPayload {
data: b"\xd1\xabE*\x9f\x9bx\x18\xac\x07y\xcdA\xea\x90'\x97\x92d.",
},
),
Attributes(
AttributesPayload {
attributes_payload_type: Request,
identifier: 41718,
attributes: [
DataAttribute {
attribute_type: 13,
value: Short(
0,
),
},
DataAttribute {
attribute_type: 18,
value: Long(
b"Certificate authentication completed successfully.\npassword: \0(msg_obj\n\t:format (1.0)\n\t:id (VPN_CUMULATE_PROMPT)\n\t:def_msg (\"Certificate authentication completed successfully.\npassword: \")\n\t:arguments (\n\t\t:0 (\n\t\t\t:type (msg_obj)\n\t\t\t:val (msg_obj\n\t\t\t\t:format (1.0)\n\t\t\t\t:def_msg (\"Certificate authentication completed successfully.\n\")\n\t\t\t\t:arguments (\n\t\t\t\t\t:0 (\n\t\t\t\t\t\t:type (string)\n\t\t\t\t\t\t:val (\"[cert_info]\")\n\t\t\t\t\t)\n\t\t\t\t)\n\t\t\t)\n\t\t\t:def_text (\"Certificate authentication completed successfully.\n\")\n\t\t)\n\t\t:1 (\n\t\t\t:type (msg_obj)\n\t\t\t:val (msg_obj\n\t\t\t\t:format (1.0)\n\t\t\t\t:id (CPSC_INTERNAL_ENTER_PASSWORD)\n\t\t\t\t:def_msg (\"password: \")\n\t\t\t\t:arguments ()\n\t\t\t)\n\t\t\t:def_text (\"password: \")\n\t\t)\n\t)\n\t:authentication_state (new_factor)\n)\n",
),
},
DataAttribute {
attribute_type: 15,
value: Long(
b"",
),
},
],
},
),
],
}
2024-07-31T13:52:52.087057Z DEBUG isakmp::ikev1::service: End sending OM request
2024-07-31T13:52:52.087536Z DEBUG isakmp::transport: Sending ISAKMP message of size 80 to SERVER_IP:500
2024-07-31T13:52:52.087568Z TRACE isakmp::transport: Sending message: IsakmpMessage {
cookie_i: 15121821750522300887,
cookie_r: 17469804346980390903,
version: 16,
exchange_type: Informational,
flags: IsakmpFlags(
0x0,
),
message_id: 1251997944,
payloads: [
Delete(
DeletePayload {
doi: 0,
protocol_id: Isakmp,
spi_size: 16,
spi: [
b"\xd1\xdb\x80\xc3d\xa8I\xd7",
b"\xf2q6~\x9dWW\xf7",
],
},
),
Hash(
BasicPayload {
data: b"8\xf3\xa2\x1b\xe1S\xa1\x02n(f\x946\xc3\xe1[\xf8\xb9XR",
},
),
],
}
Error: No CCC session in reply!The message seems to suggest that it's waiting for a password, too (CPSC_INTERNAL_ENTER_PASSWORD).
ancwrd1
commented
4 months ago Ok thanks, I will have a look into it. So far the cert+pwd wasn't a common authentication combination. Should be relatively simple to fix.
ancwrd1
commented
4 months ago Could you please try the issue29-cert-pwd branch and see if it works?
Znuff
commented
4 months ago I can confirm this works in ipsec mode!
ancwrd1
commented
4 months ago Ok thanks, I will create a new release.
As per title, my server responds with:
I'm trying to use something like:
I've tried with version 2.0.2, 2.1.0, 2.2.0 and latest 2.2.7, and none worked.
The initial server reply is:
2.0.2returns:2.1.0and2.2.0return:While
2.2.7throws out a 599 issue, probably related to #26:Regardless of
2.2.7(and I'd assume starting with2.2.1, but I got tired of compiling every version, I'm sorry), it's pretty clear thatsnx-rscan not, or rather, does not know how to handlevpn_Cert_Username_Password.Also, while the auth scheme is called
vpn_Cert_Username_Password, the actual "username" seems to be completely irrelevant, and at least on the Windows client, the username is inferred from the certificate name (ie: renaming the cert toBrown Cow.pfxwill show "Brown Cow" as the username in the client), so technically, only thepasswordis required to be sent for auth to the server.Unfortunately I wasn't able to gather any meaningful info with
mitmproxy.It seems that the server is asking the client to connect via port 4500, UDP, so after it does the initial handshake, the actual authentication is performed in the next packet(s) on UDP, and there was no discernable data in the raw frames.
Furthermore, after the initial handshake/connection via
mitmproxy, the client will get "smart" and then connect to the server IP directly, bypassing the actual IP entered during the setup process, which makes further testing very tedious, as you have to delete and re-add the connection.Also, not proxying
UDP 4500will result in the client never connecting, so I couldn't "trick" it to exclusively do it's job on 443.