Fortigate

Transit Gateway AWS, Two Regions, Route BGP, VPN IPSec, Fortigate

Como havia comentado anteriormente, neste post irei demonstrar um cenário onde vamos utilizar “Transit Gateway” na AWS, para substituir o peering entre as VPC, e utilizá-lo em uma VPN IPSec com Fortigate com roteamento BGP.

Topologia Transit Gateway com 2 regiões e VPN IPSec com Fortigate

Vamos ao nosso cenário:

AWS Cloud (sa-east-1)
my-vpc-01 (10.120.0.0/24)
                my-subnet-01 (10.120.0.0/24)
my-vpc-02 (10.120.1.0/24)
                my-subnet-01 (10.120.1.0/24)

my-route-table-01
                my-subnet-01 (10.120.0.0/24) (anexado a subnet)
my-route-table-02
                my-subnet-02 (10.120.1.0/24) (anexado a subnet)
my-sg-01
TGW-01 (transit gateway)

AWS Cloud (us-east-2)
my-vpc-03 (10.120.2.0/24)
                my-subnet-01 (10.120.2.0/24)
my-vpc-04 (10.120.3.0/24)
                my-subnet-01 (10.120.3.0/24)
my-route-table-03
                my-subnet-01 (10.120.2.0/24) (anexado a subnet)

my-route-table-04
                my-subnet-02 (10.120.3.0/24) (anexado a subnet)
my-sg-02
TGW-02 (transit gateway)

Fortigate (OnPremises)
Rede01 10.126.0.0/24
Rede02 10.126.1.0/24
Rede03 10.126.2.0/24

Agora vamos a mão na massa, não vou dar tantos detalhes na criação dos objetos neste post.


*Obs neste post, temos redes simples e roteamente FULL ou seja todo mundo fala com todo mundo, SG e ACL liberado Any, isso para facilita o entendimento, em produção isso deve ser revisto e liberado somente o que for necessário para seu pleno funcionamento. Colocamos todas as subnets na mesma zona para faciliar o artigo, mas em produção sugiro ter pelo menos duas subnets, uma em cada zona, exemplo subnet1 zona A e subnet2 zona B.

Nossas VPCs (AWS sa-east-1)

Nossas Subnets

Nossos Route Tables

Agora vamos criar nosso Transit Gateway (sa-east-1)

Name tag “tgw-01”
Description “Transit Gateway Sao Paulo”
ASN “64530” esse será nosso ASN
Auto accept shared attachments *Deixe habilitado
O restante deixem como mostrado na figura abaixo

Transit Gateway criado em “transit Gateways” Create

Agora vamos criar nosso Transit Gateways Attachment

Name tag “tgw-attch-01”
Transit gateway ID “escolha o que acabamos de criar”
Attachment type “Escolha VPC”
VPC attachment “Habilite DNS Support”
VPC ID “Escolha my-vpc-01”

Clique em criar

Repita os mesmos passos para attachment a “my-vpc-02”

Agora temos dois transit attachment

Agora que temos o Transit Gateway criado e temos as VPC anexadas, vamos criar o roteamento para nossas VPCs (sa-east-1) (us-east-2) (rede Fortigate)
Em route table vamos associar da subnet em seus respectivo arquivo de rota

Após associar as subnets, vamos criar o roteamento para nosso transit gateway
10.120.1.0/24 (rede aws sa-east-1) para nosso tgw
10.120.2.0/24 (rede aws us-east-2) para nosso tgw
10.120.3.0/24 (rede aws us-east-2) para nosso tgw
10.126.0.0/24 (rede Fortigate) para nosso tgw
10.126.1.0/24 (rede Fortigate) para nosso tgw
10.126.2.0/24 (rede Fortigate) para nosso tgw

Repita os passos para my-route-table-02
10.120.1.0/24 (rede aws ea-east-1) para nosso tgw
10.120.2.0/24 (rede aws us-east-2) para nosso tgw
10.120.3.0/24 (rede aws us-east-2) para nosso tgw
10.126.0.0/24 (rede Fortigate) para nosso tgw
10.126.1.0/24 (rede Fortigate) para nosso tgw
10.126.2.0/24 (rede Fortigate) para nosso tgw

Até o presente momento ja temos essa topologia

Agora em nossos SG, vamos liberar os trafego

Liberamos aqui as seguintes redes
10.120.1.0/24 (rede aws ea-east-1)
10.120.2.0/24 (rede aws ea-east-2)
10.120.3.0/24 (rede aws ea-east-2)
10.126.0.0/24 (rede Fortigate 01)
10.126.1.0/24 (rede Fortigate 02)
10.126.2.0/24 (rede Fortigate 03)

Repita os passos para “my-sg-02”

Liberamos aqui as seguintes redes
10.120.0.0/24 (rede aws ea-east-1)
10.120.2.0/24 (rede aws ea-east-2)
10.120.3.0/24 (rede aws ea-east-2)
10.126.0.0/24 (rede Fortigate 01)
10.126.1.0/24 (rede Fortigate 02)
10.126.2.0/24 (rede Fortigate 03)

Ficará desta forma

Agora vamos partir da nosso ambiente na AWS em us-east-2

Vamos as nossas VPCs
my-vpc-03 10.120.2.0/24
my-vpc-03 10.120.3.0/24

Nossas subnets

Nossos Route table, ja deixei associado nossas subnet as tabelas de rotas

Agora vamos criar nosso Transit Gateway em us-east-2

As opções são as mesmas

Name tag “tgw-02”
Description “Transit Gateway Ohio”
ASN “64530” esse será nosso ASN
Auto accept shared attachments *Deixe habilitado
O restante deixem como mostrado na figura abaixo

Nosso TGW

Agora vamos criar nosso Transit Gateways Attachment

Name tag “tgw-attch-02”
Transit gateway ID “escolha o que acabamos de criar”
Attachment type “Escolha VPC”
VPC attachment “Habilite DNS Support”
VPC ID “Escolha my-vpc-03”

Clique em criar

Repita os mesmos passos para attachment a “my-vpc-03”

Agora que temos o Transit Gateway criado e temos as VPC anexadas, vamos criar o roteamento para nossas VPCs (sa-east-1) (us-east-2) (rede Fortigate)

10.120.0.0/24 (rede aws sa-east-1) para nosso tgw
10.120.1.0/24 (rede aws sa-east-1) para nosso tgw
10.120.3.0/24 (rede aws us-east-2) para nosso tgw
10.126.0.0/24 (rede Fortigate) para nosso tgw
10.126.1.0/24 (rede Fortigate) para nosso tgw
10.126.2.0/24 (rede Fortigate) para nosso tgw

Repita os mesmos passos para “my-rote-table-02”

10.120.0.0/24 (rede aws sa-east-1) para nosso tgw
10.120.2.0/24 (rede aws sa-east-1) para nosso tgw
10.120.4.0/24 (rede aws us-east-2) para nosso tgw
10.126.0.0/24 (rede Fortigate) para nosso tgw
10.126.1.0/24 (rede Fortigate) para nosso tgw
10.126.2.0/24 (rede Fortigate) para nosso tgw

Até aqui temos essa infra em us-east-2

Agora em nossos SG, vamos liberar os trafego

Liberamos aqui as seguintes redes
10.120.0.0/24 (rede aws ea-east-1)
10.120.1.0/24 (rede aws ea-east-1)
10.120.3.0/24 (rede aws us-east-2)
10.126.0.0/24 (rede Fortigate 01)
10.126.1.0/24 (rede Fortigate 02)
10.126.2.0/24 (rede Fortigate 03)

Repita os passos para “my-sg-04”

10.120.0.0/24 (rede aws ea-east-1)
10.120.1.0/24 (rede aws ea-east-1)
10.120.3.0/24 (rede aws us-east-2)
10.126.0.0/24 (rede Fortigate 01)
10.126.1.0/24 (rede Fortigate 02)
10.126.2.0/24 (rede Fortigate 03)

Ficará desta forma

Calma ainda não acabou .rs…… agora vamos compartilhar nosso transit gateway de sa-east-1 com us-east-2, agora precisar pegar o ID do nosso transit gateway de us-east-2, anotem esse numero (não o meu mas sim o seu rs..)

Agora vamos voltar para sao paulo, em nosso transit gateway de sao paulo e vamos em transit gateway attchments, create transit gateway attchments

name tag “shared-tgw-ohio
transit gateway ID “nosso tgw de sao paulo”
Attchment Type “Peering Coonection”
Account “My Account”
Region “US East (Ohio) (us-east-2)
Transit Gateway ID “O ID que separamos do TGW de Ohio”
Clique em create

Se tudo deu certo, estamos neste ponto

Agora temos que aceitar o peering lá em Ohio

Estamos assim em Ohio

Vamos aceitar o peering

Selecione o transit gateway attchment, depois em actions, Accep transit gateway attachment

Mais um vez

Estamos assim em nosso transit gateway em ohio

Estamos assim em nosso transit gateway em são paulo

Até agora temos essa infraestrutura de rede na AWS em sa-east-1 (sao paulo) e us-east-2 (Ohio), o roteamento entre as regiões está sendo feito via “Transit Gateway”, temos rotas cadastradas e liberação em nossos SG.

Ainda não acabou ..rs….calma respira, estamos quase em 50%, simmmm isso mesmo 50% rs… ainda temos que criar o roteamente dentro do Transit Gateway em Sao Paulo e Ohio, mais é simples, bora lá.

Em “Transit Gateways, vamos em Transit gateway Route Tables

Temos este Route Table (Transit Gateway) “my-route-table-tgw”

Em Associations, veja que temos nossos anexos criados anteriormente

Agora vamos em “Routes”

Veja que temos ‘route’ para nossas VPC de sa-east-1, vamos adicionar rotas para as VPCs de us-east-2

Em create routre, CIDR “10.120.2.0/24 e escolha o attchment “Peering”, clique em create static route

Repita os passos para a segunda VPC de Ohio

Se tudo deu certo até agora, temos esse cenário:

Vamos aproveitar e fazer a mesma coisa no transit gateway de Ohio, ufa…..dá trabalho né….rs…., estamos quase lá…

Em Ohio (us-east-2), temos nosso route table transit gateway

Temos nossas associações

Agora vamos criar todas da mesma maneira que fizemos em sa-east-1, porém em us-east-2 iremos criar as rotas para a rede do Fortigate também, associando elas ao peering.

Se tudo correu bem, temos este cenário

Em us-east-2 (Ohio) tudo certo agora, vamos voltar para sa-east-1 (Sao Paulo)

Vamos partir para nossa VPN com Fortigate, em “Virtual Private Network (VPN), vamos criar um Customer Gateway

Name “cg-fgt”
Routing “Dynamic”
BGP ASN “65010” esta ASN será do nosso Fortigate
Cetificate ARN “Deixe como esta”
Device “Fortigate” este item não é obrigatório
Clique em “Create Customer Gateway”

Se tudo correu bem

Agora vamos voltar para nosso Transit Gateway Attchment em sa-east-1 e vamos anexar nossa VPN
Transit Gateway ID “escolha nosso transit gateway”
Attchment Type “VPN”
VPN Attchment “”Existing” escolha a que foi criada (customer gateway)
Routing Options “Dymanic BGP”
Enable Accleration “habilite”
O restante deixe como esta

Se tudo correu bem, temos este cenário, temos anexados em nosso transit gateway duas VPCs, um Peering e uma VPN.

Feito isso, nossa conexão Site-to-Site é criada automaticamente. Veja como ficou:
Temos transit gateway criado e cg criado

Temos aqui os detalhes dos Tunneis que estão DOWN (pois ainda não chegamos no fortigate)

Agora por fim e não menos importante (rs…) vamos para o fortigate. Antes disso precisamos pegar o arquivos na AWS para sabermos nossa PSK, pegamos ele em connections mesmo, fazer download e escolher Fortigate, feito download do arquivo, bora lá fazer as configurações.
Vamos criar nossos Tuneis Phase1 e Phase2

Phase1

Phase2

Agora vamos criar o Segundo Tunel

Phase1

Phase2

Se tudo correu bem, temos dois tuneis VPN

Agora vamos configura nosso BGP.

#Vamos fazer via CLI no prompt do Fortigate

##Aqui vamos configura as interfaces (VPN)
##As informações de configurações encontra-se no arquivo .txt que fizemos download do console da AWS


config system interface
    edit TunnelAWS01
        set ip 169.254.97.118 255.255.255.255
        set remote-ip 169.254.97.117 255.255.255.252
    next
    edit TunnelAWS02
        set ip 169.254.72.94 255.255.255.255
        set remote-ip 169.254.72.93 255.255.255.252
    next
end

Se tudo correu bem, temos essa saída:

E temos as configurações nas interfaces

Vamos adicionar essas Interfaces a nossa Zona “Cloud”, aconselho a trabalhar com zonas, isso facilita o trabalho administrativo.

Agora vamos criar as regras de Firewall, neste post criaremos regras de InBound e OutBound Any para facilitar o artigo, é claro que no ambiente de produção isso não deve acontecer (mas sabemos por ai que é assim que funciona rs…)

##Vamos criar as regras via CLI do Fortigate

#Criar regras de firewall
###Eu trabalho com Zonas, então Trust é minha LAN e UnTrust é minha WAN

config firewall policy
    edit 1
        set name Cloud-to-Trust
        set srcintf Cloud
        set dstintf Trust
        set srcaddr all
        set dstaddr all
        set action accept
        set schedule always
        set service ALL
    next
    edit 2
        set name Trust-to-Cloud
        set srcintf Trust
        set dstintf Cloud
        set srcaddr all
        set dstaddr all
        set action accept
        set schedule always
        set service ALL
end

Se tudo correu bem temos essa saída

Temos nossas regras criadas

Vamos ver se nossa VPN esta UP!. Nossos tuneis estão UP, Phase1 e Phase2

Porém nosso BGP ainda não esta UP!

Vamos configura o nosso anuncio de BGP para a AWS
Vamos fazer via CLI do Fortigate

#Configurando BGP

config router bgp
    set as 65010
    set router-id 20.201.30.224
    config neighbor
        edit 169.254.97.117
            set soft-reconfiguration enable
            set remote-as 64530
        next
    end
    config neighbor
        edit 169.254.72.93
            set soft-reconfiguration enable
            set remote-as 64530
        next
end

Se tudo correu bem

Agora vamos anunciar nossas rotas para AWS

Fortigate –> Network –> BGP
10.126.0.0/24
10.126.1.0/24
10.126.2.0/24
Se tudo correu bem temos essas rotas anunciadas.

E temos esses vizinhos configuradores

Vejam que com essas configurações nossas Rotas BGP para AWS já estão sendo recebidas

Vamos ver se na AWS nosso Transit Gateway ja esta recebendo nossas rotas anunciado pelo Fortigate? Vamos lá em “Transit Gateways” depois em “Transit Gateway Attchments”, vamos selecionar nosso transit gatewsy route table e em “routes”.
Vejam pela imagem abaixo que nossas redes anunciadas pelo Fortigate já estão aparecendo

Agora vamos ver se tudo isso que foi feito acima (Vamos combinar que dá um certo trabalho e um pouco de conhecimento) esta funcionando.

Agora fazer os testes a partir de uma VM que esta atras do Fortigate
IP: 10.126.0.132, a partir desta VM temos que conseguir chegar em todas as EC2 que estão na AWS, tanto em sa-east-1 (sao paulo) como em us-east-2 (ohio).
IPs de destinos de nossas EC2
my-ec2-01 IP 10.120.0.173
my-ed2-02 IP 10.120.1.221
Conforme imagem abaixo:

Vamos verificar a conectividade entre nossa rede 10.126.0.0/24 (Fortigate) e as redes da AWS (sao paulo) 10.120.0.0/24 e 10.120.1.0/24
1 teste OK

2 teste ok

Conseguimos conectividade para AWS sa-east-1, agora vamos para us-east-2.
IPs de destinos de nossas EC2
my-ec2-03 IP 10.120.2.164
my-ed2-04 IP 10.120.3.223
Conforme imagem abaixo:

Vamos verificar a conectividade entre nossa rede 10.126.0.0/24 (Fortigate) e as redes da AWS (sao paulo) 10.120.2.0/24 e 10.120.3.0/24
1 teste ok

2 teste ok

Imagem do Debug do Fortigate onde vemos os pacotes

Agora vamos ver o a conectividade da AWS para nossa rede Fortigate.
VMs fortigate
my-vm-01 IP 10.126.0.132
my-vm-02 IP 10.126.1.4
my-vm-03 IP 10.126.2.4
Vamos executar os teste a partir da my-ec2-01 IP 10.120.0.173
Estou dentro da VM my-ec2-01 IP 10.120.0.173
Vamos aos teste de conectividades para Fortigate
1 teste ok

2 teste ok

3 teste ok

Temos conectividade entre AWS sa-east-1 e as redes do Fortigate, agora vamos para us-east-1>
Estou dentro da my-ec2-03 em us-east-2 (Ohio) vamos ver se termos conectividade

1 teste ok

2 teste ok

3 teste ok

4 teste ok

Teste de da rede 10.126.1.0/24, conforme figura abaixo, teste de conectividade esta ok.

Com os testes concluímos nosso artigo, ufá, deu trabalho mas no final deu tudo certo.

Abaixo a topologia final.

Espero ter ajudado.

Links de referencias:

https://pt.wikipedia.org/wiki/Border_Gateway_Protocol
https://aws.amazon.com/pt/transit-gateway/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc
https://docs.aws.amazon.com/pt_br/vpc/latest/peering/create-vpc-peering-connection.html
https://pt.wikipedia.org/wiki/IPsec
https://docs.fortinet.com/document/fortigate-public-cloud/7.0.0/aws-administration-guide/506140/connecting-a-local-fortigate-to-an-aws-vpc-vpn
https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-peering-scenario.html

Seja Feliz!!!!


VPN IPSEC AWS e FORTIGATE BGP

Neste artigo irei configurar um VPN IPSec entre AWS e Fortigate com Roteamente BGP.

Vamos ao nosso cenário:

AWS – Sao Paulo

VPC
My-VPC-01 10.128.0.0/24

Subnet
my-subnet-01 10.128.0.0/26

Route table
my-routetable-01 (Subnet-01)

Security Group
my-sg-01

My EC2
my-ec2-01 (my-subnet-01)

Temos nosso “Costumer Gateway”

Abaixo as configurações com as nossas configurações (IP/ASN do Fortigate), um ponto bem importante aqui vamos utilizar o “ASN” “65010”, ele tem que ser único na sua rede.

Para maiores informações clique aqui

Após criado, ficará desta forma

Agora vamos para os nossos Virtual Private Gateway (VPG) – “my-vpg”

Agora aqui iremos utilizar o “ASN” “64530”este ASN será o ASN da AWS, criei tres VPG (my-vpg-01/02/03) todos com os mesmos ASN

Após a criação ficará desta forma

Agora teremos que anexar nosso VPV (iremos anexar “my-vpc-01”, “Action” “Attach to VPC”

Agora temos nosso vpg com vpc attach

Agora vamos voltar para nossos arquivos de “Route Table”

Vamos selecionar “my-route-table-01”, depois em “Propagação de Rotas”, editar propagação de Rotas e Habilitar a propagação, repita esses passos para os outros dois aquivos de Route Table.

Agora vamos criar nossa conexão com nosso Fortigate

Se tudo correu bem, teremos essa tela

Agora vamos para nosso fortigate, mas antes disso precisamos pegar as configurações, clique em “fazer download da configuração”

Fornecedor “Fortinet”
Plataforma “Fortigate 40+ Series”
Software “FortiOS 6.4.4 + (GUI)
Ike Version “IKEv2”

Pronto, agora sim, vamos para nosso Fortigate

EM VPN, IPSec Wizard, Create New

Vamos utilzar este nome “TunnelAWS01” nos iremos criar dois tunneis para este exemplo.

Essas são as informações fornecidas para o Tunnel 01

New VPN Tunnel Window Appears (Here we configure the VPN settings):

Under “Network” Section:
a. IP Version:     IPv4
b. Remote Gateway: Static IP Address
c. IP address: 54.207.145.204
d. Local Interface: wan1
e. Local Gateway: Select Specify and enter WAN port IP (Public IP)
f. Dead Peer Detection: Enable by selecting On Idle/ On Demand
g. Authentication Method: Pre-shared Key
h. Pre-Shared Key: KUGQkdF1Y3_hKD1mI5azR2JwEQRE463n
i. IKE Version: 2
Phase 1 Proposal:
j.  Encryption: aes128
k. Authentication: sha1
l. DH group: 2     ! and deselect 5
m. Keylife: 28800 seconds

! NAT Traversal is enabled by default but if your FortiGate device is not behind a NAT/PAT device, please deselect NAT Traversal.

! --------------------------------------------------------------------------------
! #2: IPSec Configuration

Under Phase 2 Selectors --> New Phase 2
a.	Name:  vpn-04ec6648c35364924-0
b.	Local Address: LAN subnet behind Fortigate/0.0.0.0/0
c.	Remote Address: AWS Private Subnet/0.0.0.0/0

Under Advanced
d.	Encryption: aes128
e.	Authentication: sha1
f.	Select Enable Replay Detection
g.	Select Perfect Forward Secrecy
h.	DH Group: 2 ! and deselect 5
i.	Keylife: 3600 seconds
j.	Enable Auto-negotiate   ! Autokey Keep Alive is enabled automatically when Auto-negotiate is enabled
k.	Click Ok

Se tudo correu bem temos esta tela

Agora vamos criar mais um Tunnel, mas as informações do .txt, para o Tunnel 02

Temos as seguintes configurações para o Tunnel02

New VPN Tunnel Window Appears (Here we configure the VPN settings):

New VPN Tunnel Window Appears (Here we configure the VPN settings):

Under “Network” Section:
a. IP Version:     IPv4
b. Remote Gateway: Static IP Address
c. IP address: 54.232.159.40
d. Local Interface: wan1
e. Local Gateway: Select Specify and enter WAN port IP (Public IP)
f. Dead Peer Detection: Enable by selecting On Idle/ On Demand
g. Authentication Method: Pre-shared Key
h. Pre-Shared Key: AVxMUvS1A1GuxDVcJxm_K28O67CthcZU
i. IKE Version: 2
Phase 1 Proposal:
j.  Encryption: aes128
k. Authentication: sha1
l. DH group: 2     ! and deselect 5
m. Keylife: 28800 seconds

! NAT Traversal is enabled by default but if your FortiGate device is not behind a NAT/PAT device, please deselect NAT Traversal.

! --------------------------------------------------------------------------------
! #2: IPSec Configuration

Under Phase 2 Selectors --> New Phase 2
a.	Name:  vpn-04ec6648c35364924-1
b.	Local Address: LAN subnet behind Fortigate/0.0.0.0/0
c.	Remote Address: AWS Private Subnet/0.0.0.0/0

Under Advanced
d.	Encryption: aes128
e.	Authentication: sha1
f.	Select Enable Replay Detection
g.	Select Perfect Forward Secrecy
h.	DH Group: 2 ! and deselect 5
i.	Keylife: 3600 seconds
j.	Enable Auto-negotiate   ! Autokey Keep Alive is enabled automatically when Auto-negotiate is enabled
k.	Click Ok

Se tudo correu bem até aqui teremos esse resultado.

Agora vamos criar uma Zona chamada Trust-Cloud, em Network, Interfaces, Create new, Zone

Adicione os dois Tunneis para AWS

Se tudo correu bem teremos

Agora voltando em nosso .txt, vamos começar a configurar o BGP.

Nos temos essa configuração a fazer nas interfaces VPN que criamos


Go to Network Tab --> Interface --> wan1 and edit TunnelAWS01

a. IP : 169.254.92.86
b. Remote IP: 169.254.92.85/30
c. Select Ping
d. Administrative Status: Up
e. Select Ok.

## Vamos fazer a configuração da Interface via CLI do Fortigate
#Configurar interfaces para sessão BGP

config system interface
    edit TunnelAWS01
        set ip 169.254.92.86 255.255.255.255
        set remote-ip 169.254.92.85 255.255.255.252
    next

!You can set MTU and MSS on the tunnel by performing this from the CLI:
 
 config system interface
  edit "TunnelAWS01"
    set mtu-override enable
    set mtu 1427
    set tcp-mss 1379
   next
end

Resultado, edit a interface e habilite o ping (repita isso na segunta interface)

Configurando MTU (Repita isso na segunda interface)

Agora repita os passos para a segunda interface

Vamos utilizar as informações que constam no .txt que foi feito download

Go to Network Tab --> Interface --> wan1 and edit TunnelAWS02

a. IP : 169.254.31.218
b. Remote IP: 169.254.31.217/30
c. Select Ping
d. Administrative Status: Up
e. Select Ok.

#Configurar interfaces para sessão BGP

config system interface
    edit TunnelAWS02
        set ip 169.254.31.218 255.255.255.255
        set remote-ip 169.254.31.217 255.255.255.252
    next

!You can set MTU and MSS on the tunnel by performing this from the CLI:
 config global
 config system interface
  edit "vpn-08d53f64bc31f682f-1" ! This name will be the same as the VPN tunnel name
    set mtu-override enable
    set mtu 1427
    set tcp-mss 1379
   next
end

Edit a interface e habilite o ping

Se tudo correu bem até aqui, teremos esse resultado.

Agora vamos criar as regras de Firewall, aqui iremos fazer simples, Any –> AWS e Any –> OnPremises.

Vamos criar via CLI que é muito mais rapido

#Criar regras de firewall

config firewall policy
    edit 1
        set name allow-gcp-to-lan
        set srcintf Trust-Cloud
        set dstintf Trust
        set srcaddr all
        set dstaddr all
        set action accept
        set schedule always
        set service ALL
    next
    edit 2
        set name allow-lan-to-gcp
        set srcintf Trust
        set dstintf Trust-Cloud
        set srcaddr all
        set dstaddr all
        set action accept
        set schedule always
        set service ALL
end

Se tudo correu bem nos temos ida e volta

Agora nossos Tunneis devem estar UPs, vamos conferir

Agora vamos para nossa configuração BGP no Fortigate

Voltamos lá no nosso .txt que foi baixado com as configurações, lá nos temos todas as informações necessária para configurar o BGP.

#Vamos utlizar a informação que consta no .txt

Go to Network --> BGP

#Primeira interface

 a. Local-AS : 65010
 b. Router-ID: 191.232.210.141
 c. Click Apply
 d. Neighbor -> Create New:
      1. IP:  169.254.92.8
      2. Remote AS: 64530
      3. Click Add/Edit

#Segunda interface

Go to Network --> BGP

 d. Neighbor -> Create New:
      1. IP:  169.254.190.113
      2. Remote AS: 64530
      3. Click Add/Edit

Agora vamos declara nosso CIDR para o BGP

Se tudo correu bem até aqui, devemos ter esse

Agora que os dois Tuneis estão UPs

Agora vamos ver nosso roteamento
Vemos que nossa rota BGP aparece em nossa tabela (rede AWS)

Agora de volta a AWS, vamos verificar nossa tabela de routa e Security Group

Liberamos em nosso SG a rede 10.5.0.0/22

Agora vamos ver nossa tabela de rotas

Nossa rota foi propagada com sucesso, vamos testar a conectivdade

Em nossa rede 10.5.0.0/22 conseguimos chegar na rede 10.128.0.0/24

Agora vamos ver em nossa rede AWS 10.128.0.0/24 se conseguimos chegar na rede 10.5.0.0/22

Com isso concluimos este artigo, em um próximo artigo irei fazer a conexão utilizando “Transit Gateway” com redes em Sao Paulo e Virginia utilizando somente uma conexão VPN IPSec.

VPN IPSec AWS e Azure com Fortigate (Peering Vnet)

Temos os seguintes objetos neste cenario:
Azure –> Ambiente Fortigate em HA e vnet dedicada, ambiente “File Exchange” (Troca de arquivos) com vnet dedicada com peering, dois arquivos Route Table.
AWS –> VPC, EC2,CG,VGW,CON.

Neste cenario iremos criar uma VPN IPSec entre AWS e Azure (sei que é possível utilizar os objetos das próprias clouds, mas neste cenário iremos utilizar Fortigate no Azure), vamos botar a mão na massa.

Para criar o ambiente do Fortigate com Vnet dedicada, iremos utilizar este artigo que escrevi há um tempo atrás “clique aqui”.

Ambiente Azure com Fortigate HA e Vnet dedicada.

Agora vamos ao nosso ambiente de “File Exchange”
Este ambiente é composto por uma VM Windows Server 2016, com software de trocas de arquivos tradicionais (SFTP, CD-IBM, SMB (Este com DFS)).
Então temos a vnet 10.128.10.0/24 conecta via peering com a vnet do firewall 10.126.0.0/24.

Ambiente “File Exchange” Azure

Agora vamos ao nosso ambiente na AWS:
Temos uma VPC “172.28.0.0/16”
Temos uma Subnet “172.28.31.0/24”
Temos nosso servidor File Exchange “172.28.31.77”

Agora vamos as configurações, vamos inciar pela AWS (Lembrando que este é apenas um cenário que muitas empresas possuem, este artigo não significa que esta certo ou errado.)
Vamos começar criando uma VPC na AWS.

Em “VPC” “Criar VPC”

nome da VPC “vpc-sao-paulo-bo”
CIDR IPv4 “172.28.0.0/16

Não iremos utilizar “Tags” clique em “criar”

Agora temos nossa VPC criada


Vamos agora criar nossa Subnet, em “subnets”, “Criar Subnets”

Nome “Private”
CIDR IPV4 “172.28.31.0/24”

Agora criaremos nossa VM (Windows Server 2016) nesta VPC e Subnet (Não irei mostrar aqui como criar uma EC2 na AWS)

Com nossa EC2 criada, vamos criar uma tabela de roteamento.
Em “Route Table” “Criar Tabelas de Rotas”
Nome “rt-subnet-bo-private”
VPC “vpc-sao-paulo-bo”

Temos nossa tabela criada

Veja que só temos route 172.28.0.0/16, ainda não temos route para nossa VPN, não será criar essa rota de forma manual, pois iremos habilitar a “propagação de rotas”, mas isso depois de criarmos nossos objetos para conexão de nossa VPN IPSec. Agora vamos associar nossa subnet privada nesta tabela de roteamento, “Associação de sub-rede” “Editar Associação de sub-rede”

Marque nossa subnet private e clique em salva

Pronto agora nossa subnet esta associada, com isso qualquer rota propagada ja estará disponivél neste subnet

Agora vamos criar nossos objetos de VPN IPSec

Em Virtual Private Network (VPN), Customer Gateways “Create Customer Gateways”

Name “cgw-peer-azu-fortigate”
IP Address “XXX.XXX.XXX.XXX” IP do nosso Load Balance do nosso Fortigate no Azure

Agora vamos criar nosso VGW, em Virtual Private Network (VPN)

vamos em “Create Virtual Private Gateway”

Name “vgw-aws-sao-paulo
ASN “Amazon Default ASN” podemos deixar assim mesmo, pois neste exemplo iremos utilizar Static Route


Agora vamos anexar nossa VPC em nosso VGW

Selecione o VGW criada, depois “Actions” Attach VPC”

Selecione a VPC que criamos “vpc-sao-paulo-bo”

VGW criado e VPC anexada

Agora vamos criar nossa conexão

Em “Virtual Private Network (VPN), “Site-to-Site VPN Connections”

Criar conexão

Agora aqui, muita atenção pois se ficar errado aqui a VPN não irá funcionar

Tag “con-azure-fortigate”
Target Gateway Type “Virtual Private gateway” escolha o que criamos na lista supensa
Gateway do Cliente “Existente” Selecione o que criamos
Opção de Roteamento “Estatico” pois neste exemplo não iremos utilizar BGP
Prefixo “10.128.10.0/24” a rede de comunição do Azure
Versão IP “IPv4”
CIDR de rede IPV4 local “10.128.10.0/24” aqui é a rede do azure não a rede AWS
CIDR de rede IPV4 remoto “172.31.0.0/16” aqui é a rede da AWS e não do Azure

As outras opções deixem como esta e clique em criar

Após alguns minutos (em média 10 minutos)

Aguarde até ficar disponivel

Com nossa conexão disponível

Podemos ver as configurações

O Tunnel ainda esta “DOWN” , pois ainda não criamos do lado do azure

Nossa rota estatica

Agora vamos em nosso ambiente Azure

Com disse no inicio deste post, não vou me aprofundar na criação do ambiente do Fortigate, pois o mesmo foi criado neste post já, utilizaremos a mesma infraestrutura para este artigo.

Depois de nossa infraestrutura de fortigate criada:

Vamos criar agora para nossa infra de “Fila Exchange”

Temos os seguintes objetos no ambiente de “File Exchange” no Azure

Resource Group “rg-file-exchange-brazilsouth” “10.128.10.0/24”
Virtual Network “vnet-file-exchange-brazilsouth” “10.128.10.0/26”
Subnet “snet-file-exchange-brazilsouth”
Virtual Machine “BRAZUFE01” “Neste post ensino como criar Windows Server”

Vamos criar o peering entre a vnet do ambiente do “File Exchange” e do “Fortigate”

Agora vamos as rotas

Em nosso arquivo/objeto no Azure “Route Table” “rt-fw-edge-shared-brazilsouth-internal”
vamos criar a rota para AWS

Assim ficará nosso roteamento

Route AWS

Agora vamos associar nossas snet

Temos que associar as seguintes subnet

snet-fwedge-shared-brazilsouth-Protected 10.126.0.128/27 (SNET dedicada para VMs)
snet-fwedge-shared-brazilsouth-Internal 10.126.0.32/27 (Snet interna do Fortigate)
snet-file-exchange-brazilsouth-01 10.128.10.0/26 (snet do ambiente do “File Exchange”

Agora com nosso roteamento pronto, vamos as configurações no Fortigate.

Mas para isso precisamos voltar na AWS, em VPN

Em Site-To-Site Connection clique selecione nossa conexão criada e depois “fazer download das configurações” em nosso exemplo selecione Fortigate, Fortigate 40+ Series, FortiOS 6.4.4, Ikev2

Fazer download

Com o arquivos de configuração em mãos

Vamos ao fortigate, em VPN, IPSec Tunnels

Create New -> IPSec Tunnel

Custon, TunnelAWS01

No arquivo que foi feito downoad, temos todas as informações necessário que precisamos para estabelecer as Phase1 e Phase2 da VPN

Temos o Peer “xxx.xxxx.xxxx.xxx
Temos a PSK “xxxxxxxxxxxxxxxxxxxxx”
Versão do IKE “V2”

i. IKE Version: 2
Phase 1 Proposal:
j. Encryption: aes128
k. Authentication: sha1
l. DH group: 2 ! and deselect 5
m. Keylife: 28800 seconds

Under Phase 2 Selectors –> New Phase 2
a. Name: vpn-0179c76477325e5f9-0
b. Local Address: LAN subnet behind Fortigate/0.0.0.0/0
c. Remote Address: AWS Private Subnet/0.0.0.0/0

Under Advanced
d. Encryption: aes128
e. Authentication: sha1
f. Select Enable Replay Detection
g. Select Perfect Forward Secrecy
h. DH Group: 2 ! and deselect 5
i. Keylife: 3600 seconds
j. Enable Auto-negotiate ! Autokey Keep Alive is enabled automatically when Auto-negotiate is enabled
k. Click Ok

Com o Tunnel criado, vamos as rotas

Vamos em network, static routes

Create New

Destination “172.28.0.0/16” Rede AWS
Interface “TunnelAWS01” Nome que demos para nosso Tunnel

Agora vamos criar o roteamento dentro do Fortigate para nossa vnet 10.128.10.0/24 eu que temos um peering

Em Network, Static Route, Create New

Destination “10.128.10.0/24
gateway “10.126.0.33” (Gateway da Snet Azure)
Clique em “OK”

Agora em Interface/Create Zone

Name “ZoneCloud”
Interface “TunnelAWS01”, clique em OK

Agora vamos criar nossas regras de firewall

Em “Policy and Objetics” “Firewall Policy”

Create New

Name “Trust-to-ZoneCloud”
Incoming interface “Trust(port2)
Outgoing interface “ZoneCloud”
Source “All” (Somente para este exemplo deixaremos tudo liberado)
Destination “All” (Somente para este exemplo deixaremos tudo liberado)
Schedule “Always”
Service “All” (Somente para este exemplo deixaremos tudo liberado)
Action “Accept”
Inspection Mode “Flow-Based”
Nat “Disable”
Application Control “Default”
Log Allowed traffic “All Sessions”
Clique em “OK”

Neste momento nosso Tunnel IPSec ja encontra-se estabelecido

Nosso roteamento encontra-se ativo

AWS também encontra-se com o Tunnel Ativo

Na AWS vamos em VPC, Route Table

Vamos olhar nosso arquivo de roteamento

“rt-subnet-bo-private”

Podemos observar que nossa rota para Azure ja encontra-se propagada

Agora vamos a um teste basico, na nossa VM no Azure “BRAZUFE01”

vamos executar um ping para nossa VM de File Exchange que encontra-se na AWS

Temos resposta de nosso ping

Em nosso Fortigate temos respostas também.

Após este testes, podemos executar as instalação de nossos softwares de “File Exchange” normalmente, pois nossos ambientes que estão no Azure e na AWS ja possuem conectividade completa, após isso podemos refinar nossas regras de firewall para permitir somente o trafego necessário entre os ambientes.

E assim ficou nossa topologia

Espero ter ajudado.

*Obs: Para o sucesso desta conexão é imprescindível se atentar aos seguintes passos:

1º) Ao criar a conexão de VPN na AWS quando for informar a rede local (rede do cliente remoto) e rede remota (rede AWS).
2º) Lembre que habilitar a propação de rotas no arquivo de Route Table na AWS, desta forma você não precisa ficar criando routas de forma manual.
3º) Não esquece de liberar dentro do “SG” as redes remotas (aqui as redes do Azure)
4º) Na Route Table do Azure, sempre add as Subnet onde irão receber as conexão para o Firewall, neste exemplo a Snet Internal
5º) Sempre criar as rotas no arquivo Route Table do Azure (Fortigate), ele precisa saber para onde deve mandar o pacote (Sim no arquivo Route Table precisa ter a informação da rota, pois se não tiver, não chega o pacote no firewall)
6º) Se for necessário ter outra arquivos Route Table no azure, deve-se anexar a snet que receberá as rotas e a rota em sim definida, (Neste exemplo com dois arquivos Route Table no azure, os dois devem conter as rotas explicitas)

Seja Feliz!!!!

DEPLOY Fortigate HA AZURE CLI (BASH) TEMPLATE ARM

Neste post iremos fazer o deploy de Fortigate (Version 7) em HA (Active/Passive) “Load Balance (ELB/ILB)”, utilizando um template modificado fornecido pela prória fortigate (adequado as preferencias para este artigo de exemplo).
Nesta topologia/arquitetura de rede colocamos o Fortigate EDGE para ser a rota default de todas as nossas vnets que estão no azure, com isso toda entrada ou saida de dados passa obrigatóriamente pelo Fortigate EDGE, essa arquitetura não esta certa nem errada, tudo vai depender do compliance de cada empresa, time de segurança, time de rede e claro do orçamento de cada um. Lembra muito o artigo que escrevi sobre Palo Alto

No final vou deixar os arquivos para download e algumas explicações sobre os arquivos .json

Uma breve explicação.

Vamos aos objetos criados no azure

Resource Group
rg-fw-edge-shared-brazilsouth

NAMETYPELOCATION
fwedge01_OsDisk_1_8e3e21f33b774e919ba304a2ec8a3b62DiskBrazil South
fwedge01_disk2_5e1d09faa5fa446eb56329f30ce3ff51DiskBrazil South
fwedge02_OsDisk_1_cbedf98d06474b009df9c9c13b972f55DiskBrazil South
fwedge02_disk2_c8449694114e4b849123c6f93103624fDiskBrazil South
elb-fwedge-01Load balancerBrazil South
ilb-fwedge-01Load balancerBrazil South
int-fwedge01-eth0Network interfaceBrazil South
int-fwedge01-eth1Network interfaceBrazil South
int-fwedge01-eth2Network interfaceBrazil South
int-fwedge01-eth3Network interfaceBrazil South
int-fwedge02-eth0Network interfaceBrazil South
int-fwedge02-eth1Network interfaceBrazil South
int-fwedge02-eth2Network interfaceBrazil South
int-fwedge02-eth3Network interfaceBrazil South
nsg-fwedge-sharedbrazilsouthNetwork security groupBrazil South
pip-fwedge-mgmt-aPublic IP addressBrazil South
pip-fwedge-mgmt-bPublic IP addressBrazil South
pip-lb-external-fwedge-01Public IP addressBrazil South
rt-fw-edge-shared-brazilsouthRoute tableBrazil South
fwedge01Virtual machineBrazil South
fwedge02Virtual machineBrazil South
vnet-fwedge-shared-brazilsouthVirtual networkBrazil South

Discos

Temos dois discos em cada Fortigate VM:
DiskOS 2GB SSD Premium
DiskDATA 30GB SSD Premium

Teremos uma VNET “vnet-fwedge-shared-brazilsouth” com as seguintes subnets (snets)

NameCIDR
snet-fwedge-shared-brazilsouth-External10.126.0.0/27
snet-fwedge-shared-brazilsouth-Internal10.126.0.32/27
snet-fwedge-shared-brazilsouth-HASync10.126.0.64/27
snet-fwedge-shared-brazilsouth-Management10.126.0.96/27
snet-fwedge-shared-brazilsouth-Protected10.126.0.128/27
snet-fwedge-shared-brazilsouth-LoadBalance10.126.0.160/27

Temos 4 interfaces de rede para cada VM

Interface NameVM AttachSnet NameIP IntCIDR
int-fwedge01-eth0fwedge01snet-fwedge-shared-brazilsouth-External10.126.0.510.126.0.0/27
int-fwedge01-eth1fwedge01snet-fwedge-shared-brazilsouth-Internal10.126.0.3710.126.0.32/27
int-fwedge01-eth2fwedge01snet-fwedge-shared-brazilsouth-HASync10.126.0.6910.126.0.64/27
int-fwedge01-eth3fwedge01snet-fwedge-shared-brazilsouth-Management10.126.0.10110.126.0.96/27
int-fwedge02-eth0fwedge02snet-fwedge-shared-brazilsouth-External10.126.0.610.126.0.0/27
int-fwedge02-eth0fwedge02snet-fwedge-shared-brazilsouth-Internal10.126.0.3810.126.0.32/27
int-fwedge02-eth0fwedge02snet-fwedge-shared-brazilsouth-HASync10.126.0.7010.126.0.64/27
int-fwedge02-eth0fwedge02snet-fwedge-shared-brazilsouth-Management10.126.0.10210.126.0.96/27

Temos dois Load Balances

1x Internal Load Balance (ilb-fwedge-01) IP: 10.126.0.190
1x External Load Balance (elb-fwedge-01) IP: XXX.XXX.XXX.XXX

Temos 1 NSG (Network Security Group) (snet-fwedge-shared-brazilsouth-03 “Management”)

1x “nsg-fwedge-shared-brazilsouth-mgmt” com as seguintes regras

Allow-MGMT-HTTPS/SSH
Source: XXX.XXX.XXX.XXX/XX (IP ou IPs de origem que podem se conectar na interface MGMT)
Destination: 10.126.0.96/24 (Rede de gerencia MGMT)

Temos 3 IPs Publicos

pip-fwedge-mgmt-a (Management Fortigate A)
pip-fwedge-mgmt-b (Management Fortigate B)
pip-lb-external-fwedge-01 (IP Publico External Load Balance)

Temos 2 Virtual Machines

fwedge01 (Standard_F8s – 8vCPUs, 16 GB Memory)
fwedge02 (Standard_F8s – 8vCPUs, 16 GB Memory)

Temos um arquivo de Route Table “rt-fw-edge-shared-brazilsouth”, nele temos as seguintes rotas:

NameCIDRNext Hop typeNext Hop IP address
DefaultRoute0.0.0.0/0VirtualAppliance10.126.0.190

Agora vamos ao nosso script

#!/bin/bash
##Declarando variaveis

##Declarando Variaveis (Obrigatório)
export Subscription_Name="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" ##inserir sua Subscription Azure
export RG_Name02="rg-fw-edge-shared-brazilsouth"
export Location_Region="brazilsouth"

###Script
###Selecionar subscription
az account set --subscription "${Subscription_Name}"

##Criando RG
az group create -n "${RG_Name02}" -l "${Location_Region}"

##Deploy Fortigate Template
az deployment group create -g "${RG_Name02}" --template-file template.json --parameters @parametersFile.json

##Desligando VMs
az vm stop -g "${RG_Name02}" -n "fwedge01"
az vm stop -g "${RG_Name02}" -n "fwedge02"

##Deallocate
az vm deallocate -g "${RG_Name02}" -n "fwedge01"
az vm deallocate -g "${RG_Name02}" -n "fwedge02"

###Criando Storage Accout (Para boot diag)
az storage account create -g "${RG_Name02}" -n "stgdiagfwedgefgt01" -l "${Location_Region}" --sku "Standard_LRS"

##Criando Snet Internal Load Balance (Subnet para load balance interno)
az network vnet subnet create -g "${RG_Name02}" --vnet-name "vnet-fwedge-shared-brazilsouth" -n "snet-fwedge-shared-brazilsouth-LoadBalance" --address-prefixes "10.126.0.160/27"

##alterando IP Internal Load Balance
az network lb frontend-ip update -g "${RG_Name02}" --lb-name "ilb-fwedge-01" -n "frontend-fwedge-internal-01" --vnet-name "vnet-fwedge-shared-brazilsouth" --subnet "snet-fwedge-shared-brazilsouth-LoadBalance" --private-ip-address "10.126.0.190"

###Habilitando Boot dioag VM01/02
az vm boot-diagnostics enable -n "fwedge01" -g "${RG_Name02}" --storage "stgdiagfwedgefgt01" 
az vm boot-diagnostics enable -n "fwedge02" -g "${RG_Name02}" --storage "stgdiagfwedgefgt01" 

##Fixando IP eht0 (VM01/02)
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge01-eth0" -n "ipconfig1" --private-ip-address "10.126.0.5"
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge02-eth0" -n "ipconfig1" --private-ip-address "10.126.0.6"

###Fixando IP eth1 (VM01/02)
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge01-eth1" -n "ipconfig1" --private-ip-address "10.126.0.37"
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge02-eth1" -n "ipconfig1" --private-ip-address "10.126.0.38"

###Fixando IP eth2 (VM01/02)
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge01-eth2" -n "ipconfig1" --private-ip-address "10.126.0.69"
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge02-eth2" -n "ipconfig1" --private-ip-address "10.126.0.70"

###Fixando IP eth3 (VM01/02)
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge01-eth3" -n "ipconfig1" --private-ip-address "10.126.0.101"
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge02-eth3" -n "ipconfig1" --private-ip-address "10.126.0.102"

###Anexando NSG MGMT a snet mgmt 
az network vnet subnet update -g "${RG_Name02}" -n "snet-fwedge-shared-brazilsouth-Management" --vnet-name "vnet-fwedge-shared-brazilsouth" --network-security-group "nsg-fwedge-shared-brazilsouth-mgmt"

###Deletando regras existentes (criadas pelo templete, pode-se alterar diretamente no template tb)
az network nsg rule delete -g "${RG_Name02}" --nsg-name "nsg-fwedge-shared-brazilsouth-mgmt" -n "AllowAllInbound"
az network nsg rule delete -g "${RG_Name02}" --nsg-name "nsg-fwedge-shared-brazilsouth-mgmt" -n "AllowAllOutbound"

##Criando regras NSG MGMT HTTPS
az network nsg rule create -g "${RG_Name02}" --nsg-name "nsg-fwedge-shared-brazilsouth-mgmt" -n "Allow-MGMT-HTTPS" --priority "100" \
--source-address-prefixes "179.215.182.42/32" --source-port-ranges "*" \
--destination-address-prefixes "10.126.0.96/27" --destination-port-ranges "443" --access "Allow" \
--protocol "TCP" --description "Acesso liberado a snet management"

##Alterando regras NSG MGMT SSH
az network nsg rule create -g "${RG_Name02}" --nsg-name "nsg-fwedge-shared-brazilsouth-mgmt" -n "Allow-MGMT-SSH" --priority "101" \
--source-address-prefixes "179.215.182.42/32" --source-port-ranges "*" \
--destination-address-prefixes "10.126.0.96/27" --destination-port-ranges "22" --access "Allow" \
--protocol "TCP" --description "Acesso liberado a snet management"

###Anexando Subnet Internal a Route Table
az network vnet subnet update -g "${RG_Name02}" -n "snet-fwedge-shared-brazilsouth-Internal" --vnet-name "vnet-fwedge-shared-brazilsouth" --route-table "rt-fw-edge-shared-brazilsouth-internal" 

###Inciando as VM01/02
az vm start -g "${RG_Name02}" -n "fwedge01"
az vm start -g "${RG_Name02}" -n "fwedge02"

Agora tudo pronto, vamos acessar nosso FGT, iremos acesso pelo IP Publico “pip-fwedge-mgmt-a”

Entre com usuário e senha que contas no template

Vamos as configurações iniciais

Clique em “Begin”
Clique em “ok”
Clique e “ok”

Temos nosso Dashbord inicial

Vamos verificar nosso HA Sync

Vamos em System / HA

Tudo certo

Vamos agora em “Network” “Static Routes”

Por padrão teremos essas rotas (Isso pode ser editado/alterado no template)

Vamos fazer algumas modificações e deixar desta forma

Basicamente, iremos remover a rota “168.63.129.16/32” “10.126.0.1” “port1”

Ficará desta forma

Toda e qualquer nova rede que for criar e for feito peering com a rede do Firewall-EDGE 10.126.0.0/24 teremos que criar a “Static Route”

Vamos a um exemplo, em nosso ambiente azure temos a Vnet “10.188.0.0/24”, iremos fazer um peering com ela e add route static no FGT.

Sempre usaremos a port2, pois ela é nossa “LAN-Trust”, o gw 10.126.0.33 é o gw do azure (já expliquei em outros posts como funciona a rede no azure, que ele guarda para si os 3 primeiros IP de cada subnet)
Agora nossa Static Route ficará desta forma

Vamos agora criar um regra de acesso a internet
“Policy & Objects” “Firewall Policy”

Create New

Clique em “ok”

Agora nos temos uma regra que vem da nossa interface “LAN-Trust” para a nossa interface “WAN-UnTrust”

Agora vamos add essa vnet/subnet ao nosso Route Table

Assim ficou nosso arquivo

**(Esta vnet tem que possui peering com nossa rede do firewall edge)

Vamos ao teste

Criamos a seguinte vm “vm-lan-trust-01”
subnet 10.188.0.0/26
IP: 10.188.0.4

Estamos dentro da nossa VM Trust

vamos fazer um teste de curl para http//ifconfig.me e monitor em nosso firewall

Como podem ver em nossa VM Trust, trouxe o IP da interface WAN-UnTrust e todo trafego passou pelo nossa firewall

Agora um outro cenário, temos parceiros/clientes que precisam acessar nossas aplicações ou um ambiente de “Transfer” (Connect Direct IBM, SFTP, FTPS, SMB) para isso acontecer de forma segura podemos estabelecer Tuneis IPSec com nossas Parceiros/Clientes e desta forma liberar o acesso de forma segura.
Outra cenario seria a publicação de uma aplicação interna e expo-la para internet, temos varias possibilidade de forma segura em nossa ambiente.

Agora algumas explicações referente aos .json

Linha 5/6: usuário de acesso ao firewall
Linha 8/9: senha
Linha 12: prefixo do firewall
Linha 15: versão do licenciamento, neste exemplo seria PayAsGo (Pague pelo uso, se vc possui BYOL, altere para o valor que consta no template)
Linha 18: ultima versão do firmware
Linha 21: Size VM
Linha 36: nome do IP Publico do External LB
Linha 39: RG
Linha 42: IP Publico MGMT FGT A
Linha 45: RG
Linha 48: IP Publico MGMT FGT B
Linha 51: RG

Continuando

Linha 57: nome da vnet (o proprio template cria a vnet)
Linha 60: RG
Linha 63: CIDR da Vnet
Linha 66: Nome da Vnet External
Linha 69: CIDR da Subnet External

As outras são auto explicativas

***Nunca esquecer de add Static Route em nosso firewall, sempre add as subnet no arquivo Route Table, sempre fazer peering para novas Vnets.

Link para download

Seja Feliz!!!!!!!!!!!!!!!!!

Infraestrutura de rede (Vnet) com Azure Firewall na Borda.

Neste artigo venho apresentar uma topologia utilizando Cloud Azure, com 7 Vnets ligadas por peering, gateway de VPN com BGP e Azure Firewall.

Nesta topologia todas as subnets estão com route table 0.0.0.0/0 para o IP da interface do nosso Azure Firewall

0.0.0.0/0 –> 10.128.0.68

Desta maneira temos total segregação da rede (Azure Vnet), onde cada projeto/departamento tem sua propria vnet.
Desta forma a vnet por exemplo do RH não fala com a Vnet de Marketing (Somente se for criada regras de Firewall) e o porque de utilizar desta forma.

Na minha visão tem que ser “cada um no seu quadrado”, não porque estamos em cloud que esse pensamento deve mudar, desta maneira tornamos nosso ambiente mais seguro, protegemos nossas cargas de trabalhos, deixamos cada ambiente totalmente isolado, segredado e seguro.

Na borda nos temos Azure Firewall com default route, onde ele controla tudo que entra e sai da nossa rede.

Topologia Azure Firewall

Exemplos de regras na pratica

Temos nesta topologia dois servidores de DNS (Windows Server 2019):

AZUEASTDNS01 e AZUEASTDNS02 (dentro do dominio glbx.corp)

AZUEASTDNS01.glbx.corp (10.128.8.4)
AZUEASTDNS02.glbx.corp (10.128.9.4)

Esses servidores são os DNS Server padrão de todas as nossas vnets

Veja como ficaria a regra de Azure Firewall para que toda “Resolução de Nomes” seja liberada: (Neste exemplo não estamos utilizando Firewall Manager)

Foi criada a seguinte regra

Name: dns vnet resoler
Protocol: TCP/UDP
Source: 10.128.0.0/16 (Estou utilizando este CIDR neste exemplo)
Destination Address: 10.128.8.4,10.128.9.4 (Nossos servidores DNS)
Destination Port: 53

Firewall Rule DNS Vnet

Conforme regra criada acima, todas as vnet que estão fazendo peering, e com route default 0.0.0.0/0 para o IP no nosso Azure Firewall, iram conseguir resolver nomes utilizando nossos servidores DNSs.

Vamos a outro exemplo pratico.

Em nosso ambiente temos dois servidores web (Windows Server 2019 com IIS) que hospeda a intranet da empresa, na frente deste servidores temos um load balance fazendo o balanceamento da carga, que possui o IP 10.128.11.196

Para os colaboradores acessarem a infraestrutura da empresa, existe uma VPN IPSec com BGP comunicando o ambiente OnPremises e o ambiente do Azure

A regra para liberar o acesso dos colaboradores ao nosso ambiente “intranet” seria assim:

Name: acesso rede interna – intranet
Protocol: TCP
Source: 10.127.0.0/22 (Este CIDR é da rede OnPremises)
Destination Address: 10.128.11.196 (IP do Load Balance)
Destinaton Port: 80/443

Nossos colaboradores seguiram este caminho

Notebook –> Firewall OnPremises –> Rota BGP –> Gateway Azure –> Route Default Azure –> Azure Firewall –> IP do Load Balance

Nossa intranet utiliza banco de dados Azure Database SQL (PaaS), para este modelo criamos um Azure Database SQL (PaaS) com private link e bloqueamos totalmente o acesso externo (Internet) ele só é acessivel via rede interna.

Link para utilização de private link com DNS Personal (Neste exemplo utilizamos desta forma)

https://docs.microsoft.com/pt-br/azure/private-link/private-endpoint-dns

Regra de Firewall

Name: acesso rede interna – intranet
Protocol: TCP
Source: 10.128.10.4,10.128.11.4
Destination Address: 10.128.4.10 (IP do Private Link que criamos)
Destinaton Port: 1433

Com esta regra nossa aplicação “intranet” conseguirá acessar o banco de dados PaaS via rede interna.

Outro exemplo pratico, neste cenário iremos expor uma aplicação para internet

Iremos expor nosso Site Institucional para a internet, temos este ambiente

Frontend: Application Gateway com IP Privado, peering com nossa vnet master, porém na subnet onde esta hospedado nossa application gateway não possui route default 0.0.0.0/0 para nosso AzureFirewall

Iremos utilizar o recurso de NAT para expor nosso site com destino um Appplication Gateway (não irei ensinar neste exemplo com criar/configurar um application gatewaY)

Name: acesso site institucional
Protocol: TCP
Source: * (qualquer lugar da internet)
Destination Address: 20.72.175.158 (IP previamente criado a atachado ao azure firewall)
Destinaton Port: 443
Translate Adress: 10.128.4.10 (IP privado do Application Gateway)
Translate Port: 443

Com a regra de firewall criada acima nosso site institucional ficará exposto para a internet com proteção de anti-DDoS do Azure que esta em nossa borda e por Application Gateway (WAF) na frente da aplicação.

Essa topologia não esta certa nem errada, eu acredito que é possivel deixar seu ambiente totalmente segredado, seguro, com um ponto unico de acesso e ainda conseguir utilizar todos os recurso do Azure de forma segura.

Bom é isso pessoal, fiquem a vontade para criticar/sugestionar

Outra coisa importante que se deve levar em conta, se no seu ambiente se faz necessário estabelecer comunicação com outras empresas, parceiros cliente etc….pense em utilizar a o proprio gateway de VPN BGP, porém pense que seu cliente da VPN IPSec não poderá utilizar a mesma rede que seu ambiente, neste exemplo o CIDR 10.128.0.0/16 e nem 10.127.0.0/22, para resolver essa questão você pode estabelecer a VPN IPSec em seu ambiente OnPremises e fazer o roteamento dos pacotes para seu ambiente no Azure (recomendo somente se não for critico, pois se seu ambiente OnPremises ficar indisponivel a VPN ficará também), outra solução seria criar um nova Vnet (Para deixar o ambiente segredado) e criar um Virtual Appliance como por exemplo “Fortigate” (Pode ser Palo Alto, SonicWall, PFSense), com a Vnet criada, faça o peering com a vnet master para propagação BGP, e NÃO deixe como rota default as subnets do fortigate para o AzureFirewall, depois disso bastas estabelecer o tunnel IPSec com seu parceiro e criar as devidas rotas na tabela de roteamento e as regras no Azure Firewall.

Autenticação FSSO AGENT Fortinet

Vamos neste post como instalar e configurar FSSO AGENT do Fortinet.

Veja o desenho abaixo

image

Primeiro passo fazer download do FSSO AGENT pelo site da http://support.fortinet.com ou diretamente neste link http://migre.me/jr1kJ

Segundo passo a instalação em um servidor com Active Directory (AD)
Vamos a instalação

Duplo clique no instalador

image

Next

image

Aceite os termos e clique em NEXT

image

Local de instalação, next

image

Usuário e senha do administrador do domínio

image

Deixe a tela de opção do jeito que está

image

Clique em Install

image

A instalação

image

Instalado com sucesso, vamos a configuração, habilite “Lanch DC Agente Install Wizard” depois Finish

image

Collector Agent IP address: IP do Servidor

Collector Agent listening port: 8002

Next

image

Selecione o domínio a ser monitorado e clique em Next

image

Nesta tela vamos escolher as configurações padrões
Para maiores informações veja http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/FSAE.036.11.html

Clique em Next

image

Pronto, agente instalado clique em “Finish”

Vamos configurar o Agent

Acesse no menu iniciar, Fortinet, Fortinet Sing On Agent, Configure Fortinet Single On Agent

image

A primeira alteração a ser feita é a autenticação do agente com o fortinet, vamos configurar uma senha neste exemplo [email protected]

image

Depois vamos ver as opções, “Select Domains To Monitor”

image

Habilite seu domínio, neste exemplo “GLBX\glbx.local” clique em OK

image

O Agente está fazendo as configurações

image

Agora clique em “Set Group Filters”

image

Clique em “Add…”

image

Clique em “Advanced”
image

Escolha os grupos a serem monitorados, neste exemplo ACCESS_FULL_INTERNET e ACCESS_RESTRICT_INTERNET, clique em Add

image

Marque a opção “Default filter” e clique em OK

image

Aqui você verá os grupos monitorados, clique em OK

image

Agente sendo configurado

Agora vamos salvar

image

Clique em “Salve&Close”

image

Agente sendo configurado e salvo

image

Um detalhe muito importante as portas 8000 e 8002 devem estar liberados no firewall do servidor para comunicação em o firewall e o servidor.

Pronto nosso agente está instalado e configurado, agora vamos configura-lo em nosso firewall.

No Firewall clique em User & Device, Authentication, Single Sign-On, Create New

 

image

Type: Fortinet Single-Sign-On Agent
Name: SRV-DC01
Primary Agent IP/name: IP de nosso servidor 10.174.1.3
Password: lembra que configuramos a senha no agent no servidor, neste exemplo [email protected]
Neste exemplo vamos usar somente um Agent FSSO, mas é recomendável pelo menos dois, caso um falha teremos outro para autenticação, mas neste exemplo iremos utiliza somente um.

image

Clique em “Apply & Refresh”

image

Agora veja que nosso agente já trouxe as informações de nossos grupos com acesso a internet, neste exemplo “ACCESS_FULL_INTERNET e ACCESS_RESTRICT_INTERNET”

Clique em ok.

image

Pronto agente configurado no Firewall

Agora vamos criar os grupos de acesso no firewall

Clique em “User & Device” User Group, Creat New

image

Name: SRV-DC01-FULL-ACCESS
Type: Fortinet Single Sign-On (FSSO)
Available Members: Veja que trouxe nosso grupos, vamos selecionar “GLBX/ACCESS_FULL_INTERNET” e clicar na seta para adicionar em Members, clique ok

image

image

Grupo criado, agora vamos criar o grupo de acesso restrito, creat new

Name: SRV-DC01-RESTRICT-ACCESS
Type: Fortinet Single Sign-On (FSSO)
Available Members selecione o grupo GLBX/ACCESS_RESTRICT_INTERNET e clique na seta para adicionar em Members, clique ok

image

image

Pronto agora temos nossos dois grupos de acesso a internet FULL e RESTRICT criados em nosso firewall

Agora vamos criar a politica de acesso

Em POLICY, Policy,Creat New

Primeira Etapa

Policy Type: Firewall
Policy Subtype: User Identity
Incoming Interface: port1 (LAN)
Source Address: Objeto criado coma range de nossa rede interna
Outgoing Interface: port3 (WAN1)
Enable NAT: Habilite

image

Agora vamos a segunda etapa, em “Configure Authentication Rules” Creat New”

Destination Address: all
Group: SRV-DC01-FULL-ACCESS (Grupo que tem acesso FULL a internet)
User: Click to ad… não utilizamos usuários específicos
Schedule: always
Service: ALL
Action: ACCEPT
Log Allowed Traffic: Deixe habilitado
Generate Logs when Session Starts: Deixe habilitado

image

Clique em OK

Agora vamos criar o acesso para os usuário do grupo RESTRICT

Creat New

Destination: all
Group: ACCESS_RESTRICT_INTERNET
User: Click to add… não estamos utilizando usuário específicos
Schedule: always
Service: HTTP, por ser restrito, deixemos somente HTTP port 80
Action: ACCEPT
Log Allowed Traffic: Deixe habilitado
Generate Logs when Session Starts

EM UTM Security Profiles, vamos habilitar “Web Filter” onde temos alguns sites bloqueados

image

Clique ok

Agora vemos nossas regras de autenticação criadas

image

Clique ok

image

Regras criadas

Vamos ao teste utilizando o usuário “vpmonteiro” que está no grupo acesso restrito

Bloqueamos estes sites para o grupo restrito

image

Vamos acessar uma maquina no domínio com o usuário “vpmonteiro”

image

Veja que o usuário está conectado em nosso firewall

image

Ao abrir o navegador, conseguimos acesso a internet normalmente

image

Vamos ver se o usuário está logado mesmo, acessando o FSSO AGENT no AD e clicando em Show Logon Users

image

Veja que o usuário “vpmonteiro” está conectado

image

Vamos ver se ele consegue acessar aqueles sites que bloqueamos acima

image

Veja que o ao acessar um site restrito o acesso foi bloqueado

Vamos tentar via HTTPS

image

Veja que não é acessado.

Logs do Fortinet

image

Agora vamos ver com o usuário “csantana” que não possui restrições

 

image

Veja que o usuário está logado

image

image

image

Veja que conseguimos acessar qualquer site normalmente

image

Veja que ao tentar acessar uma maquina fora do domínio ela não consegue acessar nenhum site

image

image

Agora vou deixar a politica de acesso a internet habilitada por LDAP e com já configuramos tudo no POST anterior veja

image

E se tentarmos autenticar com o usuário restrito “vpmonteiro”

O acesso a sites restritos continua normalmente

image

E veja os dois usuário logados um por LDAP e outro por FSSO

image

Seja Feliz!!!

Bloqueando arquivos executáveis para download e execução pelo navegador utilizando fortinet

Vamos bloquear o download de arquivos “.exe” pelo navegador

Acesso o Fortinet

Data Leak Prevention, File Filter

image

New File Filter Table

Name: Bloqueio .exe

OK

image

Agora em “Creat New”

image

Filter Type: Escolha “File Type”
File Type: Escolha “Executable (exe)

OK

image

APPLY

Filtro criado

image

Agora vamos em Sensor, em UTM Security Profiles, Sensor

 

image

Vamos criar um novo Perfil

image

Clique no sinal de “+”

Name: vamos dar um nome para o perfil, neste exemplo “Bloqueio .exe”

image

Agora em “Creat New”

Filter: Escolha “Files”
Filter Type included in “Bloqueio .exe” o que criamos em File Filter”
Examine the following Services: Vamos deixar somente “HTTP”
Action: Block
OK

image

APPLY

Teremos este:

image

O Perfil para bloquear arquivos .exe está criado, porém ainda não está funcionando pois não vinculamos ele a uma regra de acesso a internet em policy.

Ao acessar a URL “http://download.skype.com/bf94b0508d33d968c9200839f080e127/partner/59/SkypeSetupFull.exe

Conseguimos fazer o download do Skype normalmente

image

Agora vamos aplicar o filtro de bloqueio .exe na regra de acesso a internet

Vamos em “Policy” – Policy

EM “UTM Security Profiles” vamos habilitar “DLP Sensor” e escolher o perfil que criamos “Bloqueio .exe”

image

OK, pronto agora qualquer download ou execução de arquivos .exe pelo navegador será bloqueada.

image

Podemos em Monitor

image

Alterando mensagem de bloqueio de sites específicos Fortinet

Vamos alterar a mensagem de bloqueio de sites específicos do Fortinet, neste exemplo vamos colocar uma mensagem mais amigável para o usuário.

No fortinet, System, Config, Replace Message:

image

Escolha do lado direito “URL Block Page”

image

Ao selecionar a mensagem acima, você verá esta mensagem padrão:

image

Vamos editar o código fonte (você poderá usar qualquer editor de HTML ou editor de texto)

Está é a mensagem padrão

image

Este é o código fonte

==================================================================

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01//EN”>
<html>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>
<style type=”text/css”>
html,body{
height:100%;
padding:0;
margin:0;
}.oc{
display:table;
width:100%;
height:100%;
}.ic{
display:table-cell;
vertical-align:middle;
height:100%;
}div.msg{
display:block;
border:1px solid #30c;
padding:0;
width:500px;
font-family:helvetica,sans-serif;
margin:10px auto;
}h1{
font-weight:bold;
color:#fff;
font-size:14px;
margin:0;
padding:2px;
text-align:center;
background: #30c;
}p{
font-size:12px;
margin:15px auto;
width:75%;
font-family:helvetica,sans-serif;
text-align:left;
}
</style>
<title>
The URL you requested has been blocked
</title>
</head>
<body>
<div class=”oc”>
<div class=”ic”>
<div class=”msg”>
<h1>
The URL you requested has been blocked
</h1>
<p>
The page you have requested has been blocked, because the URL is banned.
<br />
<br />
URL = %%URL%%
<br />
%%OVERRIDE%%
</p>
</div>
</div>
</div>
</body>
</html>

===================================================================

Vamos editar agora

Alterei o titulo para:

<title>
Acesso a este site foi negado devido a politica de acesso a internet da organização SupportBrazil
</title>

===================================================================

Agora alteramos o titulo da mensagem que é exibida no navegador

<h1>
A página que tentou acessar está bloqueada de acordo com as politicas da organização SupportBrazil
</h1>
<p>

image

Agora vamos alterar a mensagem exibida

</h1>
<p>
A página que tentou acessar tem seu acesso bloqueado de acordo com a politica da organização SupportBrazil, se a página que está tentando acessar por favor crie um Ticket para equipe de TI informando a URL e motivo que ela deve ser desbloqueada para a organização ou entre em contato com o ramal 55555.<br />
<br />

 

image

Pronto veja como ficou o novo código fonte

==================================================================

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01//EN”>
<html>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>
<style type=”text/css”>
html,body{
height:100%;
padding:0;
margin:0;
}.oc{
display:table;
width:100%;
height:100%;
}.ic{
display:table-cell;
vertical-align:middle;
height:100%;
}div.msg{
display:block;
border:1px solid #30c;
padding:0;
width:500px;
font-family:helvetica,sans-serif;
margin:10px auto;
}h1{
font-weight:bold;
color:#fff;
font-size:14px;
margin:0;
padding:2px;
text-align:center;
background: #30c;
}p{
font-size:12px;
margin:15px auto;
width:75%;
font-family:helvetica,sans-serif;
text-align:left;
}
</style>
<title>
Acesso a este site foi negado devido a politica de acesso a internet da organização SupportBrazil
</title>
</head>
<body>
<div class=”oc”>
<div class=”ic”>
<div class=”msg”>
<h1>
A página que tentou acessar está bloqueada de acordo com as politicas da organização SupportBrazil
</h1>
<p>
A página que tentou acessar tem seu acesso bloqueado de acordo com a politica da organização SupportBrazil, se a página que está tentando acessar por favor crie um Ticket para equipe de TI informando a URL e motivo que ela deve ser desbloqueada para a organização ou entre em contato com o ramal 55555.<br />
<br />
URL = %%URL%%
<br />
%%OVERRIDE%%
</p>
</div>
</div>
</div>
</body>
</html>

==================================================================

Agora copie este novo código fonte e cole no fortinet em:

image

Veja como ficou

image

Clique em “Salve”

Agora vamos ver como ficou a nova mensagem de bloqueio

Está era a mensagem antiga

image

Agora a nova mensagem

image

Bloqueando sites específicos Fortinet

Vamos bloquear alguns sites específicos manualmente, neste exemplo não iremos utilizar categorização WEB na Fortinet.

Vamos lá, em UTM Security Profiles

image

Web Filter, URL Filter, Creat New

Name: neste exemplo vamos utilizar “RESTRICT”

OK

image

Agora em dentro de “RESTRICT” “Creat New”

URL: Neste exemplo vamos bloquear qualquer coisa .uol.com.br “*.uol.com.br”
Type: Wildcard (Utilizando esta opção, conseguimos bloquear *.domínio
Action: Block
Enable: Deixe habilitado.

OK

image

Agora vamos vincular ao profile em web filter, neste exemplo iremos bloquear para toda empresa *.uol.com.br

Em Web Filter, Profile, Default, Advanced Filter, habilite a opção “Web URL Filter” “RESTRICT”

Apply

image

Agora vamos criar um regra de acesso a internet

Em “Policy”, Police, Creat New

Policy Type: Firewall
Policy Subtype: Address
Incoming Interface: port1 (LAN)
Source Address: all
Outgoing Interface: port3 (WAN2)
Destination Address: all
Schedule: always
Service: ALL
Action: ACCEPT
Enable NAT: Deixe habilitada
Log Allowed Traffic: Deixe habilitada esta opção

Em UTM Security Profiles, habilite “Web Filter”, deixe no modo “ON” selecione o “Default” em profile

OK

image

Regra criada

image

Vamos fazer o teste e verificar se realmente está sendo bloqueado a URL que informamos.

Veja que o acesso a internet está normal

image

Agora vamos acessar o site www.uol.com.br

image

Agora vamos tentar acessar um site dentro do domínio uol.com.br, neste exemplo http://email.uol.com.br

O bloqueio ocorreu com sucesso.

image

Publicando SSH de forma segura com Fortinet (NAT)

Vamos fazer a publicação da porta 22 SSH para acessar a uma maquina Linux de forma segura passando pelo nosso Firewall Fortinet.

Temos este cenário: Maquina Debian 7 e Fortinet e uma range /25 de IP públicos (172.16.0.0/25) e uma range interna PRIVADA 10.10.10.0/24.
Em post anterior mostrei como publicar um WEB SERVER na porta 80 TCP, vamos utilizar a mesma linha e a mesma range de IP Públicos 172.16.0.1 – 172.16.0.126

image

Vamos acessar nosso firewall e começar a criação de objetos e regras.

Em Firewall Objects, clique em Address, Address, Creat New.

Name: Escolha um nome amigável ou o nome do servidor, neste exemplo DEBIAN-SSH
Color: A sua escolha
Subnet / IP Range: o IP do servidor DEBIAN 10.10.10.150
Interface: Porta1 (LAN) interface privada da rede
Show in Address Lits: deixe habilitada

image

Agora vamos criar o IP Pool, em Virtual IP, IP Pool

Create New

Name: PUBLIC_172_16_0_6
Type: Overload
External IP Range/Subnet
ARP Reply: Deixe habilitado
OK

image

Agora vamos criar o Virtual IP, em Virtual IP, Virtual IP, Creat New

Name: Port_22_SSH
Comments: Porta de acesso SSH
Color: a sua escolha
External Interface: neste exemplo “port3 (WAN2), pois nesta porta que está de cara na internet
Type: Static NAT
External IP Address/Range: 172.16.0.6 – 172.16.0.6 (Nosso IP Público)
Mapped IP Address/Range: 10.10.10.150 – 10.10.10.150
Port Forwarding: Deixe habilitada esta opção
Protocol: Vamos habilitar TCP
External Service Port: 22 – 22
Map to Port: 22 – 22

OK

image

Agora vamos criar a regra de NAT de saída (OUT) para o servidor

Em policy

image

Creat New

Policy Type: Firewall
Policy Subtype: Address
Incoming Interface: port1 (LAN)
Source Address: DEBIAN-SSH (Nosso servidor já criado)
Outgoing Interface: port3 (WAN) nossa porta que está ligada na internet
Destination Address: All
Schedule: always
Service: SSH_Port_22 (neste exemplo escolhi somente a porta 22 para deixar mais seguro)
Action: ACCEPT
Enable Nat: Vamos deixar habilitada
Use Dynamic Pool: Public_172_16_0_6 (Nosso IP público)
Log Alloweb Traffic: vamos habilitar para LOGAR todo o trafico

OK

image

Agora vamos criar a regra de NAT (IN) para acessar externo ao nosso servidor DEBIAN

Em policy, creat new

Policy Typer: Firewall
Policy Address: Address
Incoming Interface: port3(WAN) nossa porta ligada na internet
Source Address ALL, podemos também determinar que somente algumas redes ou somete um IP pode acessar, eu recomendo deixar especificado um RANGE ou IP para acessar, por exemplo se tem um parceiro que cuida deste servidor em sua empresa, peça ao parceiro fornecer seu IP Público de acesso a internet, ai podemos especificar que somente este IP pode acessar, lembrando que seu parceiro forneceu um IP Público Dinâmico (aquele que muda sempre que há um nova conexão) será necessário sempre alterar este IP em objetos>
Outgoing Interface: port1 (LAN)
Destination Address: Port_22_SSH (Criamos este objeto com o IP do Servidor DEBIAN e já com a porta SSH 22 configurada)
Schedule: always (podemos definir também um dia e horário com inicio e fim para acesso
Service: SSH_Port_22 (para deixar ainda mais seguro o acesso)
Action: ACCEPT
Log Allowed Traffic: Deixe habilitada para vermos os Trafico

OK

image

Agora vamos testar a conexão com o PUTTY com o IP interno 10.10.10.150

image

Acessado com sucesso

image

Agora vamos acessar pelo IP Público 172.16.0.6

image

Agora conseguimos o acesso, veja a mensagem do certificado

image

Clicamos em “SIM”

Acessado com sucesso

image