IPSEC to Fortigate

[GSecurity]

Good afternoon everyone,

I am stuck in a tunnel between Fortigate and Checkpoint Spark, phase 1 is not able to negotiate. In this case, the Fortigate has a static public IP and the checkpoint has a blocked IP. At the checkpoint end we are configuring the Peer ID since I understand that it is common to use it in these scenarios but from the checkpoint I do not see how to enter this Peer 

Please help me with this question, I am almost sure that this is why phase 1 is not working.

Thanks

[the_rock]

Hey bro,

I think we went through this last week, you still cant find that field in smb appliance? By the way, you should really be using ikev2, not ikev1.

Just saying.

Andy

[Lesley]

What is a blocked IP? What settings are under peer options? What does the log show in check point? local mgmt or central mgmt?

Also change these encryption methods while you are at it. 3DES is not safe and a real performance killer, esp in p2. 

Diffie-hellmangroup 14 atleast

[GSecurity]

These logs show me in the Fortigate firewall

ike 0:VPN-to-Puno:5057: sent IKE msg (P1_RETRANSMIT): 200.123.xx.xx:500->38.25.17.199:40743, len=168, vrf=0, id=2a7536062b1a05e5/30120e08f9e90f75
ike 0: comes 38.25.17.199:40743->200.123.xx.xx:500,ifindex=7,vrf=0....
ike 0: IKEv1 exchange=Informational id=2a7536062b1a05e5/30120e08f9e90f75:1f0fe142 len=40 vrf=0
ike 0: in 2A7536062B1A05E530120E08F9E90F750B1005001F0FE142000000280000000C0000000001000004
ike 0:VPN-to-Puno: HA state master(2)
ike 0:VPN-to-Puno:5057: ignoring unsupported INFORMATIONAL message 0.
ike 0:VPN-to-Puno:5057: out 2A7536062B1A05E530120E08F9E90F750110020000000000000000A80D00003800000001000000010000002C010100010000002401010000800100058002000480030001800B0001000C000400015180800400020D000014AFCAD71368A1F1C96B8696FC775701000D0000148299031757A36082C6A621DE000000000D0000144048B7D56EBCE88525E7DE7F00D6C2D3000000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000
ike 0:VPN-to-Puno:5057: sent IKE msg (P1_RETRANSMIT): 200.123.xx.xx:500->38.25.17.199:40743, len=168, vrf=0, id=2a7536062b1a05e5/30120e08f9e90f75
ike 0: comes 38.25.17.199:40743->200.123.xx.xx:500,ifindex=7,vrf=0....
ike 0: IKEv1 exchange=Informational id=2a7536062b1a05e5/30120e08f9e90f75:341962f8 len=40 vrf=0
ike 0: in 2A7536062B1A05E530120E08F9E90F750B100500341962F8000000280000000C0000000001000004
ike 0:VPN-to-Puno: HA state master(2)
ike 0:VPN-to-Puno:5057: ignoring unsupported INFORMATIONAL message 0.
ike ::ffff:104.140.188.58 truncated control message 0 16 0
ike 0:VPN-to-Puno:5057: negotiation timeout, deleting
ike 0:VPN-to-Puno: connection expiring due to phase1 down
ike 0:VPN-to-Puno: deleting
ike 0:VPN-to-Puno: deleted
ike shrank heap by 135168 bytes

[the_rock]

This clearly tells you why its failing...

Andy

ike 0:VPN-to-Puno:5057: ignoring unsupported INFORMATIONAL message 0.
ike ::ffff:104.140.188.58 truncated control message 0 16 0
ike 0:VPN-to-Puno:5057: negotiation timeout, deleting
ike 0:VPN-to-Puno: connection expiring due to phase1 down

[the_rock]

@GSecurity Did you do debug on CP side?

Andy

[Lesley]

I mean Check Point logs / debugs. These are far more superior 😉 

[GSecurity]

These are the phase 1 and 2 configurations for both ends

[Lesley]

From the screenshot I cannot see why it should not work. 

From security point of view. Enable PFS on both sides with minial diffiehellmangroup 14 or higher (not 2)

Same please for p1. Second change the aes-128 to aes-256 on p1 and p2 and you are good. 

What do the logs show if you filter on remote public IP you see anything comming in? 

[the_rock]

Do basic debugs on both ends.

CP:

vpn debug trunc

vpn debug ikeon

-generate some traffic

vpn debug ikeoff

check vpnd and ike files in $FWDIR/logs

FGT:

diag debug app ike -1

diag debug enable

-check what comes up on the screen, messages are usually easy to "decipher" as far as the issue

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-IPsec-VPNs-tunnels/ta-p/195955

Just run di de di command once done, though on Fortigate thats usually not even needed to disable the debug, as they are so light, if you left them on for some time, nothing would happen to the box, though by default, they stop after 30 mins, just to save cpu/memory resources.

Andy