What is wrong whit this policy?

[raffaeledp]

Hello everybody,

I'm the Fortigate 60F (v7.2.10) admin, and I log into it at:

https://vpn.xxx.com:40443/

or

https://10.1.0.1:40443/

I defined a local-in policy to momentaneously deny the access to this page to all the users. All the policy above this one are disabled:

edit 5
set uuid d5c73f7a-eae5-51ef-8ecd-4cb99f22bef3
set intf "any"
set srcaddr "all"
set dstaddr "login"
set service "HTTPS-40443"
set schedule "always"
next

The dstaddr is: 

while the service is:

I should access the login page from everywhere. Why? What I am doing wrong?

vpn.xxx.com is a DNS entry: 

 

 

[raffaeledp · Accepted solution]

Hello,

I found the solution. The problem was the address 79.x.x.x. You have to include inside the policy the private address of the interface (192.168.1.4, and not the public 79.x.x.x)

[dingjerry_FTNT]

Hi @raffaeledp ,

I tried using your local-in policy configuration and I got blocked.

So we can debug with the following commands:

diag debug flow show iprope enable

diag debug flow filter proto 6

diag debug flow filter addr 10.1.0.1

diag debug flow filter port 40443

diag debug flow trace start 100

diag debug enable

Then try it with https://10.1.0.1:40443/ first

[raffaeledp]

Hello, you are right. I noticed that when I'm inside the company network (so vpn.xxx.com is directly to 10.1.0.1) I'm blocked. Anyway, when I'm outside, and vpn.xxx.com is resolved to 79.x.x.x, I'm not blocked anymore. I tried to create the same policy (from 6 to 10) with dstaddre "79.x.x.x", but, I can reach vpn.xxx.com:40443. How is it possible? Thanks

[raffaeledp · Accepted solution]

Hello,

I found the solution. The problem was the address 79.x.x.x. You have to include inside the policy the private address of the interface (192.168.1.4, and not the public 79.x.x.x)

[dingjerry_FTNT]

Hi @raffaeledp ,

You confused me.

In your local-in policy, there was only one specific address "Login" applied and it is defined with this IP 10.1.0.1/32.   There was nothing about 192.168.1.4 for the configuration.

So do you mean that your VPN hostname (vpn.xxx.com) was directed to 192.168.1.4, not 10.1.0.1?

[raffaeledp]

Hello @dingjerry_FTNT ,

I'm sorry :)

79.x.x.x is the WAN IP.

From the external device, if I ping vpn.xxx.com, 79.x.x.x replies. 

I sniffed some packets on port 40443 filtering for dstaddr 10.1.0.1 and saw that packets were being forwarded from 192.168.1.4, and 192.168.1.4 is the wan interface address.

 

 

[dingjerry_FTNT · Accepted solution]

Hi @raffaeledp ,

That's not correct.  The WAN IP is something like you check your PC's WAN IP via https://www.whatismyip.com/ ,  the public IP is not configured on your PC directly. It's a NATted IP by your ISP.

It's the same thing for FGT. The real IP configured on the WAN interface on your FGT device is the one you configured, it might be 10.1.0.1 or 192.168.1.4, I don't know which one is because you never showed the FGT WAN interface configuration either in GUI or in CLI.

I suspect that 192.168.1.4 is the IP on your FGT WAN interface and 10.1.0.1 is the IP on your internal PC. 

That would explain why the local-in policy was not working

[funkylicious]

hi,

the dns entry is only significant to the firewall locally.

is vpn.xxx.com resolved by the workstation that you are connecting from, to the same private ip, 10.1.0.1 that would also match the object login that you defined in the local-in ?

if so, the commands that @dingjerry_FTNT provided should shed some light.