[SOLVED] Switching from aggressive to main mode does not work
-
In preparation for a 2.2 upgrade, we wanted to change our VPN Tunnels from aggressive to main mode to circumvent hitting possible known errors.
A tunnel which works fine in aggressive mode (has done so for years), does not work on main mode, the logs from endpoint1:Jan 24 09:40:01 racoon: []: INFO: IPsec-SA request for 1.1.1.1 queued due to no phase1 found.
Jan 24 09:39:42 racoon: INFO: delete phase 2 handler.
Jan 24 09:39:42 racoon: []: [1.1.1.1] ERROR: phase2 negotiation failed due to time up waiting for phase1 [Remote Side not responding]. ESP 1.1.1.1[0]->2.2.2.2[0]
Jan 24 09:39:11 racoon: []: [1.1.1.1] ERROR: phase1 negotiation failed.
Jan 24 09:39:11 racoon: []: [1.1.1.1] ERROR: failed to process ph1 packet (side: 0, status: 6).
Jan 24 09:39:11 racoon: []: [1.1.1.1] ERROR: couldn't find the pskey for 1.1.1.1.
Jan 24 09:39:11 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Jan 24 09:39:11 racoon: INFO: received Vendor ID: DPD
Jan 24 09:39:11 racoon: INFO: begin Identity Protection mode.
Jan 24 09:39:11 racoon: []: INFO: initiate new phase 1 negotiation: 2.2.2.2[500]<=>1.1.1.1[500]Logs from endpoint2:
Jan 24 09:39:11 racoon: [MIZE]: [2.2.2.2] ERROR: phase1 negotiation failed.
Jan 24 09:39:11 racoon: [MIZE]: [2.2.2.2] ERROR: failed to process ph1 packet (side: 1, status: 4).
Jan 24 09:39:11 racoon: [MIZE]: [2.2.2.2] ERROR: couldn't find the pskey for 2.2.2.2.
Jan 24 09:39:11 racoon: INFO: received Vendor ID: DPD
Jan 24 09:39:11 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Jan 24 09:39:11 racoon: INFO: begin Identity Protection mode.
Jan 24 09:39:11 racoon: [MIZE]: INFO: respond new phase 1 negotiation: 1.1.1.1[500]<=>2.2.2.2[500]No other setting changed.
Both endpoints in this tunnel have dynamic IP Addresses.
Current pfSense is version 2.1.5How can I diagnose this?
Thanks
Michel -
Which phase 1 identifiers are you using?
-
After reading up more on the subject, I discovered that apparently the combination of PSK and main mode is not possible with dynamic IP's.
I have switched to certificate-based authentication now, and the tunnel did come up fine!
(And I'm even more secure now :) )Thanks
Michel