Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 1 subscriber
  • Views 4603 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec between ASL v7.405 & Fortinet Fortigate 60

LewisRosenthal
Greetings, all...

I'm having a Dickens of a time getting this working. On the far side, I have a Fortigate 60, which I do not manage. I have provided the admin there with a PSK and my IP data. I have requested we set up for AES256 with PFS.

Upon enabling the tunnel in WebAdmin, I get the following in the log:

[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: | *received 356 bytes from ***.***.***.***:500 on eth0 [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: received Vendor ID payload [RFC 3947] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [16f6ca16e4a4066d83821a0f0aeaa862] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: received Vendor ID payload [Dead Peer Detection] [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: | preparse_isakmp_policy: peer requests PSK authentication [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: packet from ***.***.***.***:500: initial Main Mode message received on yyy.yyy.yyy.yyy:500 but no connection has been authorized with policy=PSK [/FONT]
[FONT=monospace]2009:08:17-16:16:49 secmgr-va pluto[3575]: | next event EVENT_DPD in 2 seconds for #52500 [/FONT]
I have no indication as to the level of knowledge the other admin has about either IPSec or about the Fortinet device, so I am taking him at his word when he says that he has entered all the data correctly (twice). Any suggestions for how to make this a bit easier (back off on the PFS? something other than IPSec?) would be greatly appreciated.

Thanks!


This thread was automatically locked due to age.
Parents
  • 0
    That's one of the things we'll be discussing this morning on the phone (NAT-T). He didn't provide a snapshot of the advanced settings, so I'm not sure what he's got there. Hopefully, I'll have a resolution for this this morning, and will post my results (and a how-to).

    Thanks for following up, Bob. Much appreciated.
  • 0 in reply to LewisRosenthal
    Three hours on the phone...no dice.

    Checked NAT-T. Without it enabled, the result is similar to the last two lines of the original snippet. With it enabled (on the far end; I have it enabled on the ASG), we get all of the rest of the payloads up to that point, so clearly, this is desirable, but not the problem we're seeing.

    We reset our PSK's to something simple (12345678). No change.

    We disabled PFS. No change.

    Per a SonicWALL technote (for connecting SonicOS Enhanced to Fortinet), I created a new policy (3DES/SHA/28800 for both phases, no compression, no PFS). Steve (the other admin) set up a completely new tunnel based upon those same params. At first, the FortiGate 60 stopped passing all traffic to us (the filtered log just stopped). After about a half hour of head scratching, on the verge of his rebooting it, toggling NAT-T off and then on again got it kicked over. Still, the same error as before, however.

    I'm down to trying certs instead of PSK's, though I am not convinced that those will get us much farther.

    More news as it develops...
Reply
  • 0 in reply to LewisRosenthal
    Three hours on the phone...no dice.

    Checked NAT-T. Without it enabled, the result is similar to the last two lines of the original snippet. With it enabled (on the far end; I have it enabled on the ASG), we get all of the rest of the payloads up to that point, so clearly, this is desirable, but not the problem we're seeing.

    We reset our PSK's to something simple (12345678). No change.

    We disabled PFS. No change.

    Per a SonicWALL technote (for connecting SonicOS Enhanced to Fortinet), I created a new policy (3DES/SHA/28800 for both phases, no compression, no PFS). Steve (the other admin) set up a completely new tunnel based upon those same params. At first, the FortiGate 60 stopped passing all traffic to us (the filtered log just stopped). After about a half hour of head scratching, on the verge of his rebooting it, toggling NAT-T off and then on again got it kicked over. Still, the same error as before, however.

    I'm down to trying certs instead of PSK's, though I am not convinced that those will get us much farther.

    More news as it develops...
Children