- CheckMates
- :
- Products
- :
- Quantum
- :
- Smart-1 Cloud
- :
- Re: IPSEC to Fortigate
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IPSEC to Fortigate
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@GSecurity Did you do debug on CP side?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I mean Check Point logs / debugs. These are far more superior 😉
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
These are the phase 1 and 2 configurations for both ends
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
![](/skins/images/84DAB6BD358ECB13CE1094473F6E2961/responsive_peak/images/icon_anonymous_message.png)