Skip to main content
edwallig
edwallig
New Member
December 8, 2017
Solved

dial-in VPN traffic routing problem

  • December 8, 2017
  • 1 reply
  • 20012 views

Hi all,

 

OK, two sites, HQ and branch1. HQ has a static IP directly connected to the FGT, branch1 has a dynamic IP and NAT router in front of it. On one of the HQ subnets I have computers that need to access both the Internet (via HQ DG) and 2 subnets at branch1. I have set up a dial-in style IPSEC VPN and it is connecting just fine. I've added a policy from the HQ subnet to the branch1 subnets using the dial-up VPN interface as the dst if and created a reciprocal policy for incoming traffic using the dial-up interface as the src if. There are no UTM components (AV, IDS, etc.) configured on these policies. Since it's a dial-in VPN I cannot set static routes on the dial-in "server" (HQ FGT) but I do have a static route on branch1's FGT to the HQ subnet via the VPN tunnel.

 

From a laptop at branch1 I can access resources behind HQ's FGT. From the console on HQ's FGT I can ping resources behind branch1's FGT. However, when I try to access resources at branch1 from a laptop on HQ's subnet, no joy...I don't even see traffic when running the sniffer on HQ's FGT. I can confirm that the tunnel is up and again, if I set source on the HQ console and ping the branch1 resource, it replies.

 

After working thru the forum I found this command "diag debug flow trace start 1000" which I ran - looks like the ping attempt is being processed by the firewall policy that handles normal Internet traffic for that subnet and not the policy that would allow it into the tunnel (WAN IP hidden):

 

(image attached)

 

In the snippet above, I see "ifindex-9" which correlates to my WAN port. "Policy 69" is the policy that allows traffic from this subnet to the Internet; the policy ID's for VPN traffic to/from branch1 are 76/87, respectively so it seems that the FGT is finding the first policy that works and trying to route. I can't move the tunnel policy higher since it uses the dial-in interface so a bit stuck at the moment.

 

Any help is appreciated, thanks in advance.

    Best answer by ede_pfau

    my 2 cents:

    get away from the dial-in VPN setup and just use 'Dynamic host' as your branches do not have static IP WAN addresses.

    The main reason is that for a dial-in connection the FGT will create an ad-hoc route, as a host route (/32). Have a look at the Routing Monitor to see if this is the case here as well. You cannot follow that route to the subnet behind the remote FGT - if you see successful pings from HQ to remote then you ping the FGT itself, not a host behind it.

    You would only need to use dial-in VPNs for entire networks if the remote branch was assigned a private IP address by the ISP. As this is not the case, use the right method. You will have to re-write the VPNs from scratch.

    1 reply

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    December 8, 2017

    If you're phase2 traffic selectors include the subnet at the branch, the tunnel would insert appropriate static routes into HQ FG's routing table so you shouldn't have this one-way problem. You need to have the specific route on HQ side, otherwise it would just follow the default route.

    edwallig
    edwalligAuthor
    New Member
    December 11, 2017

    Hi,

     

    thanks for the reply - I have the initial problem fixed...it turned out to be a problem with my switching architecture and nothing with the FGT setup so now I can ping both ways.

     

    New problem - I have to add another branch (call it branch2) to the mix and it needs to access resources both at HQ and at branch1. Just like branch1 it has to connect using the "dial in" option; it connects just fine and I can ping both ways from HQ to branch2. However, I'm having trouble passing traffic between the spokes; ping traffic from branch2 is not reaching branch1 (and vice-versa) and I don't see the ping traffic at HQ when running "diag sniffer packet any icmp" (not sure if I would?). I have static routes on each branch pointing to the other branch via the VPN tunnel and have policies on each branch to all traffic from the other.

     

    I've read a number of Fortinet KB articles on how to allow spoke to spoke traffic; none seem completely relevant due to the dial-in nature of the spokes. For example, I can't create a "zone" for the VPN interfaces....no option appears to add the specific interface when creating a zone. I also tried the "concentrator" path - same issue, no tunnels available. I tried to simply create a policy using the vpn interface and both source and dest but that doesn't seem to work either. I can confirm that both subnets do show as connected via the VPN interface (see attached) and I can ping either remote FGT from a laptop on the HQ subnet....just can't ping spoke to spoke.

     

    Any guidance on resolving this? thanks again...

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    December 11, 2017

    I'm not sure if FortiGate allows dialup-client to dialup-client talks on the same (phase1) interface. You might want to wait until somebody else chimes in. But we regularly use "dynamic" instead of "dialup" w/ aggressive mode (if IKEv1) in case like yours. You have to use a combination of localid/peerid to control which terminates which. Then you would have two separate interfaces for two remote locations so that you can set policies to control traffic flow between them at HQ FG when you need it.

    Terms & ConditionsAccessibility statement