Contributor

Question

VPN tunnel not automatic up

Forum|Forum|19 years ago
November 14, 2006
9 replies
7212 views

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

SuperUser

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

A

Anonymous_UserAuthor

Contributor

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

A

Anonymous_UserAuthor

Contributor

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

SuperUser

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.

A

Anonymous_UserAuthor

Contributor

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.

Zx69821.jpg

abelio

SuperUser

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

New Member

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.

A

Anonymous_UserAuthor

Contributor

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 *****************************************

A

Anonymous_UserAuthor

Contributor

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.

abelio

SuperUser

Hi, there' s no problem for FTG either to manage translations, but i think the problem is that your peer restricted this to a /29 and you need vpn services for a /24 subnet Did you tried ping other side with your ipsec policy " natoutbound" checked AND " use-natip disable" phase2 with source 192.168.x.1...6 ? Maybe anyone could help or we' re missing something else here?

red_adair

New Member

just to make sure: Your default GW (or a static route) that points to the Remote-Network hast to point to your WAN Interface. So traffic will be routed to the WAN Interface where it' s beeing catched by the VPN Policy and put into the Tunnel. You likely do not have to deal with NAT at all since you' re simply routing between 2 networks. Also make sure that the return-route is also set on the far end. -R.

A

Anonymous_UserAuthor

Contributor

Hi, many thanks to you, abelio and red.adair, for your advices. @abelio: Yes I tried this. The problem is, that the vpn is not established if I come in with another source than the 10.172.x.x. The provider also deals with policies. If there is another source than 10.172.x.x the vpn could not be established at all. @red.adair: I agree to your opinion. Normally it is just a LAN-LAN interconnection. So normally it should work with routing entries. The question for me is, when I define the policy that everything that goes to 10.192.x.x should be encrypted an should go through the tunnel normally this should be my first route. Independent of all other routes the vpn should go up, and if it only tries - but it should go up. OK. If it only goes up when the routes are OK the next question is, how does the FG knows that everything from the 10.192.x.x should be rerouted to the internals lan?? Where is the relationship between my internal lan and the proxy sources I have to specify?? If there would be a way to setup a relationship between let' s say 192.168.1.45 with 10.172.x.249 then I could imagine that this could work. Or if could work there with routes then I think there would be a way. Maybe you have an idea!?! I' m a little bit frustrated. I alway hear the same answers from the provider. There is no problem with CISCO or LANCOM. Good and correct information - because they sell this routers. Thanks for your endeavors.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded