Skip to main content
baldingfast
baldingfast
New Member
September 20, 2018
Question

100e to sonicwall

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]

4 replies

ede_pfau
SuperUser
ede_pfau
SuperUser
September 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.

Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
September 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
baldingfastAuthor
New Member
September 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]

Terms & ConditionsAccessibility statement
Thought Leadership. Security Summit. Thursday, November 12th, PGA National Resort, Palm Beach Gardens, FL.
Thought Leadership. Security Summit. Thursday, October 8th. Disney's Grand Californian Hotel & SPA, Anaheim, CA.
Security Operations Summit: Modernize SecOps. Operate AI-Native.AMER: November 4 | 9:00 AM PST. India and SAARC: November 5 | 10:00 AM IST. EMEA: November 5 | 10:30 AM CET. APAC: November 5 | 11:00 AM SGT