Certificate based SSL VPN configuration

September 11, 2015, 3:34 am

≫ Next: Access the Public Server IP from the inside network

≪ Previous: Traffic Marked under Location, Lync not working and Traffic Forwarding Requirements

$

0

0

Generating a CSR Certificate in FortiOS

1.      From System > Certificates > Local Certificates, click the “Generate” button to get the following screen:

2.      Click “OK”. This will take you back to the “Local Certificates” landing page where you can see your request.

3.      Select the new CSR certificate, you can now see that there is a “Download” link available for the CSR you just generated. Click the download link and save the file to your file system.

4.      Send this file either to your local certificate administrator or your third-party certificate authority for processing.

Sign a Certificate with Microsoft CA

Although you can create a self-signed certificate with Firebox System Manager or other tools, you can also create a certificate with the Microsoft Certificate Authority (CA).

For authentication, each certificate signing request (CSR) must be signed by a certificate authority (CA) before it can be used. When you create a certificate with this procedure, you act as the CA and digitally sign your own CSR. For compatibility reasons, however, we recommend that you instead send your CSR to a widely known CA. The root certificates for these organizations are installed by default with most major Internet browsers and XTM devices, so you do not have to distribute the root certificates yourself.

For HTTPS Proxy or SMTP Proxy content inspection, we recommend you use your internal CA to sign the request because you must create a CA certificate that can re-sign other certificates. If you create a CSR with Firebox System Manager and have it signed by a prominent CA, it cannot be used as a CA certificate.

You can use most Windows Server operating systems to complete a CSR and create a certificate.

Send the Certificate Request

1. In your web browser address bar, type the IP address of the server where the Certification Authority is installed, followed by certsrv.
   For example: http://10.0.2.80/certsrv

2. Click the Request a Certificate link.

3. Click the Advanced certificate request link.

4. Click Submit a certificate.

5. Paste the contents of your CSR file into the Saved Request text box.

6. From the Certificate Template drop-down list, select Subordinate Certification Authority.

7. Click Submit.

Issue the Certificate

1. Connect to the server where the Certification Authority is installed, if necessary.

2. Select Start > Control Panel > Administrative Tools > Certification Authority.

3. In the Certification Authority (Local) tree, select Your Domain Name > Pending Requests.

4. Select the CSR in the right navigation pane.

5. In the Action menu, select All Tasks > Issue.

6. Close the Certification Authority window.

Download the Certificate

1. In your web browser address bar, type the IP address of the server where the Certification Authority is installed, followed by certsrv.

2. Click the View the status of a pending certificate request link.

3. Select the certificate request with the time and date you submitted.

4. To choose the PKCS10 or PKCS7 format, select Base 64 encoded.

5. Click Download CA certificate to save the certificate.

Certification Authority is distributed with Windows Server as a component. If Certification Authority is not installed in the Administrative Tools folder on your server, follow the instructions from the manufacturer to install it.

Importing the Extracted Certificate into the Certificate Store Even though the CA/SSL certificate has been imported into FortiOS, HTTPS proxy/inspection will cease to function if the CA certificate is not installed in the certificate store of the client end point. I will now detail the import of the CA certificate into the Microsoft CAPI, the Mac OS X Keychain and the Java key store.

Importing the Extracted Certificate and Private Key into FortiOS

·         Login to your FortiGate/FortiOS admin interface and go to System > Certificates > Local Certificates.

·         Click on the Pending certificate

·         Click the “Import” link and choose the file from the Local .

·         You should get the following message after clicking “OK” in the preceding step: Upload Certificate successfully. Return

·         Login Via CLI

config firewall ssl setting

set caname <CAname>

end

Exporting a Certificate from FortiOS

In the event that you need to export a certificate from FortiOS, there are two methods you can use to accomplish this.

GUI Export:

1. Login to FortiOS and go to System > Certificates > Local Certificates.

2. Select the certificate that you would like to export and click the “Download” link at the top of the page.

3. Save the certificate in a location of your choice.

CLI Export:

1.      In the FortiOS command line interface, type the following command:

fnsysctl cat /etc/cert/local/Fortinet_CA_SSLProxy.cer

This command will list the certificate content in the console window similar to the following example:

-----BEGIN CERTIFICATE----- MIID1zCCAr+gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBpTELMAkGA1UEBhMCVVMxzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTERMA8GA1UEhMIRm9ydGluZXQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEVMBMG1UEAxMMRm9ydGlHYXRlIENBMSMwIQYJKoZIhvcNAQkBFhRzdXBwb3J0QGZvcnRp

-----END CERTIFICATE-----

2. Select and copy the certificate content including “-----BEGIN CERTIFICATE-----“ and “-- ---END CERTIFICATE-----“.

3. Open a text editor and paste the certificate content.

4. Save the file as CA.cer.

Microsoft CAPI Certificate Import: The CA certificate will need to be copied to the client end point file system.

·         Right-click the CA certificate and select “Install Certificate”.

·         When the “Certificate Install Wizard” window appears, click “Next” to begin the import.

·         At the “Certificate Store” window, select the option, “Place all certificates in the following store” and click the “Browse” button

·         In the “Select Certificate Store” window, select the option for “Show physical stores” then scroll up to “Trusted Root Certification Authorities” and select the sub-directory named, “Local Computer”.

·         Click “OK” and then click “Next”. Once you click “Finish” on the final window, you will have successfully imported the CA certificate into the client end point certificate store.

Setup Certificate Authentication for SSL VPN

 1. Open a browser and go to your FortiGate administration page.

2. Go to System > Certificates > CA Certificates.

3. Import your CA certificate using the steps found in, “Importing the Extracted Certificate and Private Key into FortiOS”.

4. Once the CA certificate has been successfully imported, go to the FortiGate CLI and enter the following commands:

config user peer

edit -- This is an arbitrary value of your choice.

set ca -- This is the CA certificate that you imported in step 3.

set two-factor enable

set password <pass>-- This is an arbitrary value of your choice.

Note: Use the following commands if they apply to your scenario:

set cn -- This is the common name of the peer certificate. Use only if you wish to specify a single user certificate.

set ldap server -- This is a LDAP server that you have setup under Users > Remote > LDAP – config user ldap.

set ldap-username -- This is an administrator account for your LDAP.

You must use the full DN for this account (eg. cn=administrator, cn=users,dc=fnet,dc=local) set ldap-password -- This is the password for the administrator account specified in the preceding command (set ldap-username).

 set subject -- If not set, this will allow any peer certificate subject. If you wish to isolate to just one user, enter any of the peer certificate name constraints.

5. Now you will create a user group for SSL VPN access:

6. Configure your SSL VPN Policy:

config vpn ssl settings

set sslvpn-enable enable

set dns-server1

set reqclientcert enable

set force-two-factor-auth enable

set servercert

set tunnel-ip-pools

end

7.      Configure your firewall rules:

8.      Open a browser and go to https://:10443/remote/login to test client certificate authentication. If all settings have been configured correctly, the end user should be prompted for his/her certificate and, upon confirmation of said certificate, will then have full access to the profile assigned to his/her group. If the user gets a certificate prompt and a subsequent username and password field page, there is a problem with either the certificate chain or the validation of the user.

9.      To troubleshoot issues related to certificate authentication, use the following commands:

diagnose debug app fnbamd 7

diagnose debug enable

Note:

To establish a successful SSL VPN using certificate, below points are mandatory.

a.      On Fortigate –

1.      A certified CSR certificate  - To be installed on local

2.      CA certificate from the server.  – To be installed under CA certificate

b.      On client PC

1.      A client Certificate issued by CA server

2.      CA certificated download from – Fortigate Local server

---

Access the Public Server IP from the inside network

September 11, 2015, 6:16 am

≫ Next: Image and Video upload failed in facebook

≪ Previous: Certificate based SSL VPN configuration

$

0

0

When a public IP is used to gain access to a server in a private, internal network, the traffic will attempt to go out to the internet. In order to reach the server, the traffic will need to be redirected to the correct location. A useful technique for accessing an internal server using a public IP is NAT hairpinning.

Example:

In this example, 10.0.0.5 is the real IP, 155.100.1.1 is the public IP and the inside user trying to access from the server 155.100.1.1 from 10.0.0.15.

If the Destination NAT is used in this scenario:

• The client sends a request to 155.100.1.1.
• The SRX will use a Destination NAT rule to point it back into the network.
• The server will reply directly to 10.0.0.15.
• The client will drop the packet because it does not realize that 10.0.0.5 is the same server as 155.100.1.1.

NAT hairpinning is a useful technique for accessing an internal server using a public IP.

In order to ensure that the flow occurs properly: 

·         Both the source and destination IP addresses need to be modified so each device sees the traffic flowing to and from the correct locations. This allows the return traffic to return through the SRX, and the client to receive the packets from the correct IP.

·         Make sure a security policy is configured which will allow intrazone communication in the default zone.

Configuration Example

set security nat source rule-set hairpin from zone default
set security nat source rule-set hairpin to zone default
set security nat source rule-set hairpin rule hairpin-source match source-address 10.0.0.0/24
set security nat source rule-set hairpin rule hairpin-source then source-nat interface

set security nat destination pool server address 10.0.0.5/32
set security nat destination rule-set hairpin from zone default
set security nat destination rule-set hairpin rule hairpin-destination match destination-address 155.100.1.1/32
set security nat destination rule-set hairpin rule hairpin-destination then destination-nat pool server

set security policies from-zone default to-zone default policy INTRA-default match source-address any
set security policies from-zone default to-zone default policy INTRA-default match destination-address any
set security policies from-zone default to-zone default policy INTRA-default match application any
set security policies from-zone default to-zone default policy INTRA-default then permit

Image and Video upload failed in facebook

September 16, 2015, 9:14 am

≫ Next: VPN in multi context - Allocate / Limit VPN resources to context

≪ Previous: Access the Public Server IP from the inside network

$

0

0

Image and Video upload failed in Facebook

We faced a strange behavior with Facebook when accessing via zscaler. We are able to view the  contents properly and post the text, but failed to upload images or videos.

We captured a wireshark packet and don’t find any RST or block. Finally we tried with HTTP trace and found some URLs are needs to authentication bypass.

We added below URLs authentication & SSL bypass.

vupload-edge.facebook.com

p-upload.facebook.com

And the same started working. Again after few months, we faced the same issue and found below URLs are failing. Post added those URLs, facebook upload started working.

Below are the URL's that to be in that authentication bypass list.

upload.facebook.com

vupload2.facebook.com

After we were added above URLs in authentication bypass and found still not able to upload images/videos. We were are used Cloud App to block Facebook along with User/Group based policies. When we add URLs in Auth Bypass Location policy will be applied. 

We did a Header trace and found that fbstatic-akamaihd sites send CORS(Cross Origins Resource Sharing) for "JavaScripts(js)" and CSS(Content Style Sheets). When Zscaler Sees a CORS header, it does Auth Bypass for the URL. Again location policy is applied since the URL is globally auth bypassed by Zscaler.

There was a Policy in Cloud App that was for Facebook to block for any user/location. We disabled the rule, it was working fine

VPN in multi context - Allocate / Limit VPN resources to context

September 21, 2015, 9:26 am

≫ Next: How to disconnect Management CLI sessions

≪ Previous: Image and Video upload failed in facebook

$

0

0

ASA Software Version 9.0 and later introduced Site-To-Site VPN configuration in multiple context mode. When you attempt to bring up multiple Site-To-Site VPN tunnels on the ASA, it fails and generates the syslog message "The maximum tunnel count allowed has been reached".

The specific syslog message is below:

%ASA-4-751019: Local:<LocalAddr> Remote:<RemoteAddr> Username:<username> Failed to obtain a <licenseType> license.

The log indicates that a session creation failed because the maximum license limit for VPN tunnels was exceeded which causes a failure to either initiate or respond to a tunnel request. The implementation of VPN in multiple-mode requires the division of the total available VPN licenses among the configured contexts. The ASA administrator can configure how many licenses each context is allocated.

By default, no VPN tunnel licenses are allocated to the contexts, and the allocation of the license type must be done manually by the administrator.

Dividing the licenses among the contexts is done by the augmentation of the resource manager with a 'VPN other' resource that manages the division of the 'Other VPN' license pool used for site-to-site VPN among the configured contexts. The limit-resource CLI below allows this configuration within the resource 'class' mode.

Limit-resource vpn [burst] other <value> | <value>%

Where, <value> range: 1- Platform license limit or 1-100% of installed licenses.

For bursts, the range is 1 to unassigned licenses or 1-100% of unassigned licenses.
Default: 0; no VPN resources are allocated to a class.

In order to assign a context to 10% of the installed licenses, you need to define a resource class. Next, apply the class to contexts that you need to be able to get this resource within the system context configuration.

ciscoasa(config)# class vpn

ciscoasa(config-class)# limit-resource vpn other 10%

In order to assign a context of 250 VPN Peers of the installed licenses, you need to define a resource 'class'. Next, apply the class to the contexts that you prefer to be able to get this resource within the system context configuration.

ciscoasa(config)# class vpn

ciscoasa(config-class)# limit-resource vpn other 250

In order to apply the above class "vpn" to a context called "administrator", follow these steps:

1. Change/Switchover to the system context and apply the class VPN for the context "administrator". This could be done only within the System context.
2. Below is the configuration snippet to allocate the class "vpn" to the context "administrator".
   
   

ciscoasa(config)# context administrator

ciscoasa(config-ctx)# member vpn

How to disconnect Management CLI sessions

September 22, 2015, 7:43 am

≫ Next: NAT order in ASA 8.2

≪ Previous: VPN in multi context - Allocate / Limit VPN resources to context

$

0

0

How to disconnect Management CLI sessions

More than 32 TTY simultaneous sessions are opened to a router running a JUNOS version prior to 8.2. As a result all the sessions beyond the 32^nd simultaneous session the TTY session ID will start with q . The CLI command request system logout terminal X  does not work for the TTY sessions whose ID begin with a qor an r  , and the session is not terminated.

operator@router> show system users no-resolve

11:24AM  up 10 mins, 40 users, load averages: 0.11, 0.10, 0.06

USER     TTY      FROM                              LOGIN@  IDLE WHAT

operator  p0       172.26.24.43                     11:20AM     - -cli (cli)

operator  p1       172.26.24.43                     11:22AM     2 -cli (cli)

[...]

operator  pv       172.26.24.43                     11:24AM     - -cli (cli)

operator  q0       172.26.24.43                     11:24AM     - -cli (cli)

operator  q1       172.26.24.43                     11:24AM     - -cli (cli)

operator@router> request system logout terminal q0

Use the PID of a certain TTY session to disconnect it, as shown in the example below:

·         Check which PID the TTY session q0 has: 

operator@router> show system processes |match q0
3603  ??  Is     0:00.01 mgd: (mgd) (operator)/dev/ttyq0 (mgd) 

·         Then specify the PID of q0 in the CLI command request system logout terminal: 

operator@router> request system logout terminal q0 pid 3603 

·         Verify, that the TTY session has been closed:

operator@router> show system users no-resolve | match q0

operator@router>

NAT order in ASA 8.2

September 30, 2015, 12:47 am

≫ Next: HTTP GET & POST Requests

≪ Previous: How to disconnect Management CLI sessions

$

0

0

NAT order in ASA 8.2

NAT is commonly used to translate private IP addresses (RFC 1918) to public IP addresses and therefore allow communication on the public Internet

NAT Types

·         Dynamic NAT

·         PAT

·         Static NAT

·         Static PAT

·          

The ASA requires a NAT matching rule to allow communication between interfaces of different security levels. To avoid this requirement, you can disable NAT Control. NAT in transparent mode has some limitations. Policy NAT allows to specify the source and destination address and ports to NAT (regular NAT allows only to specify the source address)

Order of NAT commands when checked by the ASA

·         NAT exemption (nat 0 access-list)

·         Static NAT and Static PAT (static)

·         Policy dynamic NAT (nat access-list)

·         Regular dynamic NAT (nat)

DNS responses can be translated by the use of the dns keywork on the NAT rule

If NAT Control is enabled but you want to bypass NAT, there are three ways to do this

·         Identity NAT (nat 0)

·         Static Identity NAT (static)

·         NAT exemption (nat 0 access-list)

Multiple NAT IDs can be used to link NAT statements to its corresponding GLOBAL statements

Dynamic NAT

Used to translate a range of private IPs to a range of public IPs (the range of public IPs could be fewer). The translation only takes place when the real inside host initiates the connection

·sh xlate command is used to check the translation table

For the duration of the translation timeout xlate, a remote host can initiate a connection to the inside host (if an ACL allows it)

Dynamic PAT

Used to translate a range of private IPs to a single public IP

PAT lets you conserve addresses, since it shares the same public IP by distinguishing the translations using unique port numbers

Disadvantages of PAT

·         Protocols that do not have Layer 4 information to translate such as ESP, GRE version 0

·         Multimedia applications that have a data stream on one port, the control path on another port, and are not open standard

NAT and PAT can be used together (for example when the number of inside hosts exceed the number of public IPs available)

For outside NAT, the outside keyword is required (outside NAT is referred when the interface with a globalstatement resides on a higher security interface)

The clear xlate command is used to clear the translation table and necessary when changing NAT statements, but keep in mind that it also disconnects all current connections that use translations

Static NAT

·         Used to specify a one-to-one translation

·         Only dynamic translations can be removed from the translations table, therefore cannot use the clear xlatecommand, must remove the static command and to remove the connections use the clear local-host command

·         To allow communication between overlapping networks is very common to use the static commands, ie.

Inside network 192.168.100.0.24, DMZ network 192.168.100.0/24

static (inside,dmz) 10.1.2.0 192.168.100.0 netmask 255.255.255.0

static (dmz,inside) 10.1.3.0 192.168.100.0 netmask 255.255.255.0

The communication will flow between 10.1.2.0/24 and 10.1.3.0/24 solving the overlapping issue

Static PAT

·         Sometimes known as Port Redirection allows to statically translate different port numbers to the same mapped IP address

·         Very useful to translate a well-known port to a non-standard port, i.e hosting a web server that listens on port 8081

static (inside,outside) tcp 209.165.201.3 80 192.168.100.3 8081

There are some advanced features that can be invoked with NAT, for example:

Some NAT statements consider the inactive and time-range keywords on the ACEs

·         The norandomseq disables TCP ISN randomization protection

·         he tcp max_conn and udp max_conn specifies the maximum number of simultaneous tcp/udp connections allowed to the local-host (default is 0 which doesn’t mean 0, means unlimited ;-))

The timeout conn and timeout xlate specifies the amount of time for the connections/translations. Always the translation time should be higher than the connection timeout, because translations are layer 3 and connections are layer 4

·The connection limits can be set in the NAT statements, however is recommended to use the Modular Policy Framework since it’s more versatile

HTTP GET & POST Requests

October 23, 2015, 1:39 am

≫ Next: GRE Tunnel Creation

≪ Previous: NAT order in ASA 8.2

$

0

0

HTTP GET & POST Requests

The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers. HTTP works as a request-response protocol between a client and server.

A web browser may be the client, and an application on a computer that hosts a web site may be the server.

Example: A client (browser) submits an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.

Two HTTP Request Methods: GET and POST 

             

Two commonly used methods for a request-response between a client and server are: GET and POST.

• GET - Requests data from a specified resource
• POST - Submits data to be processed to a specified resource

The GET Method

Note that the query string (name/value pairs) is sent in the URL of a GET request:

/test/demo_form.asp?name1=value1&name2=value2

Some other notes on GET requests:

• GET requests can be cached
• GET requests remain in the browser history
• GET requests can be bookmarked
• GET requests should never be used when dealing with sensitive data
• GET requests have length restrictions
• GET requests should be used only to retrieve data

The POST Method

Note that the query string (name/value pairs) is sent in the HTTP message body of a POST request:

POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2

Some other notes on POST requests:

• POST requests are never cached
• POST requests do not remain in the browser history
• POST requests cannot be bookmarked
• POST requests have no restrictions on data length

Compare GET vs. POST

The following table compares the two HTTP methods: GET and POST.

	GET	POST
BACK button/Reload	Harmless	Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted)
Bookmarked	Can be bookmarked	Cannot be bookmarked
Cached	Can be cached	Not cached
Encoding type	application/x-www-form-urlencoded	application/x-www-form-url encoded or multipart/form-data. Use multipart encoding for binary data
History	Parameters remain in browser history	Parameters are not saved in browser history
Restrictions on data length	Yes, when sending data, the GET method adds the data to the URL; and the length of a URL is limited (maximum URL length is 2048 characters)	No restrictions
Restrictions on data type	Only ASCII characters allowed	No restrictions. Binary data is also allowed
Security	GET is less secure compared to POST because data sent is part of the URL Never use GET when sending passwords or other sensitive information!	POST is a little safer than GET because the parameters are not stored in browser history or in web server logs
Visibility	Data is visible to everyone in the URL	Data is not displayed in the URL

Other HTTP Request Methods

The following table lists some other HTTP request methods:

Method	Description
HEAD	Same as GET but returns only HTTP headers and no document body
PUT	Uploads a representation of the specified URI
DELETE	Deletes the specified resource
OPTIONS	Returns the HTTP methods that the server supports
CONNECT	Converts the request connection to a transparent TCP/IP tunnel

GRE Tunnel Creation

November 19, 2015, 9:07 pm

≫ Next: Netflow configuration in Fortigate

≪ Previous: HTTP GET & POST Requests

$

0

0

Primary GRE Configuration

config system gre-tunnel

edit "ZscalerFilter"

set interface "internal3"        << Interface initiating tunnel connection

set local-gw 165.228.52.158   << Your IP initiating Tunnel

set remote-gw 165.225.98.32 << Zscaler IP for tunnel termination

next

end

config system interface

edit "ZscalerFilter"

set vdom "root"

set ip 172.18.234.73 255.255.255.252  << Address assigned to you by Zscaler // Internal Router IP

set allowaccess ping

set type tunnel

set remote-ip 172.18.234.74  << Address assigned to you by Zscaler  // Internal ZEN IP

set interface "internal3"

next

end

Secondary GRE configuration

config system gre-tunnel

edit "ZscalerBackup"

set interface " internal3"

set local-gw 165.228.52.158  

set remote-gw 175.45.116.32

next

end

config system interface

edit "ZscalerBackup"

set vdom "root"

set ip 172.18.234.77 255.255.255.252 << Address assigned to you by Zscaler // Internal Router IP

set allowaccess ping

set type tunnel

set remote-ip 172.18.234.78 << Address assigned to you by Zscaler  // Internal ZEN IP

set interface "internal3"

next

end

Create the route

config router static

edit 101   << Where 101 is the next Available number in your firewall

set device "ZscalerFilter"

set priority 1

next

edit 102  << Where 102 is the next Available number in your firewall

set device "ZscalerBackup"

set priority 2

            next

end

Create policy routes for Port 80 & 443

config router policy

edit 101                    << Where 101 is the next available number in your firewall

set input-device "internal2"  << Internal Interface

set src 10.0.0.0 255.0.0.0

set protocol 6

set start-port 80

set end-port 80

set gateway 172.18.234.74

set output-device "ZscalerFilter"

next

edit 102                   << Where 102 is the next available number in your firewall

set input-device "internal2"  <<Internal Interface

set src 10.0.0.0 255.0.0.0

set protocol 6

set start-port 80

set end-port 80

set gateway 172.18.234.78

set output-device "ZscalerBackup"

next

edit 103                    << Where 103 is the next available number in your firewall

set input-device "internal2"

set src 10.0.0.0 255.0.0.0

set protocol 6

set start-port 443

set end-port 443

set gateway 172.18.234.74

set output-device "ZscalerFilter"

next

edit 104                   << Where 104 is the next available number in your firewall

set input-device "internal2"

set src 10.0.0.0 255.0.0.0

set protocol 6

set start-port 443

set end-port 443

set gateway 172.18.234.78

set output-device "ZscalerBackup"

next

end

Create Firewall ACL's for traffic

config firewall policy

edit (Policy ID Goes here)

set srcintf "internal2"

set dstintf " ZscalerFilter"

set srcaddr "all"

set dstaddr "all"

set action accept

set schedule "always"

set service "HTTP"

set nat enable

next

edit (Policy ID Goes here)

set srcintf " internal2"

set dstintf " ZscalerBackup"

set srcaddr "all"

set dstaddr "all"

set action accept

set schedule "always"

set service "HTTPS"

set nat enable

next    

end

---

Netflow configuration in Fortigate

November 27, 2015, 12:30 am

≫ Next: Difference Between With / Without Proxy Traffic Flow

≪ Previous: GRE Tunnel Creation

$

0

0

Netflow configuration in Fortigate

sFlow agents can be added to any FortiGate interface, including physical interfaces, VLAN interfaces, and aggregate interfaces. However, sFlow agent/client is not supported on some virtual interfaces such as VDOM link, IPSec, gre, and ssl.<vdom>.

sFlow configuration is available only from the CLI.

The sFlow configuration are applied either globally, per-vdom, or per-interface, as shown below.

1. Set sFlow collector/server IP on the FortiGate.

config system sflow

set collector-ip x.x.x.x

set collector-port xxxx (default udp/6343)

end

2. To configure it per VDOM.

config system vdom-sflow

set vdom-sflow [disable*|enable]

set collector-ip x.x.x.x

set collector-port xxxx

end

3. Configure sFlow agents per interface.

config sys interface

edit

set sflow-sampler [disable*|enable]

set sample-rate xxxx //sample ever xxxx packets

set sample-direction [tx|rx|both*]

set polling-interval xx //in secs

next

end

Difference Between With / Without Proxy Traffic Flow

November 30, 2015, 10:58 pm

≫ Next: High CPU Utilization in Cisco Firewall

≪ Previous: Netflow configuration in Fortigate

$

0

0

Difference Between With / Without Proxy

Without Proxy (Direct HTTP request) - Destination IP is the HTTP server and the requested URI shows only the path behind the domain.

Only HOST info will be available in Wireshark. Request URI will be black and could see the Destination port details as well.

HTTP proxy requests: First packet is sent to the proxy. The requested URI shows the complete URL (host + path). 

HOST info & Request URI will be available in Wireshark.

A proxy is a server you can use to access the Internet anonymously. All your requests go through the proxy, which in turn sends you the results back. From the outside, the only one visible is the proxy - there's no way to know who's behind it.

People using proxies are usually trying to hide themselves - although there can be a few legitimate reasons to use one, like accessing a website that your ISP is blocking for some reason. In both scenarios, the “Host” value in the HTTP request is set to the requested domain. In the case of a proxy, the HTTP X-Forwarded-For header with the client IP address might be inserted.

High CPU Utilization in Cisco Firewall

December 2, 2015, 4:55 am

≫ Next: Action close & timeout in fortigate

≪ Previous: Difference Between With / Without Proxy Traffic Flow

$

0

0

High CPU Utilization in Cisco Firewall

If you noticed the CPU utilization is high, follow these steps in order to troubleshoot:

·         Verify that the connection count in show xlate count is low.

·         Verify that the memory block is normal.

·         Verify that the number of ACLs is higher.

·         Check if any captures enabled.

·         Run show conn count & show xlat count to validate the conn details

·         Check the traffic using show traffic.

Example -

Total number of packets received on ASA box: 73098 pkts/s

Throughput going to the box (calculation with packet size of 1500) :  73098 pkts/s(total numb of packets) * 1500 * 8 / 1024 / 1024

836 Mb/s

Actual throughput: 41532401(sum up of bytes) * 8 / 1024 / 1024 Mbits

316 Mbits

Average packet size:

568bytes

·      Create a CPU profile and collect the CPU dump , CISCO team can decrypt and see if any issues.

cpu profile activate 10000 (leave for 5min & don’t enter any commands on the CLI)

sh cpu profile dump

Verify the below outputs which will ensures the process running on ASA is fine.

1.      sh processes cpu-hog

2.      sh processes memory

  

Additionally to above we see overruns on ASA interfaces 

To mitigate this please consider to enable flow control on ASA and connected switch (switches)

For details please refer to bellow article

Adaptive Security Appliance Interface Overrun Counter Errors

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115985-asa-overrun-product-tech-note-00.html

Action close & timeout in fortigate

December 14, 2015, 9:31 pm

≫ Next: File System Check Error in Fortigate 5.2.3 and above

≪ Previous: High CPU Utilization in Cisco Firewall

$

0

0

Action close & timeout in fortigate

·         Action close simply means the session was closed voluntarily. 

·        A session timeout more-or-less means a session has reached the TTL waiting for a response from the other side and closes that session.

Configure the FortiGate to send TCP RST packet on session timeout

There are frequent use cases where a TCP session created on the firewall has a smaller session TTL than the client PC initiating the TCP session or the target device.

The underlying issue is that when the TCP session expires on the FortiGate, the client PC is not aware of it and might try to use again the past existing session which is still alive on its side.

This will generate unless attempts and traffic until the client PC decides to reset the session on its side to create a new one.

To avoid this behaviour, configure the FortiGate to send a TCP RST packet to the source and the destination when the correponding established TCP session expires due to inactivity.

So that the client and the server are informed that the session does not exist anymore on the FortiGate and they will not try to reuse it but create a new one.

#config firewall policy
# edit <ID>
#  set timeout-send-rst enable

File System Check Error in Fortigate 5.2.3 and above

December 24, 2015, 3:11 am

≫ Next: Authentication frequency on SAML configuration

≪ Previous: Action close & timeout in fortigate

$

0

0

File System CheckError in Fortigate 5.2.3 and above

In FortiOS 5.2 patch3, the file system check dialogue was introduced in the GUI and it offers the options to restart the unit and perform a file system check or, if desired, to be reminded later for performing the action in a maintenance window.

File System check is a feature that is checking if the device was not shutdown properly. It will do a disk scan when the system boots up to avoid any potential file system errors.  In fact, if the unit was shut down without using the proper command (#execute shutdown), during the booting sequence, the FortiGate will check internal files for this log event and, if it cannot find it, the message will be shown.

This behavior is by design and there is no option to disable this message.

The message should no longer be seen once the following actions have been completed:

- Check of the file system.
- Reboot of the device.

Syntax (Via Console / CLI)

diagnose system file-system {fscheck | fsfix | fsrebuild | fsreport}

Variable	Description	Default
file-system {fscheck | fsfix | fsrebuild | fsreport}	fscheck: Check the log disk consistency by rebooting the system. You can view the results using diagnose file-system fsreport after the reboot. fsfix: Fix non-critical errors on the log disk upon system reboot, and optimize directory structures for ext3 log disk file systems. You can view the results using diagnose file-system fsreport after the reboot. fsrebuild: Rebuild file system from scratches upon system reboot. This action may cause potential data loss. Do not perform this action unless the fsfix report has errors. You can view the results using diagnose file-system fsreport after the reboot. fsreport: Display the results of the fscheck, fsfix, and fsrebuild commands.	No

Authentication frequency on SAML configuration

January 13, 2016, 5:45 am

≫ Next: Window scaling & idle timeout for TCP sessions in Zscaler

≪ Previous: File System Check Error in Fortigate 5.2.3 and above

$

0

0

The time calculation for authentication frequency is always in GMT.

So, if the frequency is set to 90 days, at 12 AM GMT every day, it will get decremented by a value of 1. Unfortunately, there is no way to pull logs or any reference of the same.

However, whenever the user authenticates, a browser cookie is created. You can check for the cookie creation date in your browser settings. (Browser settings->cookies->all cookies and site data->click on the site accessed and check for the cookie creation time.)

Cookie expiry date mentioned there is not valid as by default all the browsers set this to 2 years. Based on the cookie creation date, you can calculate the time when the user needs to re authenticate.

How to check the cookie creation date in chrome.

Window scaling & idle timeout for TCP sessions in Zscaler

February 24, 2016, 5:01 am

≫ Next: Authentication cookies in ZScaler & its behaviour

≪ Previous: Authentication frequency on SAML configuration

$

0

0

Window scaling & idle timeout for TCP sessions in Zscaler

When the TCP RFC was first designed, a 16bit field in the TCP header was reserved for the TCP Window. This essentially being a receive buffer so you can send data to another machine up to the limit of this buffer, without waiting for an acknowledgement from the receiver to say it had received the data.

This 16 bit field means the maximum value of this is 2^16 or 65535 bytes. I'm sure when this was envisaged, it was thought it would be difficult to send such an amount of data so quickly that we could saturate the buffer.

However, as we now know, computing and networks have developed at such a pace that this value is now relatively tiny and it's entirely feasible to fill this buffer in a matter of milliseconds. When this occurs it causes the sender to back off sending until it receives an acknowledgement from the receiving machine which has the obvious effect of causing slow throughput.        

The way we get to the actual TCP Window size is (2^Scalingfactor)*TCP Window Size so If we take the maximum possible values it would be (2^14)*65535 = 1073725440 bytes or just over 1gb.

Zscaler We do support 1073725440 as max window. But that requires the client enabling time stamps on the client machine. It can be enabled on client machine by running this command as admin in Command prompt.

netsh interface tcp set global timestamps=enable

By default Zscaler advertise a scaling factor of 5.  You can enable timestamps on the client machine to use full use of scaling factor of 5 that we use.

Idle timeout for TCP sessions

We do not have idle timeout for TCP sessions in Zscaler end. But the value for (TCP) connection must be idle before keep alive probes are sent: 30000ms. The interval, in milliseconds, between keep alive probes sent to remote machines. After TCPTV_KEEPCNT (default 8) probes are sent, with no response, the (TCP) connection is dropped: 30000ms

---

Authentication cookies in ZScaler & its behaviour

March 14, 2016, 7:22 am

≫ Next: ARP issue in ASA 8.4 and above

≪ Previous: Window scaling & idle timeout for TCP sessions in Zscaler

$

0

0

·         All the redirects in the capture sent to us are for one request from user browser.

·         It take 900ms from the first request to the last response received from actual server. This is a onetime process that all domain have to go through for authentication.

·         We cannot insert a cookie in one redirect. We first test whether it accepts a cookie by inserting a dummy cookie "_sm_au_d", and if the browser returns back the dummy cookie then we know that Browser can store a cookie for this domain and return this cookie whenever this domain is called.

·         Now we start inserting Users unique cookie "_sm_au_c" and expect that this cookie will be stored by the browser and whenever user accesses the domain browser will return the cookie as well as it was able to return the dummy cookie.

·         User has made only one request to the Website from the User point of view. Zscaler is manipulating the browser to make two more requests for the website in the back-end to do required authentication. This process is not visible to user.

ARP issue in ASA 8.4 and above

March 29, 2016, 5:40 am

≫ Next: NTLM authentication prompt and certificate alert

≪ Previous: Authentication cookies in ZScaler & its behaviour

$

0

0

ARP issue in ASA 8.4 and above

·         The ARP issue atarted after the upgrade from 3.4 to 9.1

·         We noticed that the customer not able to access the servers from outside.

·         We tried to reach the server from firewall and failed

·         We cleared the MAC and tried again, but failed.

·         We cleared the MAC in Switch and no improvements

·         We failed over the device and tried, but no luck.

·         Later we enabled the Arp debug in firewall and found the below logs.

Debug command in ASA

debug arp

debug arp  enabled at level 1

HALHBECOMFW01# arp-req: generating request for 10.101.72.22 at interface APP

arp-req: request for 10.101.72.22 still  pending

list full, bp 0x6ecf63e0 freed

arp-req: generating request for 10.101.72.22 at interface APP

arp-req: request for 10.101.72.22 still  pending

list full, bp 0x6ecf63e0 freed

arp-req: generating request for 10.101.72.22 at interface APP

arp-req: request for 10.101.72.22 still  pending

list full, bp 0x6ecf63e0 freed

arp-req: generating request for 10.101.72.22 at interface APP

arp-req: request for 10.101.72.22 still  pending

list full, bp 0x6ecf63e0 freed

arp-req: generating request for 10.101.72.22 at interface APP

arp-req: request for 10.101.72.22 still  pending

list full, bp 0x6ecf63e0 freed

arp-send: arp request built from 10.101.72.1 1cdf.0f66.4b33 for 10.101.72.33 at 9267150

arp-in: response at APP from 10.101.72.33 0050.569d.4051 for 10.101.72.1 1cdf.0f66.4b33 having smac 0050.569d.4051 dmac 1cdf.0f66.4b33\n

 arp-in: src ip is same as one of nat mapped address 10.101.72.33 .Consuming the packet

arp-req: generating request for 10.101.72.22 at interface APP

arp-req: request for 10.101.72.22 still  pending

list full, bp 0x6ecf5fe0 freed

This is because of the ARP reply from firewall instead of the Server. Static NATs causes this issue. We included the below at the end of static NAT

no-proxy-arp route-lookup

MAC LEARNING CHANGE

To resolve the issues above CIsco introduced CSCuc11186 within a number of code versions, including 9.1(7). In short this changes the way that the ASA learns and populates its ARP cache. The ASA will refuse to populate its ARP cache should the NAT statement contain addresses that overlap with the external interface subnet. This typically occurs due to using 'any' objects. 

This can be resolved by,

• adding 'no-proxy-arp' to your identity NAT statements.
• removing the use of 'any' based objects

Identity NAT configurable proxy ARP and route lookup

In earlier releases for identity NAT, proxy ARP was disabled, and a route lookup was always used to determine the egress interface. You could not configure these settings. In 8.4(2) and later, the default behavior for identity NAT was changed to match the behavior of other static NAT configurations: proxy ARP is enabled, and the NAT configuration determines the egress interface (if specified) by default. You can leave these settings as is, or you can enable or disable them discretely. Note that you can now also disable proxy ARP for regular static NAT.

For pre-8.3 configurations, the migration of NAT exempt rules (the nat 0 access-list command) to 8.4(2) and later now includes the following keywords to disable proxy ARP and to use a route lookup: no-proxy-arp and route-lookup. The unidirectional keyword that was used for migrating to 8.3(2) and 8.4(1) is no longer used for migration. When upgrading to 8.4(2) from 8.3(1), 8.3(2), and 8.4(1), all identity NAT configurations will now include the no-proxy-arp and route-lookup keywords, to maintain existing functionality. The unidirectional keyword is removed.

NTLM authentication prompt and certificate alert

April 11, 2016, 7:04 am

≫ Next: PAC file - Recommendation, warnings and best practices

≪ Previous: ARP issue in ASA 8.4 and above

$

0

0

One of our customer was faced a strange issue while shifting their network from wired to WIFI and vice versa. Customer was received NTLM authentication prompt and certificate alert. We suspect that this is because of SSL inspection initially and found the cause for the issue as given below.

Here with briefing my responses,

·         FSSO agent pushes info to fortigate as soon as any change in IP is recorded.

·         FSSO agent periodically checks the IP addresses of logged-in users and updates the FortiGate unit when user IP addresses change.  This timer (IP address change time in FSSO agent) is especially important in DHCP environments or dynamic environments when mobile users may change their IP address as they move from one location (floor) to another together with their laptop (mobile device).  FSSO relies heavily on DNS for IP resolves. Make sure you allowed dynamic updates and configured DHCP server to update DNS whenever client IP address change.  If timer is changed to 1 sec it will generate 60 times more DNS traffic in the network for ip address change verification. It's difficult for me to say how your network/dns server will react to increase in DNS traffic.

·         Regarding SSL warning, it's coming because outlook is  using https and for ntlm authentication of https url's fortigate has to work as proxy. So this warning will continue to occur until a CA cert is imported in fortigate, refer the CA certificate for authentication and also in all user systems.

·         So in this scenario after user switches to WIFI there is no new logon event on AD hence DNS server should update the IP for the workstation . Now when FSSO agent does DNS query after configured DNS interval, if it gets new IP from dns server, FSSO entry will be updated with new IP both in Collector Agent and on Fortigate.

·         But if a http/https request comes to fortigate with new IP and it does not have updated information, as per policy configuration NTLM process is started for authentication.

Workaround to use FSSO instead of NTLM during network switch: users need to logoff and log back in after switching the network so that a new logon event is generated on AD server with new IP. FSSO agent will receive this new event from domain server and forward it to fortigate.

Solution for stop SSL warning:  Install a CA certificate to firewall and use the same as authentication certificate.

So this warning willl continue to occur until a CA cert is imported in fortigate and also in all user systems.

Refer imported CA cert in user settings.

config user setting

set auth-ca-cert <<CA certificate>
end

Note : CA certificate should be match with SSL inspection certificate

Note: Switch all collector agent’s logging level to the Debug level and switch the log size to 60Mb, on all collector agents.

Stage:

Ask user to login to domain PC and after login is successful, collect below details from respective places. 

·         From client PC
- username / group
- workstation name
- time of logon to the domain

ipconfig /all
echo %logonserver%
echo %username%
hostname
time /T
date /T
set 

·         From Fortigate:

diag debug reset
diag debug enable
diag debug console time en
diag debug authd fsso list
diagnose debug authd fsso server-status
diag firewall auth list 

From Collector Agent

Immediately copy of the collectoragent.log file from C:\Program Files\Fortinet\FSAE\
Collector Agent Logon Event Logs. Click on view logon events.

Stage 2:

Ask the user to switch the network and move to wifi and then collect these details from respective places.

·         From client PC

- username / group
- workstation name
- time of logon to the domain

ipconfig /all
echo %logonserver%
echo %username%
hostname
time /T
date /T
set 

----> output of nslookup for workstation name of client PC from DNS server. 

·         From Fortigate:
diag debug reset
diag debug enable
diag debug console time en
diag debug authd fsso list
diagnose debug authd fsso server-status
diag firewall auth list 

·         From Collector Agent 
Immediately copy of the collectoragent.log file from C:\Program  Files\Fortinet\FSAE\ Collector Agent Logon Event Logs. click on view logon events.

These details will help us in reviewing how dns is getting changed on collector agent and on DNS server. 

PAC file - Recommendation, warnings and best practices

May 28, 2016, 1:16 am

≫ Next: Customize Blue coat reporter port numbers

≪ Previous: NTLM authentication prompt and certificate alert

$

0

0

PAC File

A proxy auto-config (PAC) file defines how web browsers and other user agents can automatically choose the appropriate proxy server (access method) for fetching a given URL.

functionFindProxyForURL(url, host) {

// If the hostname matches, send direct.

    if(dnsDomainIs(host, "intranet.domain.com") ||

        shExpMatch(host, "(*.abcdomain.com|abcdomain.com)"))

        return"DIRECT";

// If the protocol or URL matches, send direct.

    if(url.substring(0, 4)=="ftp:"||

        shExpMatch(url, "http://abcdomain.com/folder/*"))

        return"DIRECT";

// If the requested website is hosted within the internal network, send direct.

    if(isPlainHostName(host) ||

        shExpMatch(host, "*.local") ||

        isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||

        isInNet(dnsResolve(host), "172.16.0.0",  "255.240.0.0") ||

        isInNet(dnsResolve(host), "192.168.0.0",  "255.255.0.0") ||

        isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0"))

        return"DIRECT";

// If the IP address of the local machine is within a defined

// subnet, send to a specific proxy.

    if(isInNet(myIpAddress(), "10.10.5.0", "255.255.255.0"))

        return"PROXY 1.2.3.4:8080";

// DEFAULT RULE: All other traffic, use below proxies, in fail-over order.

    return"PROXY 4.5.6.7:8080; PROXY 7.8.9.10:8080";

}

Recommendations

When deploying URL and host rules care must be taken to ensure rules are as explicit as possible. The examples below detail how host and URL rules should be implemented.

Host Example

if (dnsDomainIs(host, "abcdomain.com") || dnsDomainIs(host, "www.abcdomain.com"))

        return "DIRECT";

URL Example

if (shExpMatch(url, "http://abcdomain.com/folder/*"))

        return "DIRECT";

Warnings

The following code is an example which may have unintended consequences due to the broad interpretation of using the shExpMatch function, wildcards, and hostnames.

Cautionary Example

// Would send both of the following requests direct to the Internet:

// 1. www.hotmail.com 2. phishing-scam.com?email=someone@hotmail.com

 if (shExpMatch(url, "*hotmail.com*"))

        return "DIRECT";

Safe Example

// Would send only traffic to the host and subdomains of hotmail.com

 if (shExpMatch(host, "*.hotmail.com"))

        return "DIRECT";

PAC Functions

dnsDomainIs

Evaluates hostnames and returns true if hostnames match. Used mainly to match and exception individual hostnames.

Example

// If the hostname matches google.com or www.google.com

// send direct to the Internet.

 if (dnsDomainIs(host, "google.com") || dnsDomainIs(host, "www.google.com"))

    return "DIRECT";

shExpMatch

Will attempt to match hostname or URL to a specified shell expression, and returns true if matched.

Example

// Any requests with a hostname ending with the extension .local

// will be sent direct to the Internet.

 if (shExpMatch(host, "*.local"))

    return "DIRECT";

Example

// A request for the host vpn.domain.com or any request for a file or folder in the

// location http://abcdomain.com/folder/ will be sent direct to the Internet.

if (shExpMatch(host, "vpn.domain.com") ||

    shExpMatch(url, "http://abcdomain.com/folder/*"))

    return "DIRECT";

isInNet

This function evaluates the IP address of a hostname, and if within a specified subnet returns true. If a hostname is passed the function will resolve the hostname to an IP address.

Example

// If IP of requested website website falls within IP range, send direct to the Internet.

if (isInNet(dnsResolve(host), "172.16.0.0", "255.240.0.0"))

    return "DIRECT";

dnsResolve

Resolves hostnames to an IP address. This function can be used to reduce the number of DNS lookups, e.g. below example.

Example

// If IP of the requested host falls within any of the ranges specified, send direct.

if (isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||

    isInNet(dnsResolve(host), "172.16.0.0",  "255.240.0.0") ||

    isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0") ||

    isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0"))

    return "DIRECT";

localHostOrDomainIs

Evaluates hostname and only returns true if exact hostname match is found.

Example

// If the Host requested is "www" or "www.google.com", send direct.

if (localHostOrDomainIs(host, "www.google.com"))

    return "DIRECT";

isResolvable

Attempts to resolve a hostname to an IP address and returns true if successful. WARNING – This may cause a browser to temporarily hang if a domain isn’t resolvable.

Example

// If the host requested can be resolved by DNS, send via proxy1.example.com.

if (isResolvable(host))

    return "PROXY proxy1.example.com:8080";

Protocol Control

// HTTP

if (url.substring(0,5)=="http:") return "DIRECT";

// HTTPS

if (url.substring(0,6)=="https:") return "DIRECT";

// FTP

if (url.substring(0,4)=="ftp:") return "DIRECT";

Machine IP Based Routing

Example:1

if (isInNet(myIpAddress(), "10.10.5.0", "255.255.255.0"))

    return "PROXY 1.2.3.4:8080";

Example: 2

function FindProxyForURL(url, host)

{

var privateIP = /^(0|10|127|192\.168|172\.1[6789]|172\.2[0-9]|172\.3[01]|169\.254|192\.88\.99)\.[0-9.]+$/;

 var resolved_ip = dnsResolve(host);

/* Don't send non-FQDN or private IP auths to us */

 if (isPlainHostName(host) || isInNet(resolved_ip,  "192.0.2.0","255.255.255.0") || privateIP.test(host))

 return "DIRECT";

Points to remember:

ü  After updating my PAC file, the change I made don’t seem to have taken effect?

Browsers will cache a PAC file rather than retrieve it for each request; in some cases a browser restart is insufficient for obtaining an updated version of the file.In order to obtain the latest version it may be necessary to clear the browser cache, close all browser windows, and reopen the browser application.

ü  Why might web browsing performance degrade when using a PAC file?

A PAC file may leverage several functions which rely on the local DNS server(s) in order to resolve a requested host. These functions are isInNet(), isResolvable(), and dnsResolve().

ü  Tools to validate the pac file –

http://luno.org/project/proxyvalidator/

http://code.google.com/p/pacparser/
http://utmtools.com/PacMagic

Customize Blue coat reporter port numbers

July 18, 2016, 4:00 am

≫ Next: Restrict YouTube content on your network or managed devices

≪ Previous: PAC file - Recommendation, warnings and best practices

$

0

0

Customize Blue coat reporter port numbers

If some other applications using Bluecoat reporter default ports, then you can configure the Reporter to run at other ports:

·         Stop Reporter service.

·         Go to Reporter Installation Directory 3. Go to Setting Folder. You will see a cfg file called "Preference"

Change the port number:

http = {

ssl = {

ssl_v2 = "false"

ssl_v3 = "false"

tls_v1 = "true"

tls_v1_1 = "true"

tls_v1_2 = "true"

mode = "enable"

use_default_cert = "true"

cert_file = ""

key_file = ""

port = "8082" ### change to another port #. ex: 6062

password = "004cc6e07945f9"

} # ssl

ip = "0.0.0.0"

port = "8081" ### change to another port #. ex: 6061

} # http

·         Save the Preference file.

·         Start Reporter service and open Reporter Web GUI.