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.
-
@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?
-
This post is deleted! -
@rmainero
router cisco 881 both pointsWhat I see is that the problem point rises in port 4500 nat-t and the other in port 500 but both are in automatic
-
It's more that when one side moves from port 500 to port 4500 for the key exchange the other side rejects it. You can see in the logs that happens both ways.
-
Both Cisco end points are behind NAT?
-
@stephenw10 said in VPN point to point:
Both Cisco end points are behind NAT?
Yes, both computers configured the same, with different key and subnet
-
Something is different. Same firmware version on the Cisco endpoints?
