Tag Archives: FortiGate

Set up VPN IPSEC site-to-site between Palo Alto in AWS and FortiGate in premises

This is a diagram that I have used for this lab.

Understanding on deploying Palo Alto instance in AWS is necessary for this lab (https://tungle.ca/?p=3979).

On PA, Configure a tunnel.

Add a new static route into PA Virtual Route to allow traffic from the Private subnet to a LAN subnet in FortiGate.

Create IKE Crypto.
Create IPSEC Crypto.
Create an IKE Gateway.

Create an IPSEC tunnel.

Create PA-LAN and FG-LAN network.
Create both Security rules to allow traffic from PA-LAN to FG-LAN and vice versa.
Back to AWS – Route tables. Add a new static route on the Private Route.

Add 192.168.10.0/24 into the routes and select “Private Interface” on the target.

Move on to FortiGate.

Configure interfaces.

Configure default routes on FG.

Configure IPSEC VPN on FG.

Create a FG-LAN and PA-LAN address.
Set up a new static route to allow traffic from FG-LAN subnet in FG to PA-LAN subnet in AWS.
Create Security Polices to allow traffic from FG-LAN to PA-LAN and vice versa.
Setup IP address on Kali machine.

Ping from Kali machine to Windows instance (10.0.3.134).

Ping from Windows instance to Kali machine (192.168.10.2).

Check Security Policy status.
The FortiGate IPSEC tunnel is UP.

Back to Palo Alto in AWS. We can see the traffic from PA-LAN to FG-LAN and vice versa.

The Palo Alto IPSEC tunnel is UP.

Deploy an IPSEC VPN site-to-site between Palo Alto on-prem and Virtual Private Gateway on GCP

This is a diagram that I have used for the lab.

Create a new VPC network on GCP.

Search VPN keyword on the search function.

Click “Create VPN connection”.

Select Classic VPN.

Select tung-vpc on the network setting.

Create a new static IP address for your VPC.

Delete tunnel 2 because I have only used tunnel 1 in this lab. Then click Create.

Click gpc-pa-tunnel-1.

Edit the Routes to allow traffic from my tung-vpc network to the Internet via the Default Internet gateway.

We can see the static route from privatesubnet on GCP to the LAN subnets on Palo Alto has been created on the Routes section.

Check the Firewall and allow SSH from the Internet to Linux instance on the “privatesubnet”.

I have used “Allow all” to allow SSH from the Internet to Linux instance, We are able to change to only allow SSH protocol or port 22. Click Create.

Search “compute engine”, and click create an instance.

On network interfaces.

Click create.

Open SSH in browser windows on the Linux instance.

Go to FortiGate.

Create IP tunnel.

Phase 1.

Phase 2.

Create a static route to allow traffic from FortiGate LAN subnet to GCP privatesubnet.

Create both FG-LAN and GCP-LAN subnet.

Create both access rules to allow traffic from the FortiGate LAN subnet to the GCP private subnet and vice versa.

Ping from Kali machine to the Linux instance on GCP.

The tunnel is up on FortiGate.

Ping from Linux instance on GCP to Kali machine on FortiGate LAN subnet.

The tunnel is up on GCP as well.

Set up an IPSEC VPN site-to-site between FortiGate on-prem and Microsoft Azure

This is a diagram that I have used for the lab. I have used the same topology to deploy VPN site to site between Azure and Palo Alto firewall on-prem (https://tungle.ca/?p=3338). Basically I removed the Palo Alto firewall and put FortiGate in the diagram.

Create a new virtual network is Azure-PA.

Change default network to PrivateSubnet is 10.0.1.0.

A subnet address range is 10.0.1.0/24

Click Create.

Create a new subnet.

A subnetwork address range is 10.0.0.0/24

Go to “Virtual network gateway” to create a new virtual network gateway.

Virtual network: Azure-PA.

Subnet: Gatewaysubnet 10.0.0.0/24

Public IP address name: VPNIP

Click Create.

Wait around from 20 to 30 minutes to see if the Deployment will be done.

Go to “Local network gateway” and create a new local network gateway.

An IP address is a public IP address of the Palo Alto firewall.

Address space is Palo Alto’s LAN subnets.

Clock create.

Go to “Virtual network gateways”, and select the virtual network gateways that we have created in the previous step.

Go to “Connections” – Add.

Enter a shared key (PSK) for VPN site-to-site.

Take note of the IP address of Azure VPN.

On FortiGate on-prem.

Create a static default route.

Configure an IPSEC Tunnel.

Phase 1.

Phase 2.

Create a new network object for FortiGate.

FG-LAN: 172.16.0.0/16

Azure-LAN: 10.0.0.0/16.

Create both access rules to allow traffic from FortiGate LAN subnets to your Azure VPN private subnets. Remember “Disable NAT” on these rules.

Create a static route to allow traffic from FortiGate LAN subnets to your Azure private subnets via the IPSEC VPN site-to-site IKEv2 tunnel.

Ping from Kali machine to Windows 2016 on Azure.

The tunnel is up on FortiGate.

Ping a Kali machine on FortiGate LAN subnet from Azure.

Back to VPN2S, we can see the VPN status connection is “Connected”.

Sending FortiGate logs to Graylog open-source log management on AWS via IPSEC VPN site-to-site

This is a diagram that I have used to build this lab.

There are a couple of steps in this lab.

  • Configure IPSEC VPN site-to-site IKEv2 between FortiGate and AWS.
  • Implementing Graylog open-source log management on a Linux instance on AWS.
  • Download FortiGate Content Pack (.json file) for Graylog.
  • Upload the file into Graylog.
  • Configure FortiGate to send logs to Graylog via Graylog’s IP address and the destination UDP port 1500.

Use the link below to know how to deploy the VPN site-to-site between FortiGate on-prem and AWS.

https://tungle.ca/?p=2753

Create a new Linux instance (4GB RAM) to install Graylog.

On Security Group, create a couple of following rules to allow FortiGate LAN subnets to communicate with Graylog on AWS LAN subnets.

SSH to the Linux instance.

+ Update your system and install needed packages.

sudo hostnamectl set-hostname graylog
sudo yum update -y
sudo yum install epel-release
sudo wget https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/p/pwgen-2.08-1.el7.x86_64.rpm
sudo rpm -ivh pwgen-2.08-1.el7.x86_64.rpm

+ Install JAVA

sudo yum install java-1.8.0-openjdk-headless.x86_64 -y
sudo java -version

+ Create a repository file. Then add the content below to this repository.

sudo nano /etc/yum.repos.d/mongodb-org.repo
[mongodb-org-4.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

+ Install MongoDB.

sudo yum install mongodb-org -y

+ Enable and start the mongoDB service on the system.

sudo systemctl daemon-reload
sudo systemctl enable mongod.service
sudo systemctl start mongod.service
sudo systemctl --type=service --state=active | grep mongod

+ Check MongoDB service port.

netstat -antp | grep 27017

+ Installing Elasticsearch.

Create a repository, then add the following contents to the file.

sudo nano /etc/yum.repos.d/elasticsearch.repo

[elasticsearch-6.x]
name=Elasticsearch repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/oss-6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1

Install the open-source version of Elasticsearch.

sudo yum install elasticsearch-oss -y
#Edit the elasticsearch.yml file on /etc/elasticsearch/elasticsearch.yml
sudo nano /etc/elasticsearch/elasticsearch.yml

Modify the Elasticsearch configuration file. Set the cluster name to graylog and add “action.auto_create_index: false” to the file.

Save and exit the file. Enable, start and check the status of elastic search on the system.

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
sudo systemctl restart elasticsearch.service
sudo systemctl --type=service --state=active | grep elasticsearch

Check elastic search health.

curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'

+ Installing the Graylog.

Now install the Graylog repository configuration with the following command.

sudo rpm -Uvh https://packages.graylog2.org/repo/packages/graylog-4.2-repository_latest.rpm

Install Graylog-server.

sudo yum install graylog-server -y

Configure Graylog.

Generate password_secret.

pwgen -N 1 -s 96

[ec2-user@ip-10-0-0-64 ~]$ pwgen -N 1 -s 96
Bv6a46BXTALlfI3VRZ3ACfzBoIZOo3evqd7v7FY0fsrSXNZDflPcWRtYoxRrm5BZfMvq2TKffWEobYL6iSwBW908gpSC9z79

Generate root_password_sha2.

echo -n graylog@123 | sha256sum | cut -d” ” -f1

[ec2-user@ip-10-0-0-64 ~]$ echo -n graylog@123 | sha256sum | cut -d” ” -f1
cc41de147e5c624c6a7c230648545f6d14f82fa0e591148dc96993b3e539abfc

Edit etc/graylog/server/server.conf file.

sudo nano /etc/graylog/server/server.conf
Comment the following line.
#http_bind_address = 127.0.0.1:9000

Add the following line with IP address of Graylog.
http_bind_address = 10.0.0.64:9000

Enable and start Graylog service.

sudo systemctl enable graylog-server.service
sudo systemctl start graylog-server.service

Check Graylog Server listening port.

netstat -antp | grep 9000

Access Graylog web interface from Kali’s machine on FortiGate LAN subnets.

http://10.0.0.4:9000
user:admin
password:graylog@123

Back to FortiGate, configure the Syslog setting to send logs via the Graylog server on its IP address 10.0.0.64 with a destination port is 1500.

config log syslogd setting
set status enable
set server 10.0.0.64
set port 1500
end 
show log syslogd setting

On Graylog.

Download FortiGate Content Pack from Github.

https://marketplace.graylog.org/addons/f1b25e9c-c908-41e4-b5de-4549c500a9d0

https://github.com/teon85/fortigate6.4_graylog4

Download the JSON file (fortigate6.4_graylog4.json)

Go to System – Content Packs – Upload. Select the file (fortigate6.4_graylog4.json) and upload.

Click Install.

Change the Syslog port to 1500.

FortiGate dashboard.

Set up VPN site-to-site between FortiGate on-prem and AWS. Send FortiGate logs to Splunk on AWS

This is a diagram that I have used for this demonstration.

Create your VPC.

Create a private subnet.

Create a new Internet Gateway and attach it to your VPC.

Create a new route to 0.0.0.0/0 to your Internet gateway.

Create a new Customer gateway with the public IP address of FortiGate.

Create a new Virtual Private Gateway and attach it to your VPC.

Create a new VPN site-to-site.

Click Download Configuration to configure on your FortiGate.

Log into FortiGate.

Interfaces.

Copies these commands and pastes them into FortiGate. Notes the set “mtu 1427” and set “mtu-override enable” does not available on FortiGate 6.2

Back to AWS and launch a new Linux VM instance. This machine is used to test VPN site-to-site.

Configure a new static route to allow LAN subnets on AWS to access LAN subnets on FortiGate.

On FortiGate, configure a new static route to AWS LAN subnets.

Configure access rules to allow FortiGate LAN subnets to communicate with AWS LAN subnets.

Pings from Kali machine to the Linux VM instance on AWS.

The IPSEC tunnel in FortiGate is up.

Back to AWS, the VPN tunnel is up.

Launches a new Windows 2016 VM instance to install Splunk.

On Security Group, add a couple of rules to allow ICMP and all traffic on FortiGate LAN subnets to access this instance.

RDP to Windows instance and disable Firewall to send logs from FortiGate.

Download Splunk Enterprise for Windows and install it into this instance.

Install FortiGate App for Splunk and Fortinet FortiGate Add on Splunk.

Click on the Settings tab and configure Splunk to get FortiGate logs. Select new Local UDP.

Enter 514 on the port setting. Be default, FortiGate is using UDP port 514 to send log to Syslog.

Select: fgt_log

App Context: Fortinet FortiGate App for Splunk

Method: IP

Index: Default

Check the UDP 514 port is running in the instance.

Back to FortiGate, configure Fortigate to send logs to Splunk on AWS. Enter the IP address of Splunk on the IP Address setting, and click choose All for “Event Logging” and “Local Logging”. Then, click Apply.

Log out of FortiGate and log back in to generate logs. If we may not see FortiGate logs on Splunk, we need to type the commands below to change the source-ip address to send log from using the “management interface” to using the LAN interface “172.16.1.254”

config log syslogd setting
    set status enable
    set mode udp
    set port 514
    set server "10.0.0.48"
    set source-ip "172.16.1.254"
end

Also, enable PING Access, HTTP, and HTTPS on tunnel 1 interface of FortiGate.

Splunk is able to ping the FortiGate LAN interface.

Back to the Splunk instance, now we are able to see logs from FortiGate.

Implementing Elastic Network Load Balancing on both FortiGates in multiple AZs

This is a diagram that is used to deploy this lab.

In this lab, we will use Elastic Load Balancer to distribute RDP traffic via Windows 2016 VM instances among the FortiGate in different AZs on AWS.

Below are a couple of steps that are used to deploy this lab.

  • Create your VPC, subnets, and route tables.
  • Launch FortiGate 1 on AZ 1 and FortiGate 2 on AZ 2.
  • Create both Windows 2016 VM on AZ 1 and AZ 2.
  • Configure DNAT to allow RDP traffic from the Internet to Windows Server 2016 instance on each AZ.
  • Configure Elastic Network Load Balancing on both FortiGates on multiple AZ.
  • RDP traffic has been distributed to Windows 2016 VM1 and VM2 via Elastic Network Load Balancing

Create a new VPC.

Create both Public subnet 1 and Private subnet 1 on the first Availability Zone.

Create new both Public subnet 2 and Private subnet 2 on the Availability zone 2

Create 4 route tables as in the diagram above.

Link the subnets to corresponding route tables.

Create a new FortiGate on AZ 1.

Security Group.

Create a new Elastic IP address and associate for the first FortiGate.

Launch the new FortiGate instance on AZ 2.

Rename to Fortinet Zone 1 Public subnet and Fortinet Zone 2 Public Subnet.

Create a new Fortinet Zone 1 Private subnet.

Attach this into the first FortiGate.

Create a new Fortinet Zone 2 Private subnet and attach it to FortiGate 2.

Uncheck “Change source/destination check” on all FortiGate interfaces.

Back to Route tables.

Create a new route 0.0.0.0/0 on Public Route table 1 via Fortinet Zone 1 Public subnet interface.

Create a new route 0.0.0.0/0 on Public Route table 2 via Fortinet Zone 2 Public subnet interface.

Create a new route 0.0.0.0/0 on Private Route table 1 via Fortinet Zone 1 Private subnet interface.

Create a new route 0.0.0.0/0 on Private Route table subnet 2 via Fortinet Zone 2 Private subnet interface.

Access FortiGate management interface.

The FortiGate 1.

Change the LAN setting for port 2.

Do the same with FortiGate 2.

Create two new Windows Server 2016 instances on AZ1 and AZ2.

Windows Security Group.

Launch the new one.

Go to FortiGate 1, and DNAT port 3389 to Windows Server 2016 VM 1 instance.

Create a new inbound policy to allow traffic from the Internet to Windows 2016 instance.

On FortiGate 2.

Create a new Firewall Policy.

Edit the Security Group to allow RDP to Windows 2016 VM 2 instance.

Access Windows VM 1.

Create Network Load Balancer on AWS for RDP traffic to Windows Server 2016 instance.

Select “IP address”.

Add IP addresses on the public subnet of both FortiGates on “register targets”.

Click Register targets.

Wait until the health states on both IP addresses are healthy.

Right-click on FortiGate-NLB-RDP and enable “Cross zone load balancing” to allow load balancing on multiple AZ.

Set the same Windows password for both Windows 2016 instances.

Access RDP to the highlighted DNS name on NLB.

An RDP session will access Windows Server VM 1 or VM 2 via Elastic Load Balancing.

We are able to configure both web servers on Windows server 2016 VMs and distribute web traffic via Windows 2016 VM instances among the FortiGate in different AZs on AWS.