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

Virtual IP - problem

Hello,

Im a new user of fortigate devices and need your help.

Im trying to configure external access to the web service and unfortunately Im not successful.

 

My configuration:

Web server(Apache) - 10.0.8.88/24 (site is available locally by https)

Interface - 10.0.8.1/24 

Virtual IP:

-External IP (my public ip)

-Map to Web server (10.0.8.88)

-Port forwarding 8000> 443

When trying to connect MyPublicIP:8000 I get message "This site is unreachable".

 

From the logs I get the information that it cannot find the right policy, which is incomprehensible to me because I have this one.

 

Incoming interface(WAN1(public ip)) > Outgoing Interface (10.0.8.1/24).

 

Please help,

Lukas

Interfaces.PNGlog.PNGPolicy.PNGVirtualIP.PNG

 

 

1 Solution
Anonymous
Not applicable

Hello

 

I guess from debugs you are matching policy zero as default

I would advise to check routing for internal subnet 10.0.8.1/24

I guess is internaly connected , but  can you try policy route simulator to check the traffic path

 

In order to have an uderstanding how the Fortigate does handle the traffic, please run debug flow and packet sniffer as below:

Please run these debugging commands while connected to fortigate via two ssh sessions:
 
NOTE: SSH Session 1 and SSH Session 2 are separate simultaneous SSH connections.
It means that they must be running simultaneously. Otherwise, this gathered data will not be useful for troubleshooting
 
NOTE : Before running below mentioned commands, make sure that you capture console output to a file.
Please follow below link to capture the output in the text file with Putty:
a) SSH Session 1(Sniffer.txt):
diag sniffer packet any "host 10.1.1.1 or host 192.168.99.2" 6 0 l
 
b) SSH Session 2(Debug.txt):
diag debug reset
diag debug console timestamp enable
get router info routing-table all
get router info routing-table details
get router info routing-table database
get router info kernel
diag ip arp list
diag ip address list
diag ip rtcache list
diag debug flow filter clear
diag debug flow filter addr 10.1.1.1 192.168.99.2 or
diag debug flow trace start 10
diag debug enable
 
Run the above-mentioned commands and then try to connect to 192.168.99.2. After the connection attempt, stop the sniffer and debug.
 
To stop the debug, type:
diag debug disable
diag debug reset
diag debug flow trace stop
 
To stop the sniffer, press "CTRL + C".

 

Once done, attach the outputs to the thread

 

View solution in original post

9 REPLIES 9
Anonymous
Not applicable

Hello

 

I guess from debugs you are matching policy zero as default

I would advise to check routing for internal subnet 10.0.8.1/24

I guess is internaly connected , but  can you try policy route simulator to check the traffic path

 

In order to have an uderstanding how the Fortigate does handle the traffic, please run debug flow and packet sniffer as below:

Please run these debugging commands while connected to fortigate via two ssh sessions:
 
NOTE: SSH Session 1 and SSH Session 2 are separate simultaneous SSH connections.
It means that they must be running simultaneously. Otherwise, this gathered data will not be useful for troubleshooting
 
NOTE : Before running below mentioned commands, make sure that you capture console output to a file.
Please follow below link to capture the output in the text file with Putty:
a) SSH Session 1(Sniffer.txt):
diag sniffer packet any "host 10.1.1.1 or host 192.168.99.2" 6 0 l
 
b) SSH Session 2(Debug.txt):
diag debug reset
diag debug console timestamp enable
get router info routing-table all
get router info routing-table details
get router info routing-table database
get router info kernel
diag ip arp list
diag ip address list
diag ip rtcache list
diag debug flow filter clear
diag debug flow filter addr 10.1.1.1 192.168.99.2 or
diag debug flow trace start 10
diag debug enable
 
Run the above-mentioned commands and then try to connect to 192.168.99.2. After the connection attempt, stop the sniffer and debug.
 
To stop the debug, type:
diag debug disable
diag debug reset
diag debug flow trace stop
 
To stop the sniffer, press "CTRL + C".

 

Once done, attach the outputs to the thread

 

lukas_k
New Contributor II

Thank you, I sent the log in a private message.

SveN2
New Contributor

Hi,

 

you are saying "Incoming interface(WAN1(public ip)) > Outgoing Interface (10.0.8.1/24)."

But looking at the screenshot of that firewall policy it says "virtual-wan-link" as incomming interface. Change that to wan1 and try again.

 

lukas_k
New Contributor II

It is wan 1 (SD-WAN Zone)

anikolov
Staff
Staff

Make sure that in the routing table you have a route for the source through the wan1 interface since this is the interface from which you expect the traffic. The return traffic will follow the default routing table from "get router info routing-table all", so if this traffic leaves from other interface, this traffic will be dropped.

Aleksandar Nikolov
funkylicious
Contributor III

Also, an idea would be to : set preserve-session-route enable , under each wan interface in the sdwan zone, if not already.

geek
geek
Mohamed_Gaber
Contributor

I see a message "The interface-subnet address assigned to this interface is currently in use and will not be detected". 

Is there a conflict?

Mohamed Gaber
Cell : +201001615878
E-mail : mohamed.gaber@alkancit.com
Mohamed GaberCell : +201001615878E-mail : mohamed.gaber@alkancit.com
lukas_k
New Contributor II

I managed to solve the problem. 

Thank you for your help in particular ethomollari and anikolov thanks to them I retraced the entire path along with debugging and observed that there was a lack of communication between local policy and dmz(somehow I didn't think of that after all it's the first thing to check ) and from the outside there was also a lack of allowed ip in the source in my case I just had to add the appropriate ip addresses that can connect from the outside.

Anonymous
Not applicable

Thats great

Thanks for sharing the complete solution with our community

Labels
Top Kudoed Authors