VPN tunnel, cannot initiate traffic from remote site

[Shagma]

I have some difficulties with a hub and spoke configuration. I have followed the Handbook examples on how to set up a hub and spoke network. The network consists of only 60c' s, all 4.0 MR2. There' s one 60c at main and two remotes at the moment. I experience the problem at both remote locations and the configuration is almost identical. Descritption of problem: Remote sites can contact main site over IPSEC after establishing tunnel. The next time the tunnel is established, the remote site cannot contact main site over IPSEC tunnel. If I initiate communication from main, I am also able to establish communication from remote to main. This works until tunnel has to be re-initiated, then the same thing happens. From what I' ve been able to gather from diagnostics through CLI, the remotes seems to pass traffic to main through IPSEC tunnel interface, but I can' t see any replies from main. It' s a bit like this guy' s problem, only his configuration differs a little: http://support.fortinet.com/forum/tm.asp?m=68738&p=1&tmode=1&smode=1 Routing table remote site: S* 0.0.0.0/0 [10/0] via 212.33.132.241, wan1, [0/50] S 192.168.0.0/24 [10/0] is directly connected, toHub C 192.168.2.0/24 is directly connected, internal1 C 212.33.132.240/30 is directly connected, wan1 Routing table main site: S* 0.0.0.0/0 [10/0] via 77.241.103.13, wan1, [0/50] C 77.241.103.12/30 is directly connected, wan1 C 192.168.0.0/24 is directly connected, internal S 192.168.2.0/24 [1/0] is directly connected, toSpokes_0 Remote site IPSEC Ph1: config vpn ipsec phase1-interface edit " toHub" set interface " wan1" set proposal 3des-sha1 aes128-sha1 set remote-gw 77.241.103.14 set psksecret ENC 7s2wTnNbvhLXXyhlY673G6JS2pHlmdNkJ81WV5EGqZ222iLqNho18s/EY+FHCXCL/tlei4R46NI+3bQLtw81xJwdRCBFTOlUuwWKVpM/PU44Sy4H next end Main site IPSEC Ph1: config vpn ipsec phase1-interface edit " toSpokes" set type dynamic set interface " wan1" set proposal 3des-sha1 aes128-sha1 set psksecret ENC TG+HIeYCE8LEvnuPoqRgOe5P7Pbe/h05DSKDd7zBPbJt2SJwXVtblXrOw8pxA1+AOe7zVACCU0w0UGprWWjs070EdSdArDwtVyXbNL1n1kdsnF9s next end Remote site IPSEC ph2: config vpn ipsec phase2-interface edit " toHub P2" set phase1name " toHub" set proposal 3des-sha1 aes128-sha1 set dst-subnet 192.168.0.0 255.255.0.0 set src-subnet 192.168.2.0 255.255.255.0 next end Main site IPSEC Ph2: config vpn ipsec phase2-interface edit " toSpokes P2" set phase1name " toSpokes" set proposal 3des-sha1 aes128-sha1 next end Firewall policies remote: config firewall policy edit 3 set srcintf " internal1" set dstintf " wan1" set srcaddr " Internal Net" set dstaddr " all" set action accept set schedule " always" set service " ANY" set nat enable next edit 2 set srcintf " VPN Zone" set dstintf " internal1" set srcaddr " Spoke Net" set dstaddr " Internal Net" set action accept set schedule " always" set service " ANY" next edit 4 set srcintf " internal1" set dstintf " VPN Zone" set srcaddr " Internal Net" set dstaddr " Spoke Net" set action accept set schedule " always" set service " ANY" next edit 5 set srcintf " dmz" set dstintf " wan1" set srcaddr " all" set dstaddr " all" set action accept set schedule " always" set service " ANY" set nat enable next edit 6 set srcintf " wan1" set dstintf " internal1" set srcaddr " all" set dstaddr " Klient" set action accept set schedule " always" set service " ANY" next end Firewall policies main: config firewall policy edit 1 set srcintf " internal" set dstintf " wan1" set srcaddr " all" set dstaddr " all" set action accept set schedule " always" set service " ANY" set nat enable next edit 2 set srcintf " wan1" set dstintf " internal" set srcaddr " all" set dstaddr " Sofus Server" set action accept set schedule " always" set service " RDP" set nat enable next edit 3 set srcintf " VPN_Zone" set dstintf " VPN_Zone" set srcaddr " Spoke Net" set dstaddr " Spoke Net" set action accept set schedule " always" set service " ANY" next edit 4 set srcintf " VPN_Zone" set dstintf " internal" set srcaddr " Spoke Net" set dstaddr " HK Nettverk" set action accept set schedule " always" set service " ANY" next edit 5 set srcintf " internal" set dstintf " VPN_Zone" set srcaddr " HK Nettverk" set dstaddr " Spoke Net" set action accept set schedule " always" set service " ANY" next end

[rwpatterson]

ORIGINAL: Shagma Remote site IPSEC ph2: config vpn ipsec phase2-interface edit " toHub P2" set phase1name " toHub" set proposal 3des-sha1 aes128-sha1 set dst-subnet 192.168.0.0 255.255.0.0     this subnet is a superset of the one below set src-subnet 192.168.2.0 255.255.255.0 next end

When trying to open an IPSec connection from the remote, the local LAN is part of the remote subnet scope. Change the main subnet mask, or network ID of the main (or at least change the remote to 172.16.0.x) or some other non ambiguous scope and give it a try. My opinion...

[Shagma]

While i cannot say that you are wrong, due to my limited understanding of the subject, I did try to follow the example in the Handbook. Would you mind taking a look at these manual pages? http://docs.fortinet.com/fgt/handbook/html/hub-and-spoke.81.6.html http://docs.fortinet.com/fgt/handbook/html/hub-and-spoke.81.26.html Does my config represent whats outlined there?

[ede_pfau]

Me too. I don' t think your tunnel config is wrong. Basically I trust the Handbook. From your description though I suspect that the tunnel times out asymmetrically. Picture this: - tunnel is going UP - tunnel (key or idle timer) time limit is reached on remote side but tunnel SA is still valid at the hub - remote tries to rekey which fails because the old SA still exists - some time later, the SA expires - now the remote side can establish a tunnel again To test the theory, could you please do the following: - open command line windows via ssh to both units (hub, spoke) - assuming tunnel is down: on the remote: exec ping <private IP of hub internal interface> -> tunnel is UP, ping replies come in - wait 5 minutes until pings die - now on the HUB do a ' diag vpn tun flush' this removes the stale SA - on the remote, try to ping if the theory is right, you can now get the tunnel UP again. The ' diag vpn tunnel' command has more helpful commands like - stat - list - up - down HTH.

[Shagma]

I tried doing what you said, but somehow I must have messed up the configuration even more so I just gave up the whole hub&spoke thing. I have now configured main and remote with GW to GW. I' m planning on doing this for every remote site. There will just be 4 remotes so it shouldn' t be a problem I think. Sadly I am now faced with a new problem. The tunnel is up but response to ping from the main does not get through. I monitored the traffic on both ends, and main sends echo' s to remote, but the remote never receives them. I have configured a FW rule on remote like this: edit 4 set srcintf " internal1" set dstintf " MOLtoHK_tunnel" set srcaddr " Internal_Network" set dstaddr " HK_Network" set action accept set schedule " always" set service " ANY" edit 8 set srcintf " MOLtoHK_tunnel" set dstintf " internal1" set srcaddr " HK_Network" set dstaddr " Internal_Network" set action accept set schedule " always" set service " ANY" Static route: edit 2 set device " MOLtoHK_tunnel" set dst 192.168.0.0 255.255.255.0 Addresses: edit " HK_Network" set subnet 192.168.0.0 255.255.255.0 next edit " Internal_Network" set subnet 192.168.1.0 255.255.255.0

[ede_pfau]

and main sends echo' s to remote, but the remote never receives them

Might be a routing problem on the main site then. Check the static routes there, and the outgoing policy.

[Shagma]

I forgot to mention that main can ping remote just fine. Anyhow, here are the settings on main: set srcintf " HKtoMOL_tunnel" set dstintf " internal" set srcaddr " MOL_Network" set dstaddr " Internal_Network" set action accept set schedule " always" set service " ANY" set srcintf " internal" set dstintf " HKtoMOL_tunnel" set srcaddr " Internal_Network" set dstaddr " MOL_Network" set action accept set schedule " always" set service " ANY" set device " HKtoMOL_tunnel" set dst 192.168.1.0 255.255.255.0 edit " Internal_Network" set associated-interface " internal" set subnet 192.168.0.0 255.255.255.0 edit " MOL_Network" set subnet 192.168.1.0 255.255.255.0

[Shagma]

I' ve looked at the traffic flow and I think I know what the problem is. When the remote sends a packet to the other side, through the tunnel, the source address is set to external IP-address of the remote. Obviously the receiving end has some problems getting an answer back. Why is this happening?

[rwpatterson]

Check the policy for the tunnel, and ensure that NAT is not checked in it.

[Shagma]

Theres no NAT enabled as far as I can see.