VPN tunnel not automatic up

[#1]

Hi Still working on my problem with VPN. Following situation: I configured a VPN with a remote service provider. When I bring the VPN with the monitor up the VPN works With the regarding policy (destination address specified, Action is IPSEC, policy is the first in the list) nothing happens. All pings don' t reach the server and traceroute ends from an internal client at the internal interface of the fg100a. I don' t understand why the tunnel does not go up. Only special thing in this configuration is, that I need special source adresses for the provider. So I used th quick mode selector and defined the proxy sources and destinations. Any help or idea is welcome. Try to solve the problem sind 9 o' clock in the morning (now 8 hours) Thanks Oliver

[abelio]

if you run 2.80 OS, you could use VPN->Ipsec->" Tunnel Keep-Alive Configuration" configure until 2 source/destination IP numbers belonging each pair at private lan sides (under Phase2->Advanced button, select " Autokey Keep Alive" enable box) if you run 3.0 OS, you could directly set the same with CLI

 config vpn ipsec phase2
   edit " your_phase2_vpn_name" 
   ....your options here...
   set auto-negotiate enable
   next
 end
 

[#3]

Thanks. I will try it. But I' m not sure that it will work, but maybe I' m wrong. Seems that the system could not connect to the systems behind the tunnel endpoint on the remote site. I will post my experiences. Unfortunately here in Germany is it now 9 o' clock in the evening and the provider closed his lines. So I have to wait until tomorrow morning. rgds Oliver

[#4]

OK The auto-negotiate enable does not solve the problem. After doing some more test I found out the following: The provider expects special IP adresses. So I defined in the Quick mode selector of phase2 the source proxy ip and the destination proxy id. When I do this, I can establish the tunnel from the VPN monitor. But there is no reaction of the tunnel when I ping a remote server, even there is no answer when I ping the remote server after a manuell tunnel up. So it seems to me that the system is confused about the proxy source I specified (because it' s another one then the internal). Maybe I need a routing entry between the internal network and the proxy source network which I specified in the quick mode selector? Or maybe I could specify the sender IP adress in another way then the quickmode selector. I tested out natip but the remote side told me that I do not come with the correct IP. So I could not establish a tunnel. Any ideas? Thanks Oliver

[abelio]

ok, we' re in a previous step; sorry, i understood another thing; you have not a functional vpn at all (yet) Post some extra info to us to understand your scenario OS 2.80 or 3.0? If the provider expect special IP address, you have to define that as a selector source address Check with them if they' re receiving the correct IP address they' re waiting for. If you' ve specified " ipsec action" in your policy you don' t need extra routes to reach; you' re on ' policy-based mode" vpn.

[#6]

Hi abelio, first of all thanks for your help. OK here are some additional infos: FG100A OS3.0 I try to describe it in other words. Maybe my last posts were not clear enough. I have a internal class C network 192.168.... The internal network card of the FG is connected to this network. The wan1 is directly connected to the internet with an official IP address. The provider also has an official IP address on his internet gateway. Now we need a VPN between this two points. So my endpoint is wan1 and the endpoint of the provider is his gateway. The provider expects that the IP packets which come throught the tunnel have special IP addresses 10.172.x.x. This IP range is given to me from the provider. Next the provider expects that the packages only go to a special subnet in his environment (10.192.x.x/24). The server that I need to reach is this 10.192. subnet. This is the environment. What I did is the following: I created a VPN with the neccessary parameters. To follow the recommandations of the provider I defined in the advanced settings of phase 2 in the quick mode selector the source address 10.172.x.x/29 and in the destination address 10.192.x.x/24. Also I defined a firewall policy with Source NIC:internal ADDRESS:all. Destination NIC wan1 ADDRESS:10.192.x.x. SCHEDULE:always, SERVICE:any; ACTION:encrypt and choose the tunnel (no mistake I only have one tunnel). This policy is the first in the list. What I can do with the tunnel is, that I can establish the tunnel. So tunnel is up when I initiate it from the VPN monitor. Also it is up when I do a diagnose vpn tunnel up and the debug info of application ike is also OK. The provider aggreed that everything is OK. I come in with the right IP address (10.172.x.x) and the packages only go to the needed subnet (10.192.x.x) My problem is, that I can' t use the tunnel. So even when I manually establish the tunnel no data is going through the tunnel. Doing a traceroute from an internal system ends at the FG internal NIC. Doing a traceroute from the FG does not give a first hop back only ***. So it seems to me that the internal requests are not correctly translated to source address which I defined in the vpn phase 2 advanced settings.

[abelio]

Hello again, thanks for clarify, I cannot see any relationship between the subnet your peer expects 10.172.x.x/29 and your internal lan 192.168.Y.x/ 24, there' s no reason for packets to flow between subnets question : did you enabled " natoutbound" in your ipsec firewall policy? if so, remember that natip is enabled in 3.0, in that case your internal based packets go away with your 100A public ip address. if you configure within your phase 2 " use-natip disable" (natoutbound enabled in your ipsec policy), the selector source you' ve specified in src-subnet (your 10.172.x.x/29 ) will be used. Anyway, even in this case, i' m not sure if one-to-one map will work in this case ( 192.168.x.{1-7} translated to 10.172.x.{1-7}) due mainly different subnet masks If that worked, only it would be for that sub-group /29 of your internal /24 net)

[red_adair]

Is it policy-VPN or IPSec-Interface VPN ? (your description points to policy-vpn; but just to make sure) Are routes set correctly ? (Maybe you can post snippets for these) In case of policy vpn your route have to point to the WAN-IF, for IPSec-Interface-VPN it has to point to that " new" Interface. # diag sniff pack <if-name> ' icmp' 4 [<if-name> can be " any" or the phy-IF name or the IPSec-Tunnel-Interface name] may help you to see where ICMP travels along, if. Are you sure that SA is established ? #diag vpn ipsec tunn lis -R.

[#9]

It is a policy VPN. But now there is the interesting point. Which routes do you mean?? Do I have to define special routes for the target network? This is point I stuck. And yes, the tunnel is established. As I wrote I think it is a routing problem and you gave the same direction in your post. Normally in my VPN' s I just define the action encrypt on the policy and everything is OK. But to be open, then the target server always was in the same subnet as the tunnel endpoint. ***************************************** Fortigate-100A # diagnose vpn tunnel list list all ipsec tunnel in vd 0 ------------------------------------------------------ name=KID_Personal 87.x.x.x:0->62.x.x.x:500 lgwy=dyn tun=tunnel mode=auto bound_if=10 proxyid_num=1 child_num=0 refcnt=5 ilast=2 olast=2 stat: rxp=0 txp=0 rxb=0 txb=0 dpd: mode=active on=0 idle=5 retry=3 count=0 seqno=42 natt: mode=none draft=0 interval=0 remote_port=500 proxyid=KID_Tunnel proto=0 sa=1 ref=2 auto_negotiate=0 src: 10.172.x.x/255.255.255.248(4):0 dst: 10.192.x.x/255.255.255.0(4):0 SA: ref=3 options=00000008 type=00 soft=0 mtu=1428 expire=28772 replaywin=0 life: type=01 bytes=0/0 timeout=28775/28800 dec: spi=2a5b2450 esp=3des key=24 887642f65a3916fa8eb8axxxxxxxxxxxxxxxxx ah=md5 key=16 0bdc7df6152c4fb3xxxxxxxxxxxxx enc: spi=700338fd esp=3des key=24 ee8f0ee4c597b446d76275b63cxxxxxxxxxxxxx ah=md5 key=16 99379b31712af1f7ee8dxxxxxxxxxxxx *****************************************

[#10]

Hi Abel, thanks for your thoughts. The relationship between my internal network and the expected network is indeed the problem. To your questions: I played around with natip settings. One problem was, as you thought, that I do not have a corresponding subnet mask. So the one to one translation didn' t work. So the only solution was, that I specify the selector source and target. Only with this setting I came with the right IP address to the provider. OK but for me the question now is, how could I create a relationship between the internal addresses and the required addresses? Normally there should be way. I don' t think that this so an exotically configuration and there are other vendors like CISCO or LANCOM which are able to deal with that configurations.