VPN point to point
-
If there are no logs showing it trying to come back up and failing then perhaps there is no traffic to initiate it.
-
Hello, I pass the log
Sep 22 07:18:03 charon 57999 16[NET] <con1|1108> received packet: from 190.106.82.252[500] to 190.13.88.176[500] (304 bytes)
Sep 22 07:18:03 charon 57999 16[IKE] <con1|1108> received retransmit of response with ID 0, but next request already sent
Sep 22 07:18:06 charon 57999 16[IKE] <con1|1108> sending retransmit 3 of request message ID 0, seq 3
Sep 22 07:18:06 charon 57999 16[NET] <con1|1108> sending packet: from 190.13.88.176[4500] to 190.106.82.252[4500] (76 bytes)
Sep 22 07:18:07 charon 57999 16[IKE] <con2|689> sending DPD request
Sep 22 07:18:07 charon 57999 16[IKE] <con2|689> queueing ISAKMP_DPD task
Sep 22 07:18:07 charon 57999 16[IKE] <con2|689> activating new tasks
Sep 22 07:18:07 charon 57999 16[IKE] <con2|689> activating ISAKMP_DPD task
Sep 22 07:18:07 charon 57999 16[ENC] <con2|689> generating INFORMATIONAL_V1 request 1418999662 [ HASH N(DPD) ]
Sep 22 07:18:07 charon 57999 16[NET] <con2|689> sending packet: from 190.13.88.176[500] to 200.0.211.137[500] (92 bytes)
Sep 22 07:18:07 charon 57999 16[IKE] <con2|689> activating new tasks
Sep 22 07:18:07 charon 57999 16[IKE] <con2|689> nothing to initiate
Sep 22 07:18:07 charon 57999 16[NET] <con2|689> received packet: from 200.0.211.137[500] to 190.13.88.176[500] (92 bytes)
Sep 22 07:18:07 charon 57999 16[ENC] <con2|689> parsed INFORMATIONAL_V1 request 2879668186 [ HASH N(DPD_ACK) ]
Sep 22 07:18:07 charon 57999 16[IKE] <con2|689> activating new tasks
Sep 22 07:18:07 charon 57999 16[IKE] <con2|689> nothing to initiate
Sep 22 07:18:08 charon 57999 12[CFG] vici client 516 connected
Sep 22 07:18:08 charon 57999 06[CFG] vici client 516 registered for: list-sa
Sep 22 07:18:08 charon 57999 06[CFG] vici client 516 requests: list-sas
Sep 22 07:18:08 charon 57999 06[CFG] vici client 516 disconnected -
@rmainero said in VPN point to point:
Sep 22 07:18:03 charon 57999 16[NET] <con1|1108> received packet: from 190.106.82.252[500] to 190.13.88.176[500] (304 bytes)
Sep 22 07:18:03 charon 57999 16[IKE] <con1|1108> received retransmit of response with ID 0, but next request already sentThis message implies the other side is either not receiving the replies or is rejecting them. What do the logs at the remote side of that tunnel show?
-
-
That looks like the same side of the tunnel. Do you have any logs from the other side?
-
Do you want any record on the side of the cisco?
-
Any errors shown. From the pfSense logs it looks like the other side is either not seeing packets we are sending or is rejecting them.
-
@stephenw10 said in VPN point to point:
Any errors shown. From the pfSense logs it looks like the other side is either not seeing packets we are sending or is rejecting them.
Ok, I'll send them to you tomorrow, because now it's up and working.
-
you can pass me an email where you reverse a full video of the error
-
You can upload files for me here: https://nc.netgate.com/nextcloud/index.php/s/ai7Km5LsYWZRQMf
-
@stephenw10
I already uploaded the file -
Hmm, nothing instantly jumps out but something that can cause a connection to succeed once then fail is an encryption mismatch at phase2. If it matches phase1 it will initially use that for phase2 in an IKEv2 connection but then fail at rekey. Check that.
It could also be something con figured with more allowed at one end. So pfSense will allow connections that configured with one of the enabled algorithms but the other end might only have one.
If you can copy/paste the complete logs from when it's failing it's much easier to review than a video.
-
@stephenw10 said in VPN point to point:
If you can copy/paste the complete logs from when it's failing it's much easier to review than a video.
-
When does it fail, after how long? When it first rekeys?
-
@stephenw10 said in VPN point to point:
When does it fail, after how long? When it first rekeys?
I pick it up at 7 am and at 14 pm it falls off and I pick it up again manually. If you think I can give you access to see the team as a whole, my English is not very good
-
Mmm, it looks like the re-auth time is ~7h so that lines up; it fails at re-auth.
Really I would want to see the full log from both sides covering the time where it tries to re-auth and fails.
I would also compare the VPN config from both sides carefully. It looks like one side allows connections the other side would refuse.
The error shown is a key mismatch:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/ipsec-logs.html#phase-1-pre-shared-key-mismatch
But since it can connect when pfSense establishes the tunnel that appears to be correct. Unless somehow Cisco has multiple keys.Steve
-
@stephenw10 said in VPN point to point:
But since it can connect when pfSense establishes the tunnel that appears to be correct. Unless somehow Cisco has multiple keys.
This started after the update of pfsense to 2.7 before the configurations were in des and md5, what generates noise is that the other point works correctly the problem is only this point
-
Ah OK. So you had to update the ciphers at both ends and then this started?
-
@stephenw10 said in VPN point to point:
Ah OK. So you had to update the ciphers at both ends and then this started?
That's right, modify both points, and only one has this behavior the other works perfect
-
How do you mean 'both points'?
Two tunnels?
The other tunnel that's configured in pfSense? What's at the other end of that?
