Allwyn
0

Juniper CLI Modes and Hierarchies

The Juniper CLI architecture is indeed really nicely done. No wonder it is the primary method of managing and configuring the Juniper devices. If you are coming from a Cisco background which most of start with then this way of doing things is indeed new, but just spend a few hours and get a GNS3 lab going and it will grow on you in no time.

Here’s the architecture at a glance.

Juniper CLI architecture

Of course this is not what you see when you login into a new JunOS device.

What we see there is the different modes a user can get into and a hierarchical division in which the configuration can be performed.

The two modes are:

  1. The operator mode
  2. The configuration mode

Unix Shell

This is NOT really a mode and hence I want to get it out of the way quickly.

Since the Juniper kernel is based on FreeBSD, this is the root shell aka the c shell. On a new device, which only has the root user with no password, this is the prompt (shown by the %) the root user is dropped too.

Of course it’s never recommended t o use this account for anything but the initial setup.

login as: root
Using keyboard-interactive authentication.
— JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC

root@SRX1%

The Operator Mode

This mode provides only means to monitoring, troubleshooting and displaying the current status of the device with show commands.

On a new device the root user must use the “cli” command to jump to the operator mode from the c shell. And immediately create admin accounts for the future device configuration.

Any custom user accounts created fall straight to the operator mode prompt which is show my the ‘>’ prompt.

login as: admin
Using keyboard-interactive authentication.
Password:
— JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC
admin@SRX1>

The Configuration Mode

This is the mode where an admin would live and breathe. All configuration and changes to the system are done here. As show below, you must use the “configure” or the “edit” command to jump to this mode. Hence for some admins this is also the “edit mode”.

login as: admin
Using keyboard-interactive authentication.
Password:
— JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC
admin@SRX1> configure
Entering configuration mode

[edit]
admin@SRX1#

The edit command is also a amazing feature which sets JunOS CLI apart from other CLIs. It can be used as an “cd” command (as in windows cmd) to jump across and into the various configuration hierarchies. This really brings the CLI to life giving you a complete view of where and what is to be configured.

The above figure is a good reference here. Here are some config examples using the edit command and the same config without it.

Here we are setting the host-name for the SRX from the config mode using the set command.

admin@SRX1> configure
Entering configuration mode

admin@SRX1# set system host-name ?
Possible completions:
<host-name>          Hostname for this router

[edit]
admin@SRX1# set system host-name SRX2 #press enter to set the name to SRX2

We can do the same thing using edit to go under the system hierarchy

[edit] #this shows us our current level in the hierarchy which is global
admin@SRX1# edit system

#and here we are under the system hierarchy and only have access to those commands
[edit system]
admin@SRX1# set host-name SRX2

And when you do a show command here, it only shows you the config under that hierarchy which makes troubleshooting extremely smooth and easy!

[edit system]
admin@SRX1# show
host-name SRX1;
root-authentication {
encrypted-password “$1$mEHemrS1$PZOVox.e6.YpxXFLiWZmA.”; ## SECRET-DATA
}
login {
user admin {
uid 2000;
class super-user;
authentication {
encrypted-password “$1$G28me91/$HfoIQrKZBBAMJM3hFfBNE.”; ## SECRET-DATA
}
}
}
services {
ssh;
telnet;
web-management {
http {
interface ge-0/0/0.0;
}
https {
system-generated-certificate;
}
}

Similarly we can go into different levels of the hierarchy and configure just those parameters.

Let’s look at one more example with interfaces. This is using the set command in the global hierarchy.

[edit] #just edit means the global hierarchy
admin@SRX1# set interfaces ge-0/0/0 unit 0 family inet address 192.168.2.1/24

And the same thing can be done with the edit command. Then you do the show command and see the settings just under that interface.

admin@SRX1# edit interfaces ge-0/0/0

[edit interfaces ge-0/0/0] #the interfaces hierarchy
admin@SRX1# show
unit 0 {
family inet {
address 192.168.2.1/24;
}
}

Juniper provides a nice document for further reference on the CLI.

Allwyn
,
0

Why NO HTTPS on this blog?

I have always been a proponent of HTTPS everywhere, hence some friends in the industry have brought up why I have not used HTTPS yet to secure this blog.

Firstly the blog did have a secure connection when hosted on the .blogspot domain. Google offered it for free and automatically for all .blogspot hosted blogs. You just had to flick a switch in the settings!

Recently I bought this custom domain which is still hosted for free by google’s blogger service, and the situation is google does not allow an HTTPS connection setup on custom domains yet.

While I do see some tricks out there using cloudflare, I’m a little skeptical about the approach and afraid it might break something, especially with a comment like this.


Looks like an interesting experiment with Wireshark to me.

And in case you are wondering why a simple static blog with no login screen needs HTTPS like most people still think, you should give a read to Still think you don’t need HTTPS?.

He puts rest to myths of “TLS causing CPU overhead” to rest and shows you how HTTPS makes your site faster. And more over google loves HTTPS more than HTTP sites now.

So now that I am on a job hunt, I have some time to figure how to go HTTPS on this blog. Let’s get on it.

Allwyn
,
0

GNS3 Juniper SRX Lab And CLI Commands – Part 1

I have done a few projects with Juniper SRX firewalls. They are very different from Cisco, especially the CLI. But they are fun once you understand some basics.

I used the CBTNuggets JNCIA and JNCIS-SEC to further get a good grip on the Juniper family.

This is the GNS3 lab I used during my studies. The SRX is running inside of Oracle VirtualBOX which has direct integration with GNS3. You can follow this simple tutorial on setting it up. GNS3 and VirtualBOX are both free and you can get the SRX image by doing some googling for “juniper vsrx mega.nz”.

Some GNS3 quirks to keep in mind:

  • Remember to use increase the number of NICs and use the paravirtualized network setting for SRX NICs in GNS3.
  • At times everything looks great but the SRX won’t respond to pings, so you may have to just shutdown GNS3 and VB and restart(NOT THE PC!) the whole thing.
  • Similarly the interfaces don’t show up in the “show interfaces terse” command the first time you initialize them, so again you have to restart(AGAIN—NOT THE PC!) the whole thing.
  • To simulate external networks and servers(e.g. DMZ), you can simply use a Cisco IOS router in GNS3 and enable telnet, SSH, HTTP services which you can then hit through the SRX by creating the required firewall security policies.
  • You can simulate end users with windows PCs in VirtualBOX and use them for testing purposes.
  • To connect your own host to the SRX use the GNS3 cloud and add your current WI-FI/LAN adapter to the cloud and add additional IPs your NIC separate from your actual network subnet. This gives you web-mgmt and putty access then which much more comfortable than simply using the VirtualBOX console.
  • The SRX interfaces are names as ethernet 0,1 and so on, just right-click and rename them.

Don’t let this discourage you, just get it set up once and you are good to go. With that we can start with some config!

We begin the SRX base config which begins with the configuration of the security zones and interfaces. Let’s configure the trusted zone(aka inside network in Cisco speak).

Interfaces in JunOS are separated into physical and logical components. All the configuration parameters like the IP address are done on the logical interface by assigning an unit to the physical interface, most often unit 0 is used.

## statements are my comments, do not copy them!

INTERFACE and ZONES CONFIG

#to assign logical interface and IP address to an interface
admin@SRX1# set interfaces ge-0/0/1 unit 0 family inet address 192.168.3.1/24
admin@SRX1# commit # Juniper only applies new changes after the commit

The unit 0 can be replaced with . as below

#to assign logical interface and IP address to an interface
admin@SRX1# set interfaces ge-0/0/1.0 family inet address 192.168.3.1/24
admin@SRX1# commit #as stated, commit is must everytime!

The interface then must be assigned to a zone – trust and untrusted are the default zones. We assign ge-0/0/1 to the trust zone.

admin@SRX1# set security zones security-zone trust interfaces ge-0/0/1

To enable ping, SSH, HTTP and HTTPS on the interface we need to enable it on the physical interface and the logical interface. The physical interface settings take precedence over the logical interface settings.

admin@SRX1# set security zones security-zone trust interfaces ge-0/0/1 host-inbound-traffic system-services ping
admin@SRX1# set security zones security-zone trust interfaces ge-0/0/1.0 host-inbound-traffic system-services ping
admin@SRX1# commit

Similarly SSH, HTTP, HTTPS etc can be allowed on the interface.

To see the config on the ge-0/0/1 interface we can use the following show commands.

admin@SRX1# show interfaces ge-0/0/1
unit 0 {
family inet {
address 192.168.3.1/24;
}
}

#”run” is used to execute a operator mode command in the config mode
admin@SRX1# run show configuration interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.2.1/24;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.3.1/24;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 172.16.1.1/24;
}
}
}

[edit]
admin@SRX1# run show interfaces ge-0/0/1 brief
Physical interface: ge-0/0/1, Enabled, Physical link is Up
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Remote fault: Online
Device flags   : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags     : None

Logical interface ge-0/0/1.0
Flags: SNMP-Traps 0x4000 Encapsulation: ENET2
Security: Zone: trust
Allowed host-inbound traffic : http https ping ssh telnet
inet  192.168.3.1/24

Juniper needs some additional config for web-management along with allowing it on both the logical and physical interface.

admin@SRX1# set system services web-management http
admin@SRX1# set system services web-management https
admin@SRX1# set system services web-management https system-generated-certificate
admin@SRX1# commit

There’s not interface mentioned in the above commands, doesn’t mean they are activated on all interfaces but only on the ones already allow the protocols http, https etc. SSH is allowed by default by just allowing it on the logical and physical interface.

The system services allowed can be viewed as show here:

admin@SRX1# run show configuration | match “set system services” | display set
set system services ssh
set system services telnet
set system services web-management http interface ge-0/0/0.0
set system services web-management https system-generated-certificate
set system services dhcp pool 172.16.1.0/24 address-range low 172.16.1.50
set system services dhcp pool 172.16.1.0/24 address-range high 172.16.1.60
set system services dhcp pool 172.16.1.0/24 default-lease-time infinite
set system services dhcp pool 172.16.1.0/24 domain-name maslab.com
set system services dhcp pool 172.16.1.0/24 name-server 8.8.8.8
set system services dhcp pool 172.16.1.0/24 router 172.16.1.1

The Inside-R at 192.168.3.2/24 is a Cisco router which we can use to ping, ssh, telnet to the ge-0/0/1 interface to test our config. And goes without saying never enable telnet in an production environment!

GNS3 doesn’t have any other telnet and ssh client as of now, I can also test this using the “allwyn” PC (my host machine) and the WIN7 on VB at 192.168.3.50/24. Below is the output from Inside-R.

Inside-R#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.3.2     YES NVRAM  up                    up
FastEthernet0/1            unassigned      YES NVRAM  administratively down down
Serial1/0                  unassigned      YES NVRAM  administratively down down
Serial1/1                  unassigned      YES NVRAM  administratively down down
Serial1/2                  unassigned      YES NVRAM  administratively down down
Serial1/3                  unassigned      YES NVRAM  administratively down down

Inside-R#ping 192.168.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms

Inside-R#ssh -l admin 192.168.3.1

Password:
— JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC
admin@SRX1>

With this we confirm that the inside/trusted part is configured.

Now we can configure the outside/untrusted and DMZ interfaces similarly and create security policies.

SECURITY POLICY CONFIG

Once you get the ge-0/0/0 interface set up just as we did above and assign it to the untrust zone, we can start creating policies from the Trust-Zone to the Untrust-Zone.

Policies in SRX are created between zones. To view policies from trust to untrust zone.

admin@SRX1# run show security policies from-zone trust to-zone untrust
From zone: trust, To zone: untrust
Policy: default-permit, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 2
Source addresses: any
Destination addresses: any
Applications: any
Action: permit

This is the default policy which allows all traffic from trust to untrust zone. For this lab I will set this to deny-all and then create custom user defined policies to only allow required services like ping, ssh, http etc for our testing purposes and log it as well.

*this puts you in the security policy context
admin@SRX1# edit security policies from-zone trust to-zone untrust

#edit is a really helpful way to jump around the different heirarchies of the JunOS and really narrow down the length and scope of commands both for configuration and during troubleshooting.

[edit security policies from-zone trust to-zone untrust]
admin@SRX1# set policy IN-OUT match source-address any destination-address any application junos-ping application junos-http application junos-ssh
admin@SRX1# set policy IN-OUT then permit
admin@SRX1# set policy IN-OUT then log session-close session-init
admin@SRX1# commit

The policy is created, but we have to change the order of the policies. Policies work top-down. We must put our policy before the default policy.

[edit security policies from-zone trust to-zone untrust]
admin@SRX1#  top #brings to the top heirarchy in the OS
[edit]
admin@SRX1# insert security policies from-zone trust to-zone untrust policy IN-OUT before policy default-permit

And now viewing the policies again, we see our custom user defined IN-OUT policy is before the default with logging enabled and permits only a few chosen services.

[edit security policies from-zone trust to-zone untrust]
admin@SRX1# show
policy IN-OUT {
match {
source-address any;
destination-address any;
application [ junos-telnet junos-ping junos-http junos-ssh ];
}
then {
permit;
log {
session-init;
session-close;
}
count;
}
}
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
}
}

To test this policy I have put a Cisco IOS router on the outside/untrusted network at 192.168.2.2/24 with some services enabled. Here’s the cisco config if you need to replicate this.

And here’s our results for testing from from Inside-R router.

Inside-R#ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/21/28 ms

Inside-R#telnet 192.168.2.2
Trying 192.168.2.2 … Open

User Access Verification

Password:
Outside-R>who #shows our connected user
Line       User       Host(s)              Idle       Location
* 98 vty 0                idle                 00:00:00 192.168.3.2

Interface    User               Mode         Idle     Peer Address

Outside-R>ssh -l bob 192.168.2.2

Password:

Outside-R#who
Line       User       Host(s)              Idle       Location
98 vty 0                192.168.2.2          00:00:00 192.168.3.2
* 99 vty 1     bob        idle                 00:00:00 192.168.2.2

Interface    User               Mode         Idle     Peer Address

As we can see the incoming IP of 192.168.3.2 this shows that our connection is not NATed by the SRX yet and so the router on the outside needs to have a route to the inside network, in this case the SRX is the default gateway for it.

I will stop this part here and in another post we will see some more config on the SRX.

Allwyn
,
0

The Tale of A Spoofed EMAIL In A Poem

Humans have for long used myths, poems and such to express our deepest fears, feelings and awe with the world.

And along the same spirit, I found this poem below on stackexchange. This explains the deepest feelings of a lonely mail server.

The question is why is it so easy to SPAM emails. Me sending you one which looks like it’s from barack.obama@whitehouse.gov or from your bank or mom, or whoever.

I have a copy here below, but even I’d prefer you go read it where I found it.

Context: an e-mail server, alone in a bay, somewhere in Moscow. The server just sits there idly, with an expression of expectancy.

Server:
Ah, long are the days of my servitude,
That shall be spent in ever solitude,
‘Ere comes hailing from the outer rings
The swift bearer of external tidings.

A connection is opened.

Server:
An incoming client ! Perchance a mail
To my guardianship shall be entrusted
That I may convey as the fairest steed
And to the recipient bring the full tale.

220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)

Welcome to my realm, net wanderer,
Learn that I am a mighty mail server.
How will you in this day be addressed
Shall the need rise, for your name to be guessed ?

Client:
HELO whitehouse.gov

Hail to thee, keeper of the networking,
Know that I am spawned from the pale building.

Server:
250 mailserver.kremlin.ru

The incoming IP address resolves through the DNS to “nastyhackerz.cn”.

Noble envoy, I am yours to command,
Even though your voice comes from the hot plains
Of the land beyond the Asian mountains,
I will comply to your flimsiest demand.

Client:
MAIL FROM: barack.obama@whitehouse.gov
RCPT TO: vladimir.putin@kremlin.ru
Subject: biggest bomb

I challenge you to a contest of the biggest nuclear missile,
you pathetic dummy ! First Oussama, then the Commies !
.

Here is my message, for you to send,
And faithfully transmit on the ether;
Mind the addresses, and name of sender
That shall be displayed at the other end.

Server:
250 Ok

So it was written, so it shall be done.
The message is sent, and to Russia gone.

The server sends the email as is, adding only a “Received:” header to mark the name which the client gave in its first command. Then Third World War begins. The End.

Commentary: there’s no security whatsoever in email. All the sender and receiver names are indicative and there is no reliable way to detect spoofing (otherwise there would me much fewer spams).

Allwyn
0

Printers, NAS and other devices on different LANs on the same Fortigate

I started this thread on the network engineering Q&A site.

I have now found the answer to it as well. It’s a weird situation.

I had opened a ticket with Fortinet’s TAC for the printer query which I have posted and he just enabled NAT on the WI-FI interface on which the printer is connected and the issue was resolved.

After this with another client of mine, I faced the same situation this time with an NAS storage device. And voila I had to enable NAT on the interface to which the NAS box was connected to.

For some reason any such device like printers, NAS etc. don’t seem to respond to communication from another subnet on the same fortigate and NAT solves the problem.

The same setup works fine if it was a PC in place of the printer.

UPDATE – 5th Feb 2016

One of those light bulb moments! The printers and NAS devices probably were NOT configured with a default gateway and so they never had a default route to send packets to with a destination IP address other than a directly connected one. They never had a route for any other network other than the one they were directly plugged into!

Hence when NAT was enabled, the printers could reply to the fortigate’s interface IP which would NAT the source IP of the other subnet.

The PCs on the other hand configured with a little more caution had the default gateway and hence would send all packets with unknown IP address to their default gateway.

Allwyn
,
0

Blocking HTTPs websites without SSL inspection on Fortigate

One of my clients wanted to block facebook but without using SSL inspection as he didn’t want to install the cert to 100s of his staff computers.
I explained that with that there would be no other way to get it done. This coming from all of Fortinet’s own documentation obviously. 
Then to convince the client I opened a fortinet ticket and got the same response that this can’t be done without the ssl inspection and certificate installation.
Now this guy hired some other service provider and those guys simply blocked social media signatures in app control and applied it to the policy and IT HAS WORKED.
It doesn’t say “fortiguard blocked” but just keeps the loading icon spinning and facebook doesn’t load at all.
The whole situation turned pretty embarrassing for us.

 

The Confusion

 

Fortinet must spend some time on cleaning up its archives of posts and videos with outdated info i guess.

 

Here in this and this video its displayed how https is blocked seamlessly by just using the SSL inspection inspect all ports method without any importing any certificate. And nothing about SSL certificate warnings is touched upon which almost always pops up when using HTTPs inspection. The Fortinet TAC’s response was also appeared what I can call very non-committal, TAC simply told “you must install the certificate if you get any errors”, really now I doubt there’s ever a situation when you don’t get cert errors which ssl inspection on. 
Allwyn
,
1

Automatic backup fortigate firewalls with batch file

Firewall configuration backups can save hours of reconfiguration when one of your firewalls goes nuked due to any reason whatsoever.

While fortigates have a backup button, that gets boring and repetitive soon when you reach 10 fortigates to backup daily.

I put up this following backup utility using windows batch programming and of course credit goes to all those blogs and posts I referred. This uses secure copy which must be enabled on the device.

Here is the batch code along with the .txt file you can download. Once you download the .txt just rename it to .bat for it to work.

@echo off
for /f ” eol=# tokens=1-4 delims=,”  %%i in (fgts.txt) do CALL :oneaddr %%i %%j %%k %%l
echo end
goto :EOF
:oneaddr
cd c:Program FilesPuTTY
pscp -pw %3 %2@%1:sys_config C:backup%4-%DATE%-%TIME::=%.conf

Download The Bat File

What I have highlighted in red is another .txt file which is to be fed as input to the .bat code above and both should be in the same directory.

The folder where the config files will be downloaded should already exist. And the file will be downloaded with the .conf extension there.

Also highlighted is the location where your putty is installed should match with the one in the batch file (and yes putty can be installed).

What this input file contains is the IP address, admin name, admin password and device name.
The format must be: (Keep adding more on each line.)

 x.x.x.x,username,password,devicename
y.y.y.y,username2,password2,devicename2
z.z.z.z,username3,password3,devicename3

The interface of the IP you’re providing should have SSH enabled.

Once you have everything ready just put both the bat and input txt file in a folder.

Now the last thing you need is to enable admin-scp on your foritgate device. The CLI way to do it is:

config system global
    set admin-scp enable
end

And now you just have to doubleclick the .bat file and you will see all your fortigates being backed up one by one with a name-date-time stamp.

I can hear your worries about storing passwords to firewalls in txt. You can minimize the risk by configuring read_only admin accounts on the firewalls or else just take of the that input .txt file.
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