Allwyn
,
0

Checking to confirm fortigate port forwarding by debugging

fortigate destination NAT debug CLI

A few days back one of my clients had doubts whether the port he required was forwarded correctly on the FGT.

I assured him it was and asked him to check with his IT teams whether the port was accepting traffic on the server locally, I guess many people get confused that for port forwarding to work correctly the port in question should also be open on the server or the application. These people were using Tomcat7.

Since his other IT team wasn’t convinced I decided to just send him a log of the debug from FGT.

After little quick googling I got to this post on the fortinet forum and found the debug code below on that very post.

Here’s the debug command to check this.

diag debug enable
diag debug flow filter dport 80(the destination port which you have configured in VIP)
diag debug flow filter saddr
diag debug flow  show console enable
diag debug flow trace start 100(this I guess is the number of packets or hits..will have to look this up)

<Your public IP address> I say public because when you would be sending traffic to this FGT to generate the debug logs, your incoming traffic will have the source IP of your wan which is aka your public IP. I’m sure someone out there is getting no logs at all because he’s gone all ipconfig and added his 192.168… in there which is the internal LAN network IP aka your private address.

To clear the debug filters use
diag debug reset
diad debug disable
diag debug flow filter clear
You should clear the filters every time before running the debug again.

Once your debug commands are in, just go through your browser and access the FGT’s IP as
http://x.x.x.x:yy where yy is the forwarded port, for eg: 8080, 8888, 3389 and so on. I was working with the simple port 80 so all i needed to do was http://x.x.x.x as http uses port 80.

The debug generated is as follows:

BSH # id=36871 trace_id=525 msg=”vd-root received a packet(proto=6, z.z.z.z:52957->x.x.x.x:80) from wan2.”
id=36871 trace_id=525 msg=”allocate a new session-0036f1c2″
id=36871 trace_id=525 msg=”find SNAT: IP-172.168.1.2(from IPPOOL), port-80″
id=36871 trace_id=525 msg=”VIP-172.168.1.2:80, outdev-wan2″
id=36871 trace_id=525 msg=”DNAT x.x.x.x:80->172.168.1.2:80″
id=36871 trace_id=525 msg=”find a route: gw-172.168.1.2 via internal”
id=36871 trace_id=525 msg=”Allowed by Policy-2:” 

Again x.x.x.x is the target FGT’s public IP and z.z.z.z is my public IP from where I sent the traffic to generate the logs.

I swear this is the easiest to understand debug output ever. Everything is just right there.
Allwyn
0

Unblocking Google earth on Fortigate and probably other firewalls

google earth fortigate

Google earth servers keep changing and you could be connecting to anyone which serves you the best.

 

At a client’s google earth would work fine but the street view would feature which should be as clear as standing on the road in some city would look all scrambled and jumbled up.

 

Their support forum here has a list of URLs to be allowed:
and some IPs:

74.125.227.1
74.125.227.3
74.125.227.7
74.125.227.17
67.215.65.132  
74.125.79.120 

Instead of allowing each of them, you just have to check their Fortiguard rating and confirm which webfilter category they fall into. Most them are in the following.
Reference
Search engines
Content servers

I was stuck with the last one—content server. None of the URLs above actually fall into it and the street view was still jumbled up.

Then I decided to get the big guns out—Fortinet Debugger. I could sense the errors already shaking in their boots.
diag debug enable
diagnose debug urlfilter src-addr <Your LAN PC IP here>
diag debug flow show console enable
diag debug flow trace start 100 (the no. of lines you want to be traced)

 

then stop and reset the debugging:
diag debug reset
diag debug disable

You will see the destination URL in the log and then again check the Fortiguard category or just allow the URL.

Allwyn
,
0

Blocking facebook, youtube over HTTPS on Fortigate

A few months back I was in hell over blocking Youtube for one of my clients.

I blocked it on webfilter  with certificate SSL inspection turned on and later even applied application control to it, in the end — the page opened straight away like nothing exists in between.

Later the good old fortinet TAC put me out of misery and showed my how YouTube slid past by the SSL certificate inspection as knife through butter because some of google’s websites now use a very different form of SSL — QUIC.

Look in the lock icon to the left of your address bar to see this:

Says right there the connection uses QUIC.

Fortinet has a nice little doc here on how to block it.

I’d just recommend you make this a part of your base configuration and always disable QUIC. This interferes with not only for webfilter and app control but say you want to do some email filtering, blocking gmail attachments or even stop google drive the traffic will just slip by with QUIC enabled.

1 2 3