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

dial-in VPN traffic routing problem

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.

2 Solutions
ede_pfau
Esteemed Contributor III

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
Toshi_Esumi
Esteemed Contributor III

I was referring CLI config like below. But it's just an example so you need to modify whatever necessary. If you haven't used CLI before you need to refer to VPN handbook/Online Manuals for your version. I'm not sure how you could configure this via GUI.

 

<HUB/HQ side>

config vpn ipsec phase1-interface
edit "xxxxx1"
set type dynamic
set interface "xxx-rt1"
set mode aggressive
set proposal aes128-sha1
set localid "xxxxx-s"
set dpd disable
set psksecret xxxxxxxxxxx
next
end
 
config vpn ipsec phase2-interface
edit "xxxxx1-1"
set phase1name "xxxxx1"
set proposal aes128-sha1
set dst-subnet x.x.x.x 255.255.255.0
next

<Spoke/Remote side>

config vpn ipsec phase1-interface
edit "xxxxx1"
set interface "xxxx"
set nattraversal disable
set mode aggressive
set peertype one
set proposal aes128-sha1
set localid "xxxxx-r"
set remote-gw x.x.x.x
set peerid "xxxxx-s"
set psksecret xxxxxxxxxxxxx
next
end

config vpn ipsec phase2-interface
edit "xxxxx1-1"
set phase1name "xxxxx1"
set proposal aes128-sha1
set keepalive enable
set src-subnet x.x.x.x 255.255.255.0
next
end

View solution in original post

7 REPLIES 7
Toshi_Esumi
Esteemed Contributor III

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

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
Esteemed Contributor III

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.

edwallig

Thanks again - when you say "dynamic" what exactly do you mean? Can you provide an example config, screenshots, etc.? I'm familiar with the "dynamic DNS" option but guessing that you are referring to something else.

 

Thanks again...been banging my head on my desk for several days now on this so appreciate the help.

ede_pfau
Esteemed Contributor III

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Toshi_Esumi
Esteemed Contributor III

I was referring CLI config like below. But it's just an example so you need to modify whatever necessary. If you haven't used CLI before you need to refer to VPN handbook/Online Manuals for your version. I'm not sure how you could configure this via GUI.

 

<HUB/HQ side>

config vpn ipsec phase1-interface
edit "xxxxx1"
set type dynamic
set interface "xxx-rt1"
set mode aggressive
set proposal aes128-sha1
set localid "xxxxx-s"
set dpd disable
set psksecret xxxxxxxxxxx
next
end
 
config vpn ipsec phase2-interface
edit "xxxxx1-1"
set phase1name "xxxxx1"
set proposal aes128-sha1
set dst-subnet x.x.x.x 255.255.255.0
next

<Spoke/Remote side>

config vpn ipsec phase1-interface
edit "xxxxx1"
set interface "xxxx"
set nattraversal disable
set mode aggressive
set peertype one
set proposal aes128-sha1
set localid "xxxxx-r"
set remote-gw x.x.x.x
set peerid "xxxxx-s"
set psksecret xxxxxxxxxxxxx
next
end

config vpn ipsec phase2-interface
edit "xxxxx1-1"
set phase1name "xxxxx1"
set proposal aes128-sha1
set keepalive enable
set src-subnet x.x.x.x 255.255.255.0
next
end
edwallig

Hey thank you for the information and it will probably be helpful somewhere in the future. As far as this issue, I was able to work with the ISP and convert the accounts to static IP addresses. I then went back and set up normal site to side tunnels using custom templates, ensuring that NAT-T was on for the branch FGT with the NAT router in front of it. It took a bit of tweaking on the "hub" FGT to make it work (the phase2 settings seem weird) but after adding routes and policies for the tunnels all is well now...everyone can talk to everyone.

 

Thanks again! 

Labels
Top Kudoed Authors