Skip to main content
acellgipit
acellgipit
New Member
June 10, 2021
Solved

Site to Site FortiGate to Cisco - Cannot connect due to public IP?

  • June 10, 2021
  • 1 reply
  • 7683 views

Hi, guys, can you help me? I am having troubles with connecting to a remote vpn via IPsec. They are using public IP addresses for their terminals. (See image attached). I am done with static routes, ipv4 policies, ipsec tunnels. I've done it a couple of times but this is the first time that I am connecting our local PRIVATE IP ADDRESSES (10.10.0.0 and 10.10.70.0) to remote Public ip addresses (216.242.170.0/26) Do I need to do something? Our phase 1 and phase 2 are the same even our preshared keys These IPs are just examples.

    Best answer by emnoc

    What diagnostic did you do if any ?

     

    > I would start by double checking phase1 and 2 is up, 

     

      diag vpn ike gateway list

      diag vpn tunnel list

     

    > next I would verify your route table

     

      get router info routing all | grep  216.242.170.0

     

    > if all of these are a positive, check our policy/objects are correct ( e.g no typos ) 

     

    >  and then a "diag debug flow"

     

     

    Ken Felix

    1 reply

    emnoc
    emnocAnswer
    New Member
    June 10, 2021

    What diagnostic did you do if any ?

     

    > I would start by double checking phase1 and 2 is up, 

     

      diag vpn ike gateway list

      diag vpn tunnel list

     

    > next I would verify your route table

     

      get router info routing all | grep  216.242.170.0

     

    > if all of these are a positive, check our policy/objects are correct ( e.g no typos ) 

     

    >  and then a "diag debug flow"

     

     

    Ken Felix

    acellgipit
    acellgipitAuthor
    New Member
    June 10, 2021

    Hi, Emnoc,

    Sorry for the late reply. Thank you for your advise. Im still new to Fortigate so bear with me. Here are the results:

     

    diag vpn ike gateway list

    vd: root/0 name: Imagine-IPsec version: 1 interface: port2 10 addr: 27.110.219.186:500 -> 216.240.169.50:500 created: 4s ago IKE SA: created 1/1 IPsec SA: created 1/1 id/spi: 1176320 dca29d3afb5e81d0/0000000000000000 direction: responder status: connecting, state 3, started 4s ago

     

      diag vpn tunnel list

     

    name=Imagine-IPsec ver=1 serial=4b2 27.110.219.186:0->216.240.169.50:0 bound_if=10 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/8 options[0008]=npu proxyid_num=1 child_num=0 refcnt=10 ilast=23 olast=23 ad=/0 stat: rxp=0 txp=0 rxb=0 txb=0 dpd: mode=on-demand on=0 idle=20000ms retry=3 count=0 seqno=0 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=Imagine-IPsec proto=0 sa=0 ref=2 serial=15 auto-negotiate src: 0:10.10.0.0/255.255.248.0:0 0:10.70.0.0/255.255.248.0:0 dst: 0:216.240.172.0/255.255.255.192:0

     

    get router info routing al

     

    S 216.240.172.0/26 [1/0] via 203.177.24.241, port1 [1/0] via 27.110.219.185, port2

    Also attached the real ip and stuff. I really need some help. hehe

     

    Image link : [link]https://ibb.co/XpTjDMw[/link]

    emnoc
    emnoc
    New Member
    June 10, 2021

    So this is going to need deep diagnostics

     

    1> you are responding to the cisco (that good in some degree)

     

    2> phase1 is NOT up 

     

    3> vpn Imagine-IPsec needs to be analyze as to why not negotiating IKE

     

    4> that route for the destination should be pointed to interface "Imagine-IPsec"

     

    Can you dump your following cfgs

     

    show vpn ipsec phase1-interface Imagine-IPsec

    show vpn ipsec phase2-interface  

    show router < route #>

    show firewall policy <policy number>

     

    Let's double check your cfg. Once you have confirm the cfg we need to run "diag debug application ike -1" to see what debug details are present.

     

    Ken Felix

     

    Terms & ConditionsAccessibility statement