100e to sonicwall

baldingfast · ‎09-20-2018

FortiGate 100E firmware 5.6.6

I am new to Fortigates and am trying to establish an IPSEC tunnel to a sonicwall. I have come across some tutorials on attempting this but they show for older firmware versions and things look different and the menus are not the same. I did try to also use the CLI and i have absolutely no luck with that either.

As far as I have been able to see I have configured the various settings on both ends to be the same but they are not connecting. Looking at the vpn tunnel in both the Sonicwall and Fortigate, it shows it as being up but when I get to the logs, for the fortigate it is showing as being down.

Within the logs for the Fortigate, and also in the CLI debug info I pasted below, it is showing as wanting to use IKEv2 when I have IKEv1 configured.

Some things I have tried is selecting various proposals, DPD on/off, standing on my head, sacrificing a coworker, the expected things, even reading the manual for the different versions of 5.6.5, .6, and also 6.0.2, which are also firmware I tried. Moved it back to 5.6 but I am stumped as to what I am missing, any help would be appreciated.

Screenshot of where it says IKEv2 in GUI log:

Doing a debug from the FortiGate I am getting:

ike Negotiate SA Error: ike ike [9748]

ike 0: comes <xxx.xxx.xxx.xxx>:500-><yyy.yyy.yyy.yyy>:500,ifindex=8....

ike 0: IKEv2 exchange=SA_INIT id=a3be868a6138d7cb/0000000000000000 len=380

ike 0: in A3BE868A6138D7CB000000000000000021202208000000000000017C220000300000002C010100040300000C0100000C800E0100030000080300000C03000008020000050000000804000005280000C800050000A5080E44701E201AB22D83191F468A40D16A33D5C35419B828787C8DF2EE1579193DAF76A0FDE55A3415DB2B1C3CC65D6FF07F03507D28506A01B2639AC66DDE466180848C499451356E7CCBB5394B1DF75D48320DC2C52CB03FB624716DC94B0A26126662C4B43D311E7E5EB32C7292E75E69256BB87EEE8C941805B28EB79A1A5CF85E1692267C7B5F314767ACC67EEA06DD87F1F251A77995B21B4DDCD975F3B7A5E2DE1071B9F2AA45653F4303FA7A34299FA8EA91E0146A689C3A7B9A3929000018BD871C2ED2C7CE66DB478D7F9B0A4665A1D151EC2900001C00004004E6A505A616AE249692DF8EC4833511D2131953DC2B00001C000040056309B88C1E537D73EBB7908E864D88B6714436F1000000182A6775D0AD2AA7887C33FE1D68BAF308966F0001

ike 0:a3be868a6138d7cb/0000000000000000:297: responder received SA_INIT msg

ike 0:a3be868a6138d7cb/0000000000000000:297: received notify type NAT_DETECTION_SOURCE_IP

ike 0:a3be868a6138d7cb/0000000000000000:297: received notify type NAT_DETECTION_DESTINATION_IP

ike 0:a3be868a6138d7cb/0000000000000000:297: incoming proposal:

ike 0:a3be868a6138d7cb/0000000000000000:297: proposal id = 1:

ike 0:a3be868a6138d7cb/0000000000000000:297: protocol = IKEv2:

ike 0:a3be868a6138d7cb/0000000000000000:297: encapsulation = IKEv2/none

ike 0:a3be868a6138d7cb/0000000000000000:297: type=ENCR, val=AES_CBC (key_len = 256)

ike 0:a3be868a6138d7cb/0000000000000000:297: type=INTEGR, val=AUTH_HMAC_SHA2_256_128

ike 0:a3be868a6138d7cb/0000000000000000:297: type=PRF, val=PRF_HMAC_SHA2_256

ike 0:a3be868a6138d7cb/0000000000000000:297: type=DH_GROUP, val=MODP1536.

ike 0:a3be868a6138d7cb/0000000000000000:297: no proposal chosen

ike Negotiate SA Error: ike ike [9748]

ede_pfau · ‎09-20-2018

Hi,

and welcome to the forums.

Nice nick! we've all been there at a time...

Well, I will not pretend that I know the Sonicwall stuff. But, to your rescue, the FGT adheres to the standard pretty much. If the other side does this as well you can get it to work.

First, and quite dominantly, both sides have to agree if they'd use IKEv1 or IKEv2. IF the debug snippet shows incoming requests then the SW uses IKEv2. Either change that (recommended) or switch the FGT config to use IKEv2.

The screenshot doesn't show.

I'd first try very simple proposals, like AES128/SHA1, and a VERY VERY simple PSK. You can always sharpen that when it works.

Remember that in order to establish a tunnel a policy is needed - not afterwards, but right now. Usually, it's 'lan' to 'tunnel' and 'tunnel' to 'lan', with the private subnets as source/destination.

Finally, you need to set a route to the remote private subnet, pointing to the tunnel interface. Gateway doesn't need to be specified. Without route, no traffic from hosts will reach the tunnel.

Of course, first things first: IKE version. All other hints thereafter.

Ede

"Kernel panic: Aiee, killing interrupt handler!"

Toshi_Esumi · ‎09-20-2018

I think yyy.yyy.yyy.yyy below is on FGT side. Otherise it wouldn't say "comes".

ike 0: comes <xxx.xxx.xxx.xxx>:500-><yyy.yyy.yyy.yyy>:500,ifindex=8....

And Sonicwall seems to have sent SA_INIT request msg, which is IKEv2's first message. You should look closer at Sonicwall config.

I have no knowledge about Soniwall. But they seem to have a gook KB as well. And, the log seems to show very similar to what FGTs show in IKE debugging.

https://www.sonicwall.com/en-us/support/knowledge-base/170503333449304

baldingfast · ‎09-21-2018

I took a look at the setting on the Sonicwall. I then tried to make another tunnel to a different office and the same thing is occurring, both are set for Main Mode, IKEv1.

If this were an issue with the configuration on a single SonicWall I would understand that but it is happening with two now. Lastly I tried connecting to an old pfsense firewall, it has no support for IKEv2, it is that old, and am still getting the IKEv2 showing up in the VPN logs.

Here is log from old for old pfsense and fortigate, any ideas would be welcome.

ike 0: comes <pfs.pfs.pfs.pfs>:500-><ftg.ftg.ftg.ftg>:500,ifindex=8....

ike 0: IKEv1 exchange=Informational id=7ece11da6a5e1d11/ce146ae0232e9f7c:ba6c3284 len=92

ike 0: in 7ECE11DA6A5E1D11CE146AE0232E9F7C08100501BA6C32840000005CCEDD6AEC25CE32026C215116A634ACB8FF49B7F2585F536A6864E6578838D4F06CF7D1C9EC4A48352E4A67B0E61599AFABAD2B0E26076D041180CD65E51613C1

ike 0:TLH100b:7320: dec 7ECE11DA6A5E1D11CE146AE0232E9F7C08100501BA6C32840000005C0B0000189EC6AF078136992D0DF0D6EB53E4DF3E96A11448000000200000000101108D287ECE11DA6A5E1D11CE146AE0232E9F7C00000BD4B38A8A91A9F08007

ike 0:TLH100b:7320: notify msg received: R-U-THERE

ike 0:TLH100b:7320: enc 7ECE11DA6A5E1D11CE146AE0232E9F7C0810050126A1F794000000540B000018FDEC8C40A8AE6ABADA58A3F199D3F430EE592ABB000000200000000101108D297ECE11DA6A5E1D11CE146AE0232E9F7C00000BD4

ike 0:TLH100b:7320: out 7ECE11DA6A5E1D11CE146AE0232E9F7C0810050126A1F7940000005C6E31198F8E5545F089DE124A8BE0CFEC13FAF72342974DB34D434BF8E79D70FEE0E8DAFEB3110926F0BE4DF4A6C7E493BE3E1846AC0FE3170FB3338C9F3E6D39

ike 0:TLH100b:7320: sent IKE msg (R-U-THERE-ACK): <ftg.ftg.ftg.ftg>-><pfs.pfs.pfs.pfs>:500, len=92, id=7ece11da6a5e1d11/ce146ae0232e9f7c:26a1f794

ike 0: comes <pfs.pfs.pfs.pfs>:500-><ftg.ftg.ftg.ftg>:500,ifindex=8....

ike 0: IKEv2 exchange=SA_INIT id=5b4f22cfcb8818e8/0000000000000000 len=380

ike 0: in 5B4F22CFCB8818E8000000000000000021202208000000000000017C220000300000002C010100040300000C0100000C800E0100030000080300000C03000008020000050000000804000005280000C80005000023D58D5C7FE5FACD12B7721EF2ECAB1BAD6BFD51EACEA9D2663A4F47A179932B1AA3B477BF05ED027580BD92EC7366D06312199C75CC423518A14AF6142363874DB7E5F1BD974ECA2FE931DA34818864AD3E389AB5A676E19FC046407848E267FF825BA67514FE0A27E8F40304238A1E12F75971DFC6954F98D39C80D48D2F6F101F581356838264E020CDA048E8A454B09142BC404F54C7C5DA93362752F8895AEB4A1F4E91485DE89AC92B8E1C86E84942181291EF969A8A6B7122DBE7DF99290000182B71AF1AA4C9EA28C05F8A723C3AF1ECEA3BC32E2900001C000040049976250D57E261B821C40B27439D1D6E422ACA4A2B00001C00004005458335E0A1EF27C358BD166E6781B644528AB011000000182A6775D0AD2AA7887C33FE1D68BAF308966F0001

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: responder received SA_INIT msg

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: received notify type NAT_DETECTION_SOURCE_IP

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: received notify type NAT_DETECTION_DESTINATION_IP

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: incoming proposal:

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: proposal id = 1:

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: protocol = IKEv2:

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: encapsulation = IKEv2/none

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: type=ENCR, val=AES_CBC (key_len = 256)

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: type=INTEGR, val=AUTH_HMAC_SHA2_256_12

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: type=PRF, val=PRF_HMAC_SHA2_256

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: type=DH_GROUP, val=MODP1536.

ike 0:5b4f22cfcb8818e8/0000000000000000:7710: no proposal chosen

ike Negotiate SA Error: ike ike [9748]

Toshi_Esumi · ‎09-21-2018

You already have one IPSec with IKEv1 up. Below is the DPD exchange for the UP tunnel.

ike 0:TLH100b:7320: notify msg received: R-U-THERE

ike 0:TLH100b:7320: enc

ike 0:TLH100b:7320: sent IKE msg (R-U-THERE-ACK:( <ftg.ftg.ftg.ftg>-><pfs.pfs.pfs.pfs>:500, len=92, id=7ece11da6a5e1d11/ce146ae0232e9f7c:26a1f794

Then an additional IKEv2 IPSec request is coming from the pfsense.

ike 0: comes <pfs.pfs.pfs.pfs>:500-><ftg.ftg.ftg.ftg>:500,ifindex=8.... ike 0: IKEv2 exchange=SA_INIT id=5b4f22cfcb8818e8/0000000000000000 len=380 ike 0: in

If you run "get vpn ipsec tun sum", you would see "TLH100b" up.