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

Virtual Server Cannot Connect to Outside

Hi there,

         I'm new to fortigate. I am trying to figure out why a virtual server stuck at firewall without denied policy setup. It used to work. When I did traceroute on the server, it stopped at the firewall. I don't see any policy to deny the server. Is there any other troubleshooting I can do? Thank you. 

19 REPLIES 19
_aey_
New Contributor

Hi,

 

Can you check the logs ? When you write source and destination IP addresses in the logs filter, pls check the policy column and see the matched policy name. If the traffic match with deny policy, you should create a new policy to allow traffic.

polarpanda
New Contributor II

engineer56 wrote:

Hi,

 

Can you check the logs ? When you write source and destination IP addresses in the logs filter, pls check the policy column and see the matched policy name. If the traffic match with deny policy, you should create a new policy to allow traffic.

Thank you for replying my post, aey. Yes, I checked the logs and found the policy. It's the group from inside to outside internet with accepted source ip "all" (0.0.0.0/0) to destination ip "all" (0.0.0.0/0).

ede_pfau
Esteemed Contributor III

hi,

 

it works the other way around: without any ALLOWING policy there won't be any traffic. There's an implicit DENY ALL policy at the end of the policy table, invisible.

If you do have an outbound policy, be sure to have NAT checked (to the WAN's interface address) or reply traffic won't make it back to the FGT.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
polarpanda
New Contributor II

ede_pfau wrote:

hi,

 

it works the other way around: without any ALLOWING policy there won't be any traffic. There's an implicit DENY ALL policy at the end of the policy table, invisible.

If you do have an outbound policy, be sure to have NAT checked (to the WAN's interface address) or reply traffic won't make it back to the FGT.

Thank you for replying my post,ede. Yes, I knew that. So i have a question: does each server have to have its own policy in the firewall, even virtual server? If yes, I have two other vm servers in the same location (nutanix). I don't see both two servers have their own ALLOWING policy, but they're able to route outside internet.

 

Ede, another amazing expert in this post told me to check logs and I did. The policy it's in is source all (0.0.0.0/0) to destination all (0.0.0.0/0)

ede_pfau
Esteemed Contributor III

OK, so a 'all-to-all ACCEPT' policy is good for all servers/hosts on your LAN.

If only this one server does not correctly connect to a host on the internet, you could look into the traffic using the CLI (console window):

diag debug enable

diag sniffer packet any 'host 192.168.456.789 and icmp' 4

 

where you substitute the fake address with the source address of the server on your LAN. Then, start a ping on that server to 8.8.8.8 and record the output. You should see 'ICMP request' and 'ICMP reply' packets.

Maybe you could copy&paste the output and post it here.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
polarpanda
New Contributor II

Thank you Ede. Before I did the debug you recommended, I did tracert via CMD on the server. It cannot even reach the firewall this time. So i think it might not be the issue.

 

Do you think all to all would jam the traffic? If all the servers go through all to all, it would be really slow! So what's the best practice of policies for servers?

 

Thank you!!

ede_pfau
Esteemed Contributor III

Let's first fix the problem you posted. I don't think (at all) that traffic jam prevents replies from coming in.

If your server cannot reach the FGT check it's routing. The default route must point to the FGT's LAN interface address. A traceroute should at least show that ICMP traffic reaches the gateway.

 

@emnoc: Happy New Year, Ken! I knew you'd agree to use 'diag debug flow', even if I suggested 'diag sniffer'... :)

and you're right!


Ede

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

Ede  no problem. My hunch was right that the traffic is not reaching the  FW. BTW I will be Berlin in mid-Feb, I will try to ping you when I'm in Frankfurt if time persist.

 

Ken Felix

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
polarpanda
New Contributor II

Thank you! So i executed the diagnosis commands, then I did ping on the server. Nothing showed up on the CLI.  Then I did tracert 8.8.8.8, it did reach the firewall this time. So i'm confused why I don't see any ICMP capture.

 

 

Firewall01 $ diag sniffer packet any 'host 10.x.x.x and icmp' 4 
interfaces=[any]
filters=[host 10.x.x.x and icmp]

Labels
Top Kudoed Authors