Skip to main content
random_guy
random_guy
Explorer
May 4, 2020
Question

IPSec Tunnel - Phase 1 fails

  • May 4, 2020
  • 1 reply
  • 14494 views

Odd problem that support could not help me with. Trying to bring up an IPSEC tunnel. I can create tunnels to Azure and to a spare WAN connection in out office. When I've tried to apply this config to 2 60E's in remote offices, they both failed. The only differences between these offices and our testWAN/Azure is that Azure/TestWAN receive dynamic IPs while our offices get static IPs from their ISPs and thus, have an extra route to their gateway.

 

When I run 'diagnose sniffer packet any "host x.x.x.x and port (500 or 4500)" 4 0 l' on our main firewall, I see the traffic go out but never come back. On the remote firewall I see the traffic come in and go back out. Support waived their hand, said the config was good and it was an ISP issue... but I have a hard time believing that two separate ISPs are causing the exact same problem. And our primary ISP allows this to Azure and our testWAN. 

 

Summary:

-config good

-Main -> Azure Works

-Main -> testWAN (same ISP as Main, DHCP IP) works

-Main -> Branch1 (static IP from ISP1) fails

-Main -> Branch2 (static IP from ISP2) fails

1 reply

emnoc
emnoc
New Member
May 4, 2020

You really need to dump the debug from iked

 

"diag debug reset"

"diag debug enable"

"diag debug application ike -1"

 

That might explain more and do it from both ends 

MAIN--2--remote

remote-2-MAIN 

 

Once you have capture diag debug output analyze the data and follow the evidence. Also make sure you do not have local-policy in filters that could be block the traffic.

 

I recently worked with some one who had local-in policy that where overlooked.

 

Ken Felix

random_guy
random_guyAuthor
Explorer
May 4, 2020

Same steps that Fortigate support went through. The branch receives the connection but its response never makes it back to the main. All polices on the branch are disabled to remove any potential issues there. The appropriate policies are in place on main which are know to be good because they work on test and to Azure.

 

Main:

ike 0:To_Branch:979559: sent IKE msg (P1_RETRANSMIT): x.x.x.x:500->x.x.x.x:500, len=572, id=17c8de40d4aa99ee/0000000000000000
ike 0:To_Branch:To_Branch: IPsec SA connect 0 x.x.x.x->x.x.x.x:0
ike 0:To_Branch:To_Branch: using existing connection
ike 0:To_Branch:To_Branch: config found
ike 0:To_Branch: request is on the queue
ike 0:To_Branch:To_Branch: IPsec SA connect 0 x.x.x.x->x.x.x.x:0
ike 0:To_Branch:To_Branch: using existing connection
ike 0:To_Branch:To_Branch: config found
ike 0:To_Branch: request is on the queue
ike 0:To_Branch:To_Branch: IPsec SA connect 0 x.x.x.x->x.x.x.x:0
ike 0:To_Branch:To_Branch: using existing connection
ike 0:To_Branch:To_Branch: config found
ike 0:To_Branch: request is on the queue
ike 0:To_Branch:To_Branch: IPsec SA connect 0 x.x.x.x->x.x.x.x:0
ike 0:To_Branch:To_Branch: using existing connection
ike 0:To_Branch:To_Branch: config found
ike 0:To_Branch: request is on the queue

 

Branch:

 

responder: main mode get 1st message...
VID RFC 3947 4A131C81070358455C5728F20E95452F
VID draft-ietf-ipsec-nat-t-ike-03 7D9419A6531sadf79D9215529D56
VID draft-ietf-ipsec-nat-t-ike-02 CD60464asdfC68B6A448
VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913Easdf381B5EC427B1F
VID draft-ietf-ipsec-nat-t-ike-01 16F6CA16E4A4066sdfA0F0AEAA862
VID draft-ietf-ipsec-nat-t-ike-00 4485152D18asdfBE8A8469579DDCC
VID DPD AFCAD71368A1F1Casdf696FC77570100
VID FRAGMENTATION 4048B7D56EBCasdf5E7DE7F00D6C2D3
VID FRAGMENTATION 4048B7D56EBCE8asdf7F00D6C2D3C0000000
VID FORTIGATE 8299031757A3asdf21DE00000000
negotiation result
proposal id = 1:
  protocol id = ISAKMP:
     trans_id = KEY_IKE.
     encapsulation = IKE/none
        type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=128
        type=OAKLEY_HASH_ALG, val=SHA2_256.
        type=AUTH_METHOD, val=PRESHARED_KEY.
        type=OAKLEY_GROUP, val=MODP2048.
ISAKMP SA lifetime=86400
SA proposal chosen, matched gateway To_Main
ike 0: found To_Main x.x.x.x 5 -> x.x.x.x:500
ike 0:To_Main:4: peer is FortiGate/FortiOS (v0 b0)
ike 0:To_Main:4: selected NAT-T version: RFC 3947
ike 0:To_Main:4: cookie 4ab9e7eb1f14e696/6ee2964f8ee0fc71
ike 0:To_Main:4: out 4AB9E7EB1F14E69660000000C00D00003C000000010000000100000030010100010000002801010000800B0001000C00040001518080010007800E008080030001800200048004000E0D0000144A131C81070358455C5728F20E95452F0D000014AFCAD71368A1F1C96B8696FC775701000D0000148299031757A36082C6A621DE000000000D0000144048B7D56EBCE88525E7DE7F00D6C2D3000000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000
ike 0:To_Main:4: sent IKE msg (ident_r1send): x.x.x.x:500->x.x.x.x:20001, len=192, id=4ab9e7eb1f14e696/6ee2964f8ee0fc71
ike 0:To_Main:To_Main: IPsec SA connect 5 x.x.x.x->x.x.x.x:0
ike 0:To_Main:To_Main: using existing connection
ike 0:To_Main:To_Main: config found
ike 0:To_Main: request is on the queue

 

The only difference that I can tell is that I manually had to add a static route on the branches for the gateway since it was a static IP.

 

config router static
edit 1
set device "To_Main"
set dstaddr "x.x.x.x"
next
edit 2
set gateway x.x.x.x
set device "wan1"
next
end

 

Could there be an issue there that it isn't routing back properly? 

emnoc
emnoc
New Member
May 4, 2020

I high doubt that, but what I would do

 

At main "set allow access ping" on the wan interface, from remotes can you ping the main?

  execute ping x.x.x.x

 

If that works, than routing is not a issue. Also double check the "set remote-gw x.x.x.x" settings in each remote firewall and the src_interface

 

Ken Felix

Terms & ConditionsAccessibility statement