How can I tell if my fortigate is blocking outbound traffic?

I need to know whether my fortigate 60d is blocking outbund traffic from an internal IP.  Wireshark shows that traffic is hitting the firewall from the internal IP.

How do I accomplish this using fortigate gui or cli?
tike55Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Garry GlendownConsulting and Network/Security SpecialistCommented:
Simplest way: get on the CLI, do something like this:

diag snif pack any "host <TARGETIP>" 4

Replace "<TARGETIP>" with the ip of the destination you are trying to reach. If the packets show up on both the internal and external interface (presumably with the internal IP addresses changed to some NAT IP), that part should be fine. If you only see the packets arrice at the firewall, but not get forwarded to the outside, you might need some flow debugging (which is a couple more commands). Let us know how it goes ...
0
Prabhin MPEngineer-TechOPSCommented:
hi,
If you are trying to access a website,
do a telnet to the particular hostname.
If telnet works  it doesn't block the outgoing traffic,


if website not opening in the browser even though the telnet results is positive. Check web filter policy.
0
Ashok DewanFreelancerCommented:
You can use Nmap tool on internal PC. Just do TCP connect scan on port 80 to any outside web server on internet of your choice. If three way handshake completed then firewall is not blocking any traffic for port 80. if not completed then best way to check Fortigate logs.
Analyze whole traffic with Wireshark you will get know from replied packets.
0
Simple Misconfiguration =Network Vulnerability

In this technical webinar, AlgoSec will present several examples of common misconfigurations; including a basic device change, business application connectivity changes, and data center migrations. Learn best practices to protect your business from attack.

masnrockCommented:
Garry's answer would be the most feasible. Nmap would not answer that. You might know a connection isn't getting made, but not whether the firewall itself is blocking it. Traceroute might help, but that would very optimistically assume that all routers in between would answer to ICMP traffic.
0
tike55Author Commented:
Hi Gary,

what is the 4 at the end of your command line?
0
masnrockCommented:
4 means verbose
0
Garry GlendownConsulting and Network/Security SpecialistCommented:
the last parameter tells the FG what sort of output you want.

1: print header of packets
2: print header and data from IP of packets
3: print header and data from Ethernet of packets
4: print header of packets with interface name
5: print header and data from IP of packets with interface name
6: print header and data from Ethernet of packets with interface name

4 will ensure you see packets both as they come in one interface and go out another (allowing you to see whether they are actually forwarded), with "5" you can also get the contents of the packets. Those two options are the ones used most often (I reckon)
0
tike55Author Commented:
When I tried Gary's solution the CLI shows:

interfaces=[any]
filters=[host <my ip>]

and nothing else
0
Garry GlendownConsulting and Network/Security SpecialistCommented:
Hm ... which IP did you use, the remote host? If nothing shows up, are you sure you are using the right gateway IP?

Alternatively, try "port 80" instead to see all HTTP traffic
0
tike55Author Commented:
thanks,

the traffic showed up a few minutes later.  What would indicate if the traffic was blocked?

Also in the forticloud (web gui) traffic logs, if shows inbound traffic, but no outbound.  Is there any place in that log where I can see outbound as well?
0
Garry GlendownConsulting and Network/Security SpecialistCommented:
What traffic is in the sniffer output?
0
tike55Author Commented:
I think TCP traffic.  How would I be able to tell?
I am specifically wondering whether the FW is blocking UDP traffic
0
tike55Author Commented:
Sip provider says the PBX is sending out traffic.  However, I do not see traffic from the SIP card's internal IP in the wire shark, forti logs.  
He says UDP traffic is not passing thru back to his servers.   He also suggests it could be our Cisco 2950 switch, but I see no reason why it would be configd that way.

Any suggestions how to verify or debunk his theory?
0
tike55Author Commented:
the cisco 2950 is between the pbx and firewall.  

Also worth noting, the issue is not a physical connection.  I can ping the PBX just fine.
0
tike55Author Commented:
Any ideas?
0
Garry GlendownConsulting and Network/Security SpecialistCommented:
You never mentioned before that you had problems with VoIP ...
FG has an ALG-Helper for SIP, which typically (in our experience) messes up connections in many (all?) situations. Disable it and try again ...

https://www.3cx.com/community/threads/fortigate-sip-alg-disable-steps-5-2-firmware-and-above.47694/
0
tike55Author Commented:
Hi Gary,

ALG helper is turned off.  On another note, Is the packet sniffing command you gave earlier (diag snif pack any "host <TARGETIP>" 4) equivalent to a tcp dump?
0
tike55Author Commented:
HI Gary,

Is diag snif pack any "host <TARGETIP>" 4 supposed to capture UDP traffic as well?  

All I see in the file is ICMP requests
0
Garry GlendownConsulting and Network/Security SpecialistCommented:
In essence, yes ...
0
Garry GlendownConsulting and Network/Security SpecialistCommented:
Yes, the part between the "" is similar to tcpdump/pcap syntax, so with using just the IP address, you will get all the traffic from or to that IP, no matter what IP protocol type. You could limit it to udp by adding "and UDP" to the expression.

If you are doing any VoIP, you should start out by seeing some TCP 5060 traffic for the SIP protocol before you get the UDP packets ...
0
tike55Author Commented:
I don't see port numbers or traffic type in the output.  Only ICMP.  How would I add "UDP" as well as port to the expression?
0
Garry GlendownConsulting and Network/Security SpecialistCommented:
If there is and UDP traffic, it should show up in the sniffer output and look something like this:

2.729081 wan1 in 185.35.62.96.60477 -> 195.158.42.xx.161: udp 37
3.263541 wan1 in 212.218.64.xx.500 -> 212.218.10.229.500: udp 108
3.265283 wan1 out 212.218.10.229.500 -> 212.218.64.xx.500: udp 108
3.901653 internal in 2001:4cd8:2::xxxx.51173 -> 2a00:1450:4001:818::2003.443: udp 1076 [flowlabel 0x5c09]
3.901773 wan1 out 2001:4cd8:2::xxxx.51173 -> 2a00:1450:4001:818::2003.443: udp 1076 [flowlabel 0x5c09]
3.925982 wan1 in 2a00:1450:4001:818::2003.443 -> 2001:4cd8:2::xxxx.51173: udp 79
3.926053 internal out 2a00:1450:4001:818::2003.443 -> 2001:4cd8:2::xxxx.51173: udp 79
3.926095 wan1 in 2a00:1450:4001:818::2003.443 -> 2001:4cd8:2::xxxx.51173: udp 351
3.926133 internal out 2a00:1450:4001:818::2003.443 -> 2001:4cd8:2::xxxx.51173: udp 351

Open in new window


You can use something like "udp and port XXX" to filter for that ...
0
tike55Author Commented:
Just to clarify...   To see UDP traffic, do I have to enter anything else in the CLI besides- diag snif pack any "host <SIP PROVIDER's IP>" 4?

When I entered the diag snif pack any "host <SIP PROVIDER's IP>" 4, nothing UDP showed up in the output.  Only ICMP.  Does this mean that UDP traffic is being blocked?
0
Garry GlendownConsulting and Network/Security SpecialistCommented:
No, you do not need anything else than the aforementioned input. The expression is the filter that limits the amount of information that is displayed.

And no, it does not mean it's being blocked, as even if it were blocked, you'd see the packet entering the firewall, but after that not exiting it.

Depending on the firewall model you have there is one other possibility ... there is already a session open from the endpoint, and the firewall has put the forwarding of packets off to the hardware, thereby bypassing the software layer you are using to inspect the traffic. Check your active session list for anything that matches the traffic to the provider IP, then clear those in the web interface ... when you do, and the endpoint again tries to contact the remote server, you should see traffic ... if not, do ensure you have the right gateway in your endpoint ...
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
tike55Author Commented:
On a separate note.  I just found in a wireshark several lines from the SIP card (internal) to the external SIP providers IP:

source             destination    protocol  length  info
<internal ip> <external ip>   UDP          214       10064->25372 Len=172

Does this mean the firewall attempted to transmit UDP packets to the destination IP?  No Block?
0
Garry GlendownConsulting and Network/Security SpecialistCommented:
The PCAP is from the server? If so, then it doesn't say anything about whether it went to the firewall correctly, or was forwarded ...
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.