Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
NETWORK_USER
New Contributor

ipsec site-to-site vpn traffic not reaching destination

Hello, I have configured a site-to-site vpn between two fortigate 300c FW and I see the tunnel come up but when I try to reach from a host (behind the firewall) from one end of the tunnel to another host at the other end of the tunnel, it does not work. I did packet captures and what I see is that if lets say if I start a ping from host1 behind fw 1 to a host2 behind fw2 then I see the icmp echo packets reaching fw2 (virtual vpn interface) but FW2 does not send it out the interface where host2 is connected. Same thing happens the other way round too. Am I missing any configuration? I would assume firewall knows the hosts that are directly connected to their interfaces and should know how to route traffic to them. But I am totally confused why this is not working. Anybody has any suggestions? Thank you.
12 REPLIES 12
rwpatterson
Valued Contributor III

The big question is how are the tunnels defined? Interface mode or policy mode? If interface mode, make sure that you have static routes defined in each side to reach the remote ends. The distance needs to be less than that of your default route.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
AndreaSoliva
Contributor III

Hi this what bob says is absolutly correct. To give you a red line here what has to be done for a site2site vpn: - Create on both site a Phase1 and 2 with exact the same values (recommended is for Enc AES256 SHA1 as fallback use AES256 MD5). The configuration on both sites do not diff except the public IP whcih represents the gateway on the other site. Do not use Qucik Mode selector. What you have also to be careful is the interface mode. This means actually following: Since 5.0.4 the default is NOT anymore Policy Mode because Policy Mode is slower and not anymore kind of the art. Look that you create Phase 1 in Interface Mode which is up to 5.0.4 default (if you create Phase 1 with 5.0.4 and above the Phase 1 is by default in interface mode). If you like to configure the VPN over CLI the command to create a Interface Based VPN is " config vpn ipsec phase1-interface" . Keep in mind that if you like to keep the tunnel activ on both sites activate on Phase 2 following entries: Autokey Keep Alive Auto-negotiate By CLI done with: # config vpn ipsec phase2-interface # edit [name of Phase2] # set auto-negotiate enable # set keepalive enable # end - As soon as you have Phase 1/2 in Interface Based created you will see on the specific Interface exampel WAN the VPN Phase1. Do not touch this entry. Every config should be done over Phase 1 and/or 2. - No route the encryption domain to the other site this means if the LAN to be reached over the tunnel is example 192.168.1.0/24 you have to configure over the Gui a static route which points this subnet to the VPN Interface representing your Phase 1 and visible under the WAN. You got it....? This is Interface Based :) Do this routing on both site. - At least you have to implement a correcsponding policy which covers the traffic from site A to B and the other way arround. Within this Policy configure nothing special only Source your lan with your source IP Range/Server, Destination the other site IP range (encryption domian) and as destination interface the interface representing the Phase 1 which is also visible under WAN....you got it.....? this means Interface Based. - If you " re-configure" stuff meaning changing IP ranges, changing routing etc. keep always in mind that the bring-up and down over the gui does not start the tunnel by scratch and renew the SA. If you like to renew SA meaning really bring the tunnel down and up do following: # execute router restart NOTE this restarts the routing table at all! # diagnose debug application ike 2 # diagnose debug enable # diagnose vpn ike restart NOTE Be careful this restarts ALL tunnels on the Forti and interrupts the connection. # diagnose vpn ike gateway flush [name Phase 1] NOTE This brings down and up only one tunnel but does not actually renew the SA in a clean way as diagnose vpn ike restart. Do always Interface Based VPN because this ones -if correct enc is used- will be accelerated on the FGT. This can be controlled with folllowing command: Example of accelerated VPN: # diag vpn ipsec status All ipsec crypto devices in use: CP6 null: 0 0 des: 0 0 3des: 0 0 aes: 11342694 118453159 null: 0 0 md5: 0 0 sha1: 11342694 118453159 sha256: 0 0 sha384: 0 0 sha512: 0 0 SOFTWARE: null: 0 0 des: 0 0 3des: 0 0 aes: 0 0 null: 0 0 md5: 0 0 sha1: 0 0 sha256: 0 0 sha384: 0 0 sha512: 0 0 NOTE if you have a entry within SOFTWARE it is not accelerated. Often or allways the case for Policy Based VPN' s. This red line can be used for ALL VPN' s between FGT. If you have other devices in use like Cisco etc. you have to do a little research on the Web or on Knowledgebase of Forti to find out what has to be configured on FGT: http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=FD30603 Example if you would like to configure between FGT and Astaro a connection you have to follow following: http://www.sophos.com/de-de/support/knowledgebase/116130.aspx NOTE is only a example :) to show you that it differs from the red line explained here. hope this helps.... have fun Andrea
NETWORK_USER
New Contributor

Hello Bob and Andrea! Thanks for your response. The tunnel i configured is interface based and I do have static routes for remote LAN configured on each tunnel endpoint. What I dont understand is why is the fortigate not able to route traffic to its own connected network? From what I can see both the fortigates are able to see the remote lan. They also route the traffic for remote lan over the tunnel and I can see those packets coming in on the VPN interface (Phase 1 interface I created), but they are not routed out the local lan interface by either fortigates. why? It works all fine until the last local hop on the fortigate. eg: host a -->Fortigate1 -----tunnel----Fortigate2-----host b so what i see is that when host a sends a packet to host b, I see that packet reach the VPN interface on Fortigate2, but I dont see it on the lan interface where host b is connected. Also, I don' t understand why my static route should have a lower distance than the default route? I have one static route on each fortigate for the remote network for that fortigate with next hop through VPN interface. I assume since this is a specific route the default should not matter.
rwpatterson
Valued Contributor III

1) If the distance of the static route is higher (or maybe the same) the FGT will send the packet out the default since it' s closer. The VPN would not get used at all. Look into the routing table to see if the VPN route exists. (this isn' t your issue) 2) Do you have 2 policies on each FGT? You need one for outgoing traffic and a second for incoming traffic. With the older policy based, one was all that was required. Not the same with interface based.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
NETWORK_USER
New Contributor

Hello Bob, I think the second point you mentioned is my issue. I have only one policy on each fortigate. What is the second policy I need to implement? Right now I have a policy as below: From To Source Dest Schedule Service Action Lan_int VPN_int local_lan remote_lan always all allow Thank you.
rwpatterson
Valued Contributor III

Flip the incoming and outgoing.
From... To....... Source...... Dest...... Schedule Service Action VPN_int Lan_int remote_lan local_lan always.... all...... allow

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
NETWORK_USER
New Contributor

That was it! Thanks Bob!!
rwpatterson
Valued Contributor III

Any time. That' s why we' re here.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
taheireem
New Contributor

 

Even I have faced the same issue but figured it out as it was related to upgrading of FortiOS.

 

Labels
Top Kudoed Authors