New Member

Solved

Virtual IP - problem

Forum|Forum|3 years ago
December 21, 2022
7 replies
4691 views

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

FortiGate

Best answer by Anonymous_User

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:

https://my.kualo.com/knowledgebase/?kbcat=0&article=888

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

Anonymous_UserAnswer

New Contributor III

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:

https://my.kualo.com/knowledgebase/?kbcat=0&article=888

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

New Member

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

New Member

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.

New Member

It is wan 1 (SD-WAN Zone)

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.

SuperUser

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

"jack of all trades, master of none"

Explorer III

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?

New Member

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.

New Contributor III

Thats great

Thanks for sharing the complete solution with our community