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

80C(v5.2.6) to 200B(v5.0.12) IPsec VPN is up, but no traffic

Ive re-done this thing 3 times now and still no go! :)

 

At the office, 80C(v5.2.6). At the data center 200B(v5.0.12). I have the VPN setup, the policies setup and the routing setup. The VPN monitor is showing as up at both ends. I can also up/down the VPN from both ends. Ive checked the cli debug log for the VPN and seems to be no errors at all. However, the policies remain with 0 packets and im not seeing anything in the policy logs (set to debug). I try to ping/etc anything at the other end of the VPN (from both ends) and it just goes no where. traceroute shows it going nowhere as well.

 

Can anyone shed some light? Is it compatibility issues between 5.2 and 5.0 or something?

 

Here is a link to some screenshots showing the setup of both the 80C and the 200B. In order top down: 80C setup, 80C policy, 200B setup, 200B policy. Im not showing the routing here.. as its just set and forget right? :)

 

[link]http://imgur.com/a/1lXWd[/link]

 

Help! :) thanks.

9 REPLIES 9
neonbit
Valued Contributor

Have you performed a [link=http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD30038&languageId=]diag debug flow filter [/link]on the traffic? Ifso are you provide the output?

 

I have a feeling that there may be an issue with your Phase2. I can see that you've blurred out one of the IP addresses. Just to confirm, is this the public IP address? This should be the internal subnet of that site.

 

Also could you please confirm that your routes are configured correctly?

 

One side should have this:

 

Network: 192.168.1.0/24

Gateway: Office-VPN

 

The other should have this:

 

Network: (local subnet that is blurred out)

Gateway: DC-VPN

 

When the VPN is up but there is no traffic it's usually one of two things, the routing is wrong or the policies/QMS are wrong.

greminn
New Contributor III

neonbit wrote:

Have you performed a [link=http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD30038&languageId=]diag debug flow filter [/link]on the traffic? Ifso are you provide the output?

 

Not as yet - i will get that ASAP.

 

neonbit wrote:
I have a feeling that there may be an issue with your Phase2. I can see that you've blurred out one of the IP addresses. Just to confirm, is this the public IP address? This should be the internal subnet of that site.

 

In terms of the Phase2 with the possible issue.. is this the 80C (top screenshots) or the 200B (lower screenshots)? If this is the 200B (data center), the i have source address = xxx.xxx.127.0/24 (our data center public IP range) and destination address = 192.168.1.0/24 (internal office network). And this is reversed on the 80C (office). 

 

neonbit wrote:
Also could you please confirm that your routes are configured correctly?

 

One side should have this:

 

Network: 192.168.1.0/24

Gateway: Office-VPN

 

Yes - at the 200B (data center) end this is correct.

 

neonbit wrote:
The other should have this:

 

Network: (local subnet that is blurred out)

Gateway: DC-VPN

 

Yes - at the 80C (Office) end this is correct.

 

PS: thanks for the reply!

greminn
New Contributor III

OK, further to this - i have enabled the debug log from a workstation on the office side (192.168.1.10) to a server at the DC end (xxx.xxx.127.38). The main message is "Denied by forward policy check (policy 0)", so i understand that in theory there is no policy capturing the packets, so its hitting the default deny all?

 

Full log output: http://pastebin.com/nZnuy7Xv

 

I had thought i had the policies correct tho.. 

 

Simon

neonbit
Valued Contributor

Hi Simon,

 

Thanks for that, it looks like a policy issue on the FG80C is causing the problem (the routing looks fine).

 

I would recommend double checking the values of VPN-DC-Network and VPN-Office-Network and confirming that the IP addresses and subnet masks configured for each is correct (xxx.xxx.127.0/24 and 192.168.1.0/24). Also could you please confirm if wan2 is the network configured on the 192.168.1.0/24 subnet?

greminn
New Contributor III

neonbit wrote:

Hi Simon,

 

Thanks for that, it looks like a policy issue on the FG80C is causing the problem (the routing looks fine).

 

I would recommend double checking the values of VPN-DC-Network and VPN-Office-Network and confirming that the IP addresses and subnet masks configured for each is correct (xxx.xxx.127.0/24 and 192.168.1.0/24). Also could you please confirm if wan2 is the network configured on the 192.168.1.0/24 subnet?

Thanks again for the reply neonbit!

 

On both devices: VPN-DC-Network = xxx.xxx.127.0/24 & VPN-Office-Network = 192.168.1.0/24 (i think the 200B firmware displays this as 192.168.1.0/255.255.255.0) And yes at the branch office, we are using WAN2 as "internal" (we have a gig ethernet connection.. the 80C has gig WAN1/2 ports but only 100 internal ports - we want to use our fast connection!).

 

As a side note, the VPN-* addresses are currently set to Interface = any on the 200B (in Policy > Objects > Addresses). Would this create issues? (i didnt thing so). 

 

Considering we have a NATed connection at the branch and a public IP range at the data center.. do any of these polices on either device need NAT on? 

 

Simon

 

 

 

neonbit
Valued Contributor

The interface=any thing doesn't matter. This just determines which addresses show up when creating policies.

 

I don't believe NATing will be required for now, the problem is that the 80C is not even matching a policy to send the data across... it's weird.

 

You could try to configure all the quick mode selectors to be 0.0.0.0/0.0.0.0 for local/remote subnets on both firewalls to see if there's a problem there (the policy can control which subnets can talk over the VPN).

 

Ideally if it's possible I'd love to see the CLI outputs for the DC-VPN interface, DC-VPN route, policy (#4) and address variables from the FG80C (with the blurred IP addresses replaced with something else & passwords removed).

 

Otherwise I'm kind of stumped :)

greminn
New Contributor III

neonbit wrote:
I don't believe NATing will be required for now, the problem is that the 80C is not even matching a policy to send the data across... it's weird.

 

We have just moved the office location. A strange thing you mention that, i had pre-configured the 80C for this office, but when we plugged it in, the internal->WAN1 policy would not work when the source was set to 192.168.1.0/24 (destination = all). On the off chance i changed that policy to all->all and it worked - WTF? Changing back to 192.168.1.0/24->all just would NOT work. I factory reset the firewall reset things and now 192.168.1.0/24->all works as expected. I wonder if this is related... maybe a bug in 5.2.6?

 

neonbit wrote:
You could try to configure all the quick mode selectors to be 0.0.0.0/0.0.0.0 for local/remote subnets on both firewalls to see if there's a problem there (the policy can control which subnets can talk over the VPN).

 

Tried - nope :)

 

neonbit wrote:
Ideally if it's possible I'd love to see the CLI outputs for the DC-VPN interface, DC-VPN route, policy (#4) and address variables from the FG80C (with the blurred IP addresses replaced with something else & passwords removed).

 

Otherwise I'm kind of stumped :)

 

As is me! 

[link]http://pastebin.com/PPvuKv9K[/link]

neonbit
Valued Contributor

The config looks good, the only thing I would test is to remove the devices in policy 6 (on FG80C highlighted below) and just have the policy filter by source address.

 

edit 6

        set srcintf "wan2"         set dstintf "DC-VPN"         set srcaddr "VPN-Office-Network"         set dstaddr "VPN-DC-Network"         set action accept         set schedule "always"         set service "ALL"         set devices "VPN Access Devices"     next

end

greminn
New Contributor III

OK! lets put my dumb ass nubie hat on! 

 

^dumbassnubie: lets try making sure that xxx.xxx.127.0 is actually the correct IP :) i must have cut and pasted it everwhere after getting it wrong in the first place!!!! 

 

LOL..

 

Thanks for all your assistance.

 

Simon

Labels
Top Kudoed Authors