Trabalho Final 5109
Índice
- Vyos
- Instalação do pfSense
- Acesso Através da Interface Web
- Primeira Regra de Firewall
- Desativar DHCP na LAN/Green
- Restringir Pedidos DNS
- Bloquear Tráfego ICMP
- Proxy
- Bloquear AnyDesk
- Port Forwarding
- Instalar OPNsense
- DHCP no OPNsense
- Bloquear Domínios .de
- VPN IPsec Entre OPNsense e pfSense
- VPN OpenVPN Entre OPNsense e pfSense
- Remote Users
- Remote Users no OPNsense
- Captive Portal no pfSense
- Captive Portal no OPNsense
- High Availability no pfSense
- High Availability no OPNsense
- Conclusão
Introdução
A topologia da rede irá seguir a estrutura da imagem acima.
Serão configurados firewalls pfSense e OPNsense em failover, e terão VPNs IPsec e OpenVPN site-to-site, e OpenVPN para remote clients.
Será feita a integração com Active Directory para autenticação de users para alguns serviços, Captive Portal tanto no pfSense quanto no OPNsense também será configurado.
Várias regras de firewall para bloquear acessos tanto externos quanto internos, port forwarding para acessar através da internet websites hospedados internamente.
Entre outras configurações, incluindo algumas configurações em roteadores Vyos, que farão a ligação entre as diferentes zonas.
Vyos
Vamos começar por alterar o hostname dos roteadores, para isso é preciso primeiro entrar no modo de configuração com o comando configure, depois disso para alterar o hostname é só utilizar os seguintes comandos:
set system host-name <nome> commit save
Repita nos três roteadores, dando os nomes adequados.
Depois disso é preciso atribuir IPs às interfaces. Os IPs serão atribuídos de acordo com a lista abaixo:
R1:
00:50:56:25:FB:70 eth0 – NAT – 10.255.59.1/16
00:50:56:25:FB:71 eth1 – R1R3 – 10.155.170.29/30
00:50:56:25:FB:72 eth2 – R1R2 – 10.155.170.21/30
00:50:56:25:FB:73 eth3 – WAN – 10.155.170.17/30
R2:
00:50:56:34:2D:50 eth0 – R1R2 – 10.155.170.22/30
00:50:56:34:2D:51 eth1 – R2R3 – 10.155.170.25/30
00:50:56:34:2D:52 eth2 – R2OPN – 10.155.170.1/30
00:50:56:34:2D:53 eth3 – Host – 10.10.10.10/24
R3
00:50:56:35:D2:60 eth0 – R1R3 – 10.155.170.30/30
00:50:56:35:D2:61 eth1 – R2R3 – 10.155.170.26/30
00:50:56:35:D2:62 eth2 – R3PF – 10.155.170.9/30
00:50:56:35:D2:63 eth3 – Host – 10.10.10.11/24
Para atribuir um IP à uma interface é só utilizar os seguintes comandos:
set interfaces ethernet ethx address x.x.x.x/x set interfaces ethernet ethx description <text>
Após configurar os IPs das interfaces é só fazer o commit e depois o save.
As redes nas interfaces Host são apenas o acesso por SSH aos roteadores através do Host onde as VMs estão rodando, e para habilitar esse acesso utilize o seguinte comando:
set service ssh port 22
Com os roteadores já com os IPs corretos nas interfaces corretas (e com suas interfaces ligadas às redes corretas no hypervisor) já é possível haver comunicação entre eles, entretanto eles ainda não conseguem acessar a internet, para isso é preciso primeiro configurar o NAT no roteador que está ligado à internet, que nesse caso é o R1.
Vamos começar por configurar a rota de dreno, e para isso iremos configurar uma rota estática, apontando para o IP do gateway que o R1 utiliza para acessar a internet:
set protocols static route 0.0.0.0/0 next-hop 10.255.0.1
Aqui, o IP 10.255.0.1 é o IP do gateway que o R1 está utilizando para acessar a internet.
Depois de configurada a rota estática é preciso configurar o NAT, primeiro é preciso criar uma regra dizendo qual é a interface que está ligada ao gateway, que nesse caso é a interface eth0, para criar essa regra utilizamos o seguinte comando:
set nat source rule 100 outbound-interface eth0
Agora é preciso configurar o endereço que será utilizado para fazer essa tradução, isso pode ser feito de duas maneiras, indicando diretamente qual é o endereço de IP, caso tenha um IP estático na interface que foi configurada como outbound, ou configurar como masquerade, que é especialmente útil caso o roteador esteja recebendo o IP da interface externa por DHCP, nesse caso irei configurar especificando o endereço de IP diretamente, já que essa interface tem um IP estático, isso é feito com o seguinte comando:
set nat source rule 100 translation address 10.255.59.1
Depois disso podemos configurar o IP do servidor DNS que o roteador irá utilizar para fazer a resolução de domínios, caso isso seja desejado, isso pode ser feito com o seguinte comando:
set system name-server x.x.x.x
Depois disso é só fazer o commit e save.
E com isso o R1 já tem acesso à internet, e os dispositivos que estão ligados a ele também o tem, caso estejam configurados apropriadamente, e para que os outros dois roteadores também tenham acesso à internet é preciso configurar as rotas, isso pode ser feito manualmente, através de rotas estáticas, ou através de um protocolo de roteamento, nesse caso será utilizado o protocolo OSPF (Open Shortest Path First), que irá se encarregar de propagar as redes disponíveis entre os roteadores.
Vamos começar por configurar o R1, os comandos são os seguintes:
set interfaces loopback lo address 10.1.1.1/32 set protocols ospf area 0 network 10.155.170.16/30 set protocols ospf area 0 network 10.155.170.20/30 set protocols ospf area 0 network 10.155.170.28/30 set protocols ospf passive-interface eth0 set protocols ospf passive-interface eth3 set protocols ospf default-information originate always set protocols ospf default-information originate metric 10 set protocols ospf default-information originate metric-type 2 set protocols ospf parameters router-id 10.1.1.1 set protocols ospf redistribute connected metric-type 2 set protocols ospf redistribute connected route-map CONNECT set policy route-map CONNECT rule 10 action permit set policy route-map CONNECT rule 10 match interface lo
O primeiro comando define o endereço da interface loopback, que também servirá como o ID do roteador.
Os próximos três comandos servem para configurar as redes que serão anunciadas, para que possam ser acessadas através de outros roteadores.
Os próximos dois comandos configuram as interfaces eth0 e eth3 como passivas, ou seja, interfaces que não tem um roteador utilizando OSPF ligado a elas, evitando assim que tráfego OSPF seja enviado através dessa interface, reduzindo a “poluição” nessa rede e também a carga no roteador, já que não precisará processar comunicação dos protocolos de roteamento nessas interfaces.
Os próximos três comandos servem para anunciar a rota de dreno, para que os outros roteadores possam ter acesso à internet.
O próximo comando configura o ID do roteador, que é igual ao IP da interface loopback.
Os próximos dois comandos configuram a distribuição das rotas pelo protocolo e como é feito o cálculo dos pesos das rotas.
Os dois últimos configuram as regras da distribuição.
Depois de feita a configuração é só fazer o commit e save.
Com isso já temos o OSPF configurando no R1, agora é só configurar o R2 e R3, a configuração é similar, omitindo apenas a parte da rota de dreno, já que apenas o R1 está ligado à internet.
A configuração do R2 é a seguinte:
set interfaces loopback lo address 10.2.2.2/32 set protocols ospf area 0 network 10.155.170.0/30 set protocols ospf area 0 network 10.155.170.20/30 set protocols ospf area 0 network 10.155.170.24/30 set protocols ospf passive-interface eth2 set protocols ospf passive-interface eth3 set protocols ospf parameters router-id 10.2.2.2 set protocols ospf redistribute connected metric-type 2 set protocols ospf redistribute connected route-map CONNECT set policy route-map CONNECT rule 10 action permit set policy route-map CONNECT rule 10 match interface lo
E para o R3:
set interfaces loopback lo address 10.3.3.3/32 set protocols ospf area 0 network 10.155.170.8/30 set protocols ospf area 0 network 10.155.170.24/30 set protocols ospf area 0 network 10.155.170.28/30 set protocols ospf passive-interface eth2 set protocols ospf passive-interface eth3 set protocols ospf parameters router-id 10.3.3.3 set protocols ospf redistribute connected metric-type 2 set protocols ospf redistribute connected route-map CONNECT set policy route-map CONNECT rule 10 action permit set policy route-map CONNECT rule 10 match interface lo
Com isso já temos o OSPF configurado, e assim já temos acesso, de qualquer ponto da rede, à internet e às redes que foram anunciadas.
As redes ficarão, por enquanto, distribuídas dessa maneira:
R1R3 – 10.155.170.28/30
R3R2 – 10.155.170.24/30
R1R2 – 10.155.170.20/30
WAN – 10.155.170.16/30
R3pf – 10.155.170.8/30
R2OP – 10.155.170.0/30
As rotas configuradas no R1 através do OSPF.
Também no R2.
E no R3.
Também podemos fazer alguns testes de conectividade para confirmar que os três roteadores tem acesso à internet.
O comando dig no R1 mostrando que a resolução de endereços está funcionando corretamente utilizando o servidor secundário da Cloudflare.
Mesma coisa no R2, utilizando o servidor primário da OpenDNS/Cisco.
E no R3, utilizando o servidor primário da Cloudflare.
Ping funcionando corretamente tanto especificando diretamente o IP como fazendo a resolução do endereço no R1.
Mesma coisa para o R2.
E para o R3.
As configurações dos roteadores devem ficar assim:
R1
interfaces {
ethernet eth0 {
address 10.255.59.1/16
description Interwebs
hw-id 00:50:56:25:fb:70
}
ethernet eth1 {
address 10.155.170.29/30
description R1R3
hw-id 00:50:56:25:fb:71
}
ethernet eth2 {
address 10.155.170.21/30
description R1R2
hw-id 00:50:56:25:fb:72
}
ethernet eth3 {
address 10.155.170.17/30
description WAN
hw-id 00:50:56:25:fb:73
}
loopback lo {
address 10.1.1.1/32
}
}
nat {
source {
rule 100 {
outbound-interface eth0
translation {
address 10.255.59.1
}
}
}
}
policy {
route-map CONNECT {
rule 10 {
action permit
match {
interface lo
}
}
}
}
protocols {
ospf {
area 0 {
network 10.155.170.28/30
network 10.155.170.20/30
network 10.155.170.16/30
}
default-information {
originate {
always
metric 10
metric-type 2
}
}
parameters {
abr-type cisco
router-id 10.1.1.1
}
passive-interface eth0
passive-interface eth3
redistribute {
connected {
metric-type 2
route-map CONNECT
}
}
refresh {
}
}
static {
route 0.0.0.0/0 {
next-hop 10.255.0.1 {
}
}
}
}
service {
ssh {
port 22
}
}
system {
config-management {
commit-revisions 100
}
console {
device ttyS0 {
speed 115200
}
}
host-name R1
login {
user vyos {
authentication {
encrypted-password $6$FLgoZsMdlnVN2$z7o2ezyVHgqAjtPv/UyPE3l46Kg7/DJGZP9YChYmmVETaf4ozbivfu9EfZKxNf67P4nQepmK3gYohHyRlO8Ob0
plaintext-password ""
public-keys crappy-key {
key AAAAB3NzaC1yc2EAAAADAQABAAAAgQC5nbn8bcXoMbr6+kdYK6rgifD2UbNTSh2rfXuMZO5dqp8z4GQ9fQoqUl47AiGrX4cmfoTN31VATWwLy8V8mh5rUj0eNGPSzWzx5Z9+2eGVIpkRMk4JlptHoBzIil9UhF8kUJlJr7g70jXdcB41lCboW0DxqrUBUCJd0G8+NatMiQ==
type ssh-rsa
}
}
}
}
name-server 1.1.1.1
ntp {
server 0.pool.ntp.org {
}
server 1.pool.ntp.org {
}
server 2.pool.ntp.org {
}
}
syslog {
global {
facility all {
level info
}
facility protocols {
level debug
}
}
}
}
// Warning: Do not remove the following line.
// vyos-config-version: "broadcast-relay@1:cluster@1:config-management@1:conntrack@2:conntrack-sync@2:dhcp-relay@2:dhcp-server@5:dhcpv6-server@1:dns-forwarding@3:firewall@5:https@2:interfaces@20:ipoe-server@1:ipsec@5:l2tp@3:lldp@1:mdns@1:nat@5:ntp@1:pppoe-server@5:pptp@2:qos@1:quagga@8:rpki@1:salt@1:snmp@2:ssh@2:sstp@3:system@20:vrrp@2:vyos-accel-ppp@2:wanloadbalance@3:webproxy@2:zone-policy@1"
// Release version: 1.3.0-rc6
R2
interfaces {
ethernet eth0 {
address 10.155.170.22/30
description R1R2
hw-id 00:50:56:34:2d:50
}
ethernet eth1 {
address 10.155.170.25/30
description R2R3
hw-id 00:50:56:34:2d:51
}
ethernet eth2 {
address 10.155.170.1/30
description R2OPN
hw-id 00:50:56:34:2d:52
}
ethernet eth3 {
address 10.10.10.10/24
description Host
hw-id 00:50:56:34:2d:53
}
loopback lo {
address 10.2.2.2/32
}
}
policy {
route-map CONNECT {
rule 10 {
action permit
match {
interface lo
}
}
}
}
protocols {
ospf {
area 0 {
network 10.155.170.0/30
network 10.155.170.20/30
network 10.155.170.24/30
}
parameters {
abr-type cisco
router-id 10.2.2.2
}
redistribute {
connected {
metric-type 2
route-map CONNECT
}
}
}
static {
}
}
service {
ssh {
port 22
}
}
system {
config-management {
commit-revisions 100
}
console {
device ttyS0 {
speed 115200
}
}
host-name R2
login {
user vyos {
authentication {
encrypted-password $6$FLgoZsMdlnVN2$z7o2ezyVHgqAjtPv/UyPE3l46Kg7/DJGZP9YChYmmVETaf4ozbivfu9EfZKxNf67P4nQepmK3gYohHyRlO8Ob0
plaintext-password ""
public-keys crappy-key {
key AAAAB3NzaC1yc2EAAAADAQABAAAAgQC5nbn8bcXoMbr6+kdYK6rgifD2UbNTSh2rfXuMZO5dqp8z4GQ9fQoqUl47AiGrX4cmfoTN31VATWwLy8V8mh5rUj0eNGPSzWzx5Z9+2eGVIpkRMk4JlptHoBzIil9UhF8kUJlJr7g70jXdcB41lCboW0DxqrUBUCJd0G8+NatMiQ==
type ssh-rsa
}
}
}
}
name-server 1.1.1.1
ntp {
server 0.pool.ntp.org {
}
server 1.pool.ntp.org {
}
server 2.pool.ntp.org {
}
}
syslog {
global {
facility all {
level info
}
facility protocols {
level debug
}
}
}
}
// Warning: Do not remove the following line.
// vyos-config-version: "broadcast-relay@1:cluster@1:config-management@1:conntrack@2:conntrack-sync@2:dhcp-relay@2:dhcp-server@5:dhcpv6-server@1:dns-forwarding@3:firewall@5:https@2:interfaces@20:ipoe-server@1:ipsec@5:l2tp@3:lldp@1:mdns@1:nat@5:ntp@1:pppoe-server@5:pptp@2:qos@1:quagga@8:rpki@1:salt@1:snmp@2:ssh@2:sstp@3:system@20:vrrp@2:vyos-accel-ppp@2:wanloadbalance@3:webproxy@2:zone-policy@1"
// Release version: 1.3.0-rc6
R3
interfaces {
ethernet eth0 {
address 10.155.170.30/30
description R1R3
hw-id 00:50:56:35:d2:60
}
ethernet eth1 {
address 10.155.170.26/30
description R2R3
hw-id 00:50:56:35:d2:61
}
ethernet eth2 {
address 10.155.170.9/30
description R3PF
hw-id 00:50:56:35:d2:62
}
ethernet eth3 {
address 10.10.10.11/24
description Host
hw-id 00:50:56:35:d2:63
}
loopback lo {
address 10.3.3.3/32
}
}
policy {
route-map CONNECT {
rule 10 {
action permit
match {
interface lo
}
}
}
}
protocols {
ospf {
area 0 {
network 10.155.170.28/30
network 10.155.170.24/30
network 10.155.170.8/30
}
parameters {
abr-type cisco
router-id 10.3.3.3
}
redistribute {
connected {
metric-type 2
route-map CONNECT
}
}
}
static {
}
}
service {
ssh {
port 22
}
}
system {
config-management {
commit-revisions 100
}
console {
device ttyS0 {
speed 115200
}
}
host-name R3
login {
user vyos {
authentication {
encrypted-password $6$FLgoZsMdlnVN2$z7o2ezyVHgqAjtPv/UyPE3l46Kg7/DJGZP9YChYmmVETaf4ozbivfu9EfZKxNf67P4nQepmK3gYohHyRlO8Ob0
plaintext-password ""
public-keys crappy-key {
key AAAAB3NzaC1yc2EAAAADAQABAAAAgQC5nbn8bcXoMbr6+kdYK6rgifD2UbNTSh2rfXuMZO5dqp8z4GQ9fQoqUl47AiGrX4cmfoTN31VATWwLy8V8mh5rUj0eNGPSzWzx5Z9+2eGVIpkRMk4JlptHoBzIil9UhF8kUJlJr7g70jXdcB41lCboW0DxqrUBUCJd0G8+NatMiQ==
type ssh-rsa
}
}
}
}
name-server 1.1.1.1
ntp {
server 0.pool.ntp.org {
}
server 1.pool.ntp.org {
}
server 2.pool.ntp.org {
}
}
syslog {
global {
facility all {
level info
}
facility protocols {
level debug
}
}
}
}
// Warning: Do not remove the following line.
// vyos-config-version: "broadcast-relay@1:cluster@1:config-management@1:conntrack@2:conntrack-sync@2:dhcp-relay@2:dhcp-server@5:dhcpv6-server@1:dns-forwarding@3:firewall@5:https@2:interfaces@20:ipoe-server@1:ipsec@5:l2tp@3:lldp@1:mdns@1:nat@5:ntp@1:pppoe-server@5:pptp@2:qos@1:quagga@8:rpki@1:salt@1:snmp@2:ssh@2:sstp@3:system@20:vrrp@2:vyos-accel-ppp@2:wanloadbalance@3:webproxy@2:zone-policy@1"
// Release version: 1.3.0-rc6
Instalação do pfSense
O pfSense ficará ligado ao R3, e terá internamente 3 redes, Green, Blue e Orange (DMZ), e mais adiante, uma quarta rede para a sincronização com uma segunda instância para alta disponibilidade, contando com a interface WAN, para um total de 5 interfaces necessárias, e como para os roteadores, uma interface extra para acesso direto do Host para facilitar o acesso à interface web diretamente pelo Host, sem precisar de uma VM para isso, para um total de 6 interfaces de rede.
As interfaces ficarão dessa maneira:
00:50:56:33:94:B0 – R3-pf/WAN 10.155.170.10/30
00:50:56:33:94:B1 – pfGreen 172.29.170.1/23
00:50:56:33:94:B2 – pfOrange 10.18.170.1/29
00:50:56:33:94:B3 – pfBlue 10.0.170.1/24
00:50:56:33:94:B4 – pfSync 172.168.255.1/30
00:50:56:33:94:B5 – Host 10.10.10.20/24
Após a instalação, para evitar problemas, recomendo não só remover o ISO da VM, mas remover completamente a “unidade óptica”, para não correr o risco da VM iniciar através de alguma imagem que esteja lá.
Após reiniciar a VM chegamos a essa tela:
Aqui iremos iniciar a configuração, primeiro vamos configurar as interfaces, para isso escolha a opção 1) Assign Interfaces.
Não iremos configurar VLANs, por isso selecione n.
A primeira interface a ser definida é a WAN, nesse caso, que aqui será a interface em0.
Depois disso será pedido para escolhermos qual será a interface para a LAN, aqui será a em1.
Depois disso será pedido para definir as interfaces Optional 1-4, é só continuar por ordem, escolhendo as interfaces em2 até em5.
Quando terminado teremos as 6 interfaces definidas.
Após alguns momentos estamos de volta à tela inicial, dessa vez com as 6 interfaces à mostra.
Agora será preciso definirmos alguns IPs, para isso escolha a opção 2) Set interface(s) IP address.
Aqui podemos escolher qual interface desejamos dar um IP, vamos começar pela interface 1 – WAN.
Será perguntado se desejamos usar DHCP para atribuir um IP a essa interface, iremos atribuir IPs manualmente, por isso selecione n.
O IP dessa interface ficará como 10.155.170.1/30.
Agora precisamos definir o IP do gateway, para que o pfSense tenha acesso à internet, que aqui será 10.155.170.9.
Agora será perguntado se desejamos configurar IPv6 por DHCP, não iremos utilizar IPv6, por isso selecione n.
Como dissemos que não queremos configurar IPv6 por DHCP, nos é pedido para definir manualmente um endereço, como não iremos utilizar IPv6, apenas aperte Enter.
Agora nos é perguntado se desejamos mudar o protocolo da interface web de HTTPS para HTTP, escolha a opção que desejar, tendo sempre em mente que não é recomendado o acesso à interface web através da interface WAN, e caso realmente seja necessário, é recomendado utilizar HTTPS.
Com isso já temos a interface WAN configurada.
O processo é o mesmo para configurar o IP das outras interfaces, as únicas diferenças sendo não ser necessário configurar o endereço de um gateway, já que para essas interfaces, o próprio pfSense será o gateway, e nos ser perguntado se desejamos habilitar o servidor DHCP nessas interfaces, para atribuir IPs aos clientes que sejam ligados a ela.
É possível configurar o resto das interfaces diretamente por aqui ou continuar a configuração através de um cliente ligado à rede LAN, como temos a interface OPT4, que será utilizada para esse fim, irei configurar apenas mais essa interface por aqui, antes de continuar a configuração pela interface web.
Aqui nos é perguntado se desejamos habilitar o servidor DHCP para essa interface, aqui não será necessário, selecione a opção n.
Aqui podemos ver as interfaces que temos configuradas nesse momento, as restantes interfaces serão configuradas através da interface web, mas para podermos a acessar através da interface OPT4 precisamos primeiro desativar o firewall, já que nesse momento ela pode ser acessada apenas através da interface LAN.
Para desativar o firewall é preciso acessar o terminal, para isso selecione a opção 8) Shell.
Aqui podemos desativar temporariamente o firewall com o comando pfctl -d.
E aqui podemos ver que o firewall foi desativado, tenha atenção que sempre que alguma configuração for aplicada através da interface web, por isso é possível que seja necessário repetir esse procedimento algumas vezes até que o acesso por essa interface esteja completamente configurado.
E com isso já podemos acessar a interface web através do IP 10.10.10.20.
Acesso Atráves da Interface Web
Como esse é um certificado criado pelo próprio pfSense, é preciso o aceitar manualmente.
E com isso já temos acesso à interface web, as credenciais de acesso são admin e pfsense.
E com isso podemos iniciar o processo de configuração, clique em Next para prosseguir.
Caso queira mais informações sobre as opções de suporte da Netgate clique em Learn more, caso contrário, clique em Next para prosseguir.
Aqui é possível configurar o hostname, domínio e endereços dos servidores de DNS que deseja utilizar.
Após configurar da maneira que deseja, clique em Next.
Aqui pode configurar o servidor NTP e o fuso horário que deseja, clique em Next quando estiver satisfeito.
Aqui pode fazer configurações à interface WAN.
Como iremos trabalhar apenas com IPs privados, é preciso desativar essas duas opções, caso contrário não iremos conseguir acessar os servidor que estão do lado de dentro do firewall, depois de desselecionar essas duas opções, clique em Next.
Aqui podemos configurar o IP da interface LAN, ficará na rede Green
Depois de colocar o IP que deseja para essa interface, clique em Next.
Agora é preciso definir uma nova senha para a conta admin, depois de escolher a nova senha clique em Next.
Agora será preciso aplicar as novas configurações, clique em Reload.
E com isso terminamos as configurações iniciais, clique em Finish para terminar.
Depois de clicar em Finish será preciso desativar novamente o firewall através do terminal.
Depois que o firewall for desativado temos acesso à interface principal, clique em Accept para fechar esse popup.
Caso queira participar da pesquisa clique no link User survey, caso contrário clique em Close.
E com isso temos acesso ao Dashboard.
Vamos começar por permitir o acesso à interface web através da interface OPT4, para isso vá em Firewall -> Rules.
Primeira Regra de Firewall
Clique na aba OPT4.
Clique em Add.
Essa regra irá permitir qualquer protocolo (pode restringir apenas a TCP para apenas ter acesso à interface web), irá permitir tráfego originado da rede configurada na interface OPT4, caso deseje pode restringir apenas a um único endereço de IP, e o destino é apenas ao IP que foi dado a essa interface, dessa maneira nenhum tráfego vindo dessa rede chegará a nenhuma outra rede do pfSense.
Depois de terminada a configuração da regra clique em Save.
Agora será preciso aplicar essas alterações, para isso clique em Apply Changes.
É possível que demore alguns instantes até essa regra ficar ativa, por isso é normal que perca acesso à interface web temporariamente.
E com isso já não precisamos mais nos preocupar em ficar sem acesso à interface web sempre que for feita alguma alteração ao firewall, e para confirmar que o firewall está ativo, pode ir até o terminal e utilizar o comando pfctl -e para o ativar, deverá receber de volta uma mensagem dizendo que ele já está ativo.
Iremos configurar as outras interfaces de rede, mas para isso, primeiro será necessário desativar alguns serviços DHCPv6 que estão ativos.
Para isso clique em Services -> DHCPv6 & RA.
Em DHCPv6 Server desselecione a opção Enable DHCPv6 server on interface LAN e depois clique em Save no final da página.
Depois, na aba Router Advertisements, em Router mode selecione Disabled, depois clique no botão Save no final da página.
Com isso já podemos alterar as configurações da interface LAN.
Clique em Interfaces -> LAN.
Aqui podemos fazer várias alterações nessa interface, incluindo o seu IP, nesse caso apenas o seu nome/descrição será alterado.
Após escrever o novo nome, em IPv6 Configuration Type selecione None, depois clique no botão Save, no final da página.
Clique em Apply Changes.
Aqui podemos ver que a interface LAN agora se chama GREEN (Em alguns locais o nome aparece com todas as letras maiúsculas, em outros aparece da maneira como foi escrita, isso é normal).
Após repetir esses passos para a interface OPT4 para a Renomear para Host, vamos configurar as interfaces para as redes Blue e Orange.
Vamos as configurar por ordem, começando pela interface OPT1, que ficará como Orange, clique em Interfaces -> OPT1.
Aqui temos acesso às configurações dessa interface.
É preciso primeiro habilitar essa interface, selecione a opção Enable interface, depois, em Description, dê o nome que deseja, nesse caso ficará como Orange (DMZ), em IPv4 Configuration Type, selecione Static IPv4, e mais abaixo, em IPv4 Address, coloque o IP e máscara que deseja para essa interface, nesse caso ficará como 10.18.170.1/29, depois disso clique em Save.
Clique em Apply Changes.
Repetir os passos para a interface Blue.
E com isso já temos as interfaces que iremos precisar nesse momento já configuradas.
Desativar DHCP na LAN/Green
Na rede Green teremos uma máquina com o Windows Server, que tem o seu próprio servidor DHCP, e para evitar conflitos precisamos primeiro desativar o servidor DHCP do pfSense que está ativo na interface Green.
Vá em Services -> DHCP Server.
Aqui podemos ver que o servidor DHCP está ativo nessa interface.
Desative-o e clique no botão Save no fim da página.
Com isso o servidor DHCP do Windows Server não terá mais problemas e poderá atribuir IPs aos clientes que estejam ligados a essa rede.
Aqui temos o cliente que recebeu IP através do servidor DHCP do Windows Server.
E aqui temos o Lease no Windows Server.
Restringir Pedidos DNS
Agora é preciso restringir o acesso à servidores DNS para os dispositivos que estejam na rede Green, permitindo apenas o Windows Server fazer esses pedidos, para que os outros dispositivos possam usar apenas o Windows Server como servidor DNS.
A zona Green, previamente LAN, no pfSense, por definição vem com algumas regras já configuradas no firewall, uma para permitir sempre os dispositivos ligados a essa rede o acesso à interface web, e outra para permitir qualquer tipo de tráfego que esteja saindo dessa rede.
Serão necessárias algumas regras para bloquear o acesso à servidores DNS externos para os clientes, enquanto esse acesso é permitido ao Windows Server, também será necessário criar uma regra para permitir que os clientes naveguem na internet.
O primeiro passo é ir até a página das regras do firewall, clique em Firewall -> Rules.
Vá para a aba da rede Green.
Será preciso desativar ou remover a regra que permite todo o tráfego originado dessa rede, para a desativar clique no ícone 🚫 que está do lado direito da regra, e caso queira a excluir clique no ícone 🗑 que está do lado direito da regra, depois clique em Apply Changes.
Como será necessário aplicar a mesma regra para mais do que uma porta, para não ter que criar duas regras iguais para portas diferentes, vamos criar aliases para essas portas, para isso clique em Firewall -> Aliases.
Para criar esses aliases vá para a aba Ports e clique em Add.
É preciso dar um nome a esse alias, a descrição é opcional, em Type certifique-se de que Port(s) esteja selecionado, e abaixo, em Port(s), iremos adicionar as portas.
A primeira porta será a 53, que é a porta tradicionalmente utilizada pelo serviço DNS, coloque o número da porta e uma descrição, se desejar, depois clique em Add Port, para adicionarmos uma segunda porta, essa segunda porta será a porta 853, que é utilizada pelo serviço DNS quando o tráfego é encriptado.
Depois de adicionar essas duas portas clique em Save.
O processo será repetido para o tráfego HTTP e HTTPS, nesse caso para as portas 80 e 443.
Aqui temos os dois aliases criados.
Agora vamos criar as regras no firewall, para isso volte até a página das regras para a rede Green e clique em Add para criar uma nova regra (a ordem importa, por isso essa regra deve ser a primeira da lista, por isso clique no botão Add com a seta apontando para cima).
Aqui iremos configurar essa regra, em Action selecione Pass, a interface deve ser GREEN, como não estamos utilizando IPv6, em Address Family selecione IPv4, em Protocol selecione TCP/UDP, já que em alguns casos específicos TCP é utilizado pelo DNS.
Em Source selecione Single host or alias e coloque o IP do Windows Server, já que ele será o único com permissão para acessar servidores DNS externos.
Em Destination deixe any, e em Destination Port Range deixe o primeiro e terceiro campos como (other) e no segundo e quarto coloque o alias criado para as portas DNS.
Caso queira colocar uma descrição para essa regra, a coloque no campo Description, em Extra Options.
Depois clique em Save.
Agora iremos criar uma regra que irá bloquear o tráfego DNS para fora da rede para o resto dos dispositivos.
A primeira parte é igual à regra anterior, com a única diferença sendo que em Action, iremos selecionar Block em vez de Pass.
Em Source selecione GREEN net, já que essa regra se aplica ao tráfego originado da rede inteira.
Destination ficará da mesma maneira que a regra anterior.
Coloque uma descrição apropriada e clique em Save.
Aqui podemos ver as duas regras para o acesso a servidores DNS externos, é importante que elas estejam nessa ordem, a regra que permite o acesso ao Windows Server acima da regra que bloqueia o acesso à rede.
Agora para a criação da regra que permite o acesso à web aos dispositivos da rede Green.
Essa regra irá permitir o acesso, por isso em Action é preciso selecionar Pass, a interface é GREEN e nesse caso o protocolo é apenas TCP.
Essa regra irá permitir o tráfego originado de toda a rede Green, por isso em Source selecione Green net.
Em Destination, deixe como any e para as portas, da mesma maneira como foi feito para as regras para o DNS, coloque o nome do alias criado para as portas web.
Dê uma descrição para a regra e clique em Save.
Com isso já temos as regras básicas criadas e já podemos fazer alguns testes.
Aqui podemos ver que o cliente não consegue utilizar nenhum outro servidor DNS além do Windows Server.
O Windows Server tem acesso à servidores DNS externos.
O cliente pode navegar na internet sem problemas.
Assim como o Windows Server.
Bloquear Tráfego ICMP
Iremos bloquear o tráfego ICMP originado das redes internas do firewall para todas as redes no intervalo 10.155.170.0/27, para isso é preciso criar uma regra que irá bloquear esse tipo de tráfego.
Aqui temos duas opções, criar uma regra para cada interface ou criar uma regra flutuante e selecionar de uma só vez todas as interfaces internas, para facilitar a gestão, vamos optar por uma regra flutuante.
Depois de decidir onde essa regra será criada, é preciso decidir como essa regra será criada, e existem algumas maneiras diferentes de o fazer, uma delas é criar duas regras, uma permitindo o tráfego ICMP, originado das redes internas, para todas as redes, com outra regra bloqueando apenas o tráfego destinado à rede que não desejamos (e isso pode ser feito de duas “maneiras”, uma delas é com a regra que permite o tráfego ICPM para todas as redes primeiro, e a regra que bloqueia o tráfego para a rede que desejamos bloquear abaixo da regra anterior, ou então colocar essa regra logo acima e selecionar a opção Quick, que aplica a regra imediatamente caso haja uma correspondência, e dessa maneira não chega a comparar com as regras a seguir), e outra é criar uma regra que permite o tráfego ICMP originado das redes internas e quando selecionamos o destino, colocamos a rede que não queremos que esteja acessível e selecionamos a opção Invert match, dessa maneira o tráfego é permitido para todas as redes, exceto a rede que especificamos.
Iremos criar uma regra flutuante com a opção Invert match, para simplificar e usarmos apenas uma única regra.
Clique em Firewall -> Rules.
Depois na aba Floating e em Add (como não temos nenhuma regra aqui, tanto faz se é para adicionar uma regra acima ou abaixo).
Em Action selecione Pass, em Interface selecione as interfaces das redes internas, nesse caso serão as interfaces GREEN, ORANGEDMZ e BLUE, em Direction deixe como any, Address Family fica como IPv4, como nas outras regras, e em Protocol selecione ICMP, pode deixar a opção ICMP Subtypes como any.
A opção Source pode ficar como any, já que essa regra será aplicada a várias interfaces, com diferentes redes, e em Destination selecione a opção Invert match e no menu a opção Network, e adicione a rede que deseja bloquear, como iremos bloquear várias redes contíguas, podemos simplesmente colocar o endereço da primeira rede e uma máscara que abranja todas as redes em questão.
Coloque uma descrição e clique em Save.
A regra já foi criada, mas ainda não está ativa, clique em Apply Changes para que seja aplicada.
Com isso já temos a nossa regra ativa e podemos fazer alguns testes.
Adicionei um novo IP a uma das interfaces do R1 e adicionei a rede desse IP nas redes propagadas pelo OSPF para que seja propagada aos outros roteadores.
E aqui podemos ver que o cliente, do lado de dentro do firewall, não consegue fazer ping a redes que configuramos para serem excluídas na regra, entretanto, consegue fazer ping ao IP adicionado ao R1.
Proxy
Existem alguma maneiras diferentes de se configurar um proxy no pfSense, aqui iremos instalar o Squid.
Para instalar o Squid vá em System -> Package Manager.
Depois clique na aba Available Packages.
No campo Search term coloque squid e clique em Search, depois em Install para o pacote squid.
Clique em Confirm para confirmar a instalação do pacote.
Com isso a instalação do Squid será iniciada, aguarde alguns momentos até que seja terminada.
Com isso temos o Squid instalado com sucesso.
Depois de terminar a instalação, clique em Services -> Squid Proxy Server.
Com isso entramos nas configurações do servidor proxy, mas antes que possamos fazer qualquer outra coisa, é preciso configurar o cache local, para isso clique na aba Local Cache.
Aqui é possível fazer várias configurações referentes ao caching de conteúdo, para que os computadores da rede não tenham que ir buscar na internet conteúdo que esteja salvo em cache, possivelmente poupando largura de banda e aumentando a velocidade das transferências para os clientes, mas aqui não iremos usar essa função, caso queira mais informações sobre essa funcionalidade pode sempre ler a documentação.
Em Disable Caching, selecione a opção Disable caching completely e depois clique no botão Save no final da página.
Antes de continuarmos a configuração é preciso primeiro criar um novo certificado CA para a emissão de um novo certificado que será utilizado pelo proxy.
Clique em System -> Cert. Manager.
Aqui iremos criar o novo certificado CA, para isso, na aba CAs, clique em Add.
Aqui é preciso preencher os campos para gerar o certificado.
Esse certificado será utilizado para que o proxy, configurado como man-in-the-middle, possa inspecionar todo o tráfego que passe por isso, isso tem óbvias implicações de privacidade, e sempre que esse tipo de proxy for utilizado é preciso comunicar os usuários, também é preciso verificar a legalidade desse tipo de uso onde se encontra, já que como todo o tráfego é decriptado, a cadeia de confiança entre servidor e cliente é quebrada, e todo o tráfego que era confidencial, agora está visível para o proxy, questões éticas e legais à parte, prossiga por conta própria.
Essa autoridade certificadora óbviamente não é a mesma que emitiu os certificados legítimos dos websites que serão visitados, por isso é de bom tom deixar claro a finalidade desse certificado e não tentar enganar os usuários do sistema.
Depois de preencher os dados clique em Save.
Com isso já temos o certificado criado, agora é preciso exportar esse certificado para que ele possa ser importado nas máquinas clientes, para isso, em Actions, do lado direito da janela, clique no ícone redondo similar a uma roda dentada, assim irá exportar o certificado que pode ser instalado nas máquinas clientes, essa instalação pode ser feita de várias maneiras, e vai depender do OS utilizado, no caso de máquinas Windows que façam parte de um domínio com um servidor AD, isso pode ser feito através de GPOs.
Depois de importar o certificato CA nas máquinas clientes, elas irão aceitar os certificados gerados pelo pfSense, e para que a mensagem dizendo que existe um potenção risco ao acessar a interface web, podemos criar um novo certificado para ela.
Clique na aba Certificates e depois no botão Add/Sign.
Aqui é só preencher o certificado como for mais apropriado, e em Certificate Type selecionar a opção Server Certificate.
Depois de preencher os dados corretamente, clique em Save.
E com isso já temos o novo certificado criado, agora é preciso configurar o sistema para utilizar esse novo certificado na interface web.
Clique em System -> Advanced.
Aqui temos a configuração atual da interface web, em SSL/TLS Certificate podemos ver que o certificado que foi gerado durante a instalação está sendo utilizado, precisamos selecionar o certificado que acabamos de gerar.
Selecione o certificado que foi criado e clique em Save no final da página.
E aqui temos o novo certificado ativo.
Vamos agora configurar o proxy, volte para a página de configuração do proxy.
Aqui temos o proxy configurado, primeiro é preciso o habilitar, para isso, em Enable Squid Proxy, marque a caixa Check to enable the Squid proxy, e certifeique-se de que a caixa de seleção em Keep Settings/Data também esteja selecionada, caso contrário, todas as configurações serão perdidas caso seja necessário reinstalar o pacote, ou caso seja instalada uma atualização.
Em Proxy Interface(s) selecione as interfaces que deseja que o proxy esteja ativo, nesse caso ele está ativo apenas na interface Green.
Em Proxy Port é possível configurar a porta em que o servidor proxy vai aceitar conexões, caso não esteja utilizando o modo transparente, a porta padrão é a 3128.
Em Transparent HTTP Proxy marque a caixa Enable transparent mode to forward all requests for destination port 80 to the proxy server. para ativar o proxy transparente, dessa maneira, não será preciso configurar nenhuma opção de proxy nos clientes, e o tráfego irá passar pelo servidor automaticamente, tenha atenção que o modo transparente não permite configurações mais avançadas, como filtros baseados em autenticação LDAP e similares.
Em Transparent Proxy Interface(s) é possível escolher em quais interfaces o proxy transparente está ativo.
Bypass Proxy for Private Address Destination serve para que tráfego para redes privadas não passe pelo proxy, isso pode ser beneficial quando não seja necessário monitorar o tráfego a sites internos.
Em Bypass Proxy for These Source IPs é possível configurar quais clientes não terão seu tráfego interceptado, interessante para servidores, por exemplo.
Bypass Proxy for These Destination IPs faz o oposto, libera o tráfego para um destino específico, dessa maneira todos os clientes poderão acessar esses endereços sem ter seu tráfego interceptado, útil para invadir a privacidade dos usuários caso acessem sites com informações pessoais e privadas.
Abaixo, em HTTPS/SSL Interception, marque a caixa Enable SSL filtering, para configurar o proxy como Man In the Middle.
Em SSL/MITM Mode selecione a opção Splice Whitelist, Bump Otherwise, essa opção não vai desencriptar o tráfego do que estiver em uma whitelist nas ACLs, caso contrário vai desencriptar o tráfego e apresentar um certificado auto-assinado para o cliente, interceptando esse tráfego.
SSL Intercept Interface(s) é com nos casos anteriores, selecione as interfaces de rede em que essa opção estará ativa.
SSL Proxy Port serve para configurar a porta para o tráfego SSL, por definição é a porta 3129.
EM SSL Proxy Compatibility Mode selecione Modern, para que utilize os algorítmos mais recentes e seguros.
Em CA selecione o certificado CA que foi criado anteriormente para essa finalidade.
SSL Certificate Daemon Children configura o número de processos utilizados para gerar certificados, esses certificados são mantidos em cache, entretanto, caso o processador não seja muito rápido, pode ser necessário aumentar esse número para aproveitar ao máximo o número de núcleos/threads de processamento caso esteja utilizando o firewall em uma rede movimentada e com muitos clientes, para que não haja muita espera na geração dos certificados.
Remote Cert Checks é utilizado para configurar como o servidor irá lidar com certificados remotos, sendo possível aceitar qualquer tipo de certificado do lado do website, mesmo certificados inválidos, isso vai fazer com que os usuários pensem que o site está seguro quando na verdade não está, geralmente não é boa ideia.
Certificate Adapt altera o certificado, geralmente não é necessário configurar essa opção.
Configure as opções de loggin de acordo com as suas necessidades, e daí para baixo nãoé preciso fazer nenhuma alteração para que o proxy funcione.
Depois de terminar a configuração, clique em Save.
E com isso já temos o proxy em modo transparente ativo.
Aqui podemos ver que o proxy transparente está funcionando, temos o certificado emitido pelo servidor, no lugar do certificado original do website.
Com o proxy transparente configurado, podemos agora instalar o SquidGuard para bloquear ou permitir o acesso a determinados tipos de websites, a instalação dele é feita da mesma maneira que o Squid, vá em System -> Package Manager e pesquise pelo nome do pacote, depois o instale.
Depois de instalado vá para a sua página de configuração em Services -> SquidGuard Proxy Filter.
Para que ele possa ser utilizado é preciso marcar a caixa em Enable, e como iremos utilizar uma blacklist para fazer o filtro de websites, também é preciso marcar a caixa em Blacklist, no final da página, e em Blacklist URL coloque o endereço da blacklist que o SquidGuard irá baixar para utilizar.
Aqui podemos ver como fica essa configuração.
Uma das blacklists mais utilizadas, shallalist, do site https://www.shallalist.de/, está indisponível por tempo indeterminado. É possível encontrar a última versão disponível para download em sites como no Wayback Machine, ou utilizar outras listas.
Depois de fazer a configuração clique em Save, isso irá salvar as configurações e iniciar o serviço.
Com as configurações salvas e o serviço iniciado, vá para a aba Blacklist, aqui iremos fazer o download da lista, para isso é só clicar no botão Download, tenha atenção que o download pode não ser iniciado imediatamente, sendo necessário clicar várias vezes nesse botão.
Após o download será criada a base de dados, esse processo pode demorar algum tempo para concluir.
Depois que a criação da base de dados for concluída, a blacklist estará ativa e pode ser configurada na aba Common ACL, e por definição está configurada para bloquear todos os domínios.
Agora é preciso configurar o que está bloqueado e o que está liberado, para isso abra a aba Common ACL.
Aqui temos a configuração inicial, em Target Rules podemos ver que está configurado como !all, ou seja, not all, dessa maneira não deixa passar todos os websites que estão na lista, para alterar isso é preciso clicar, em Target Rules List, no botão +, para expandir a lista.
Aqui podemos ver que a opção Default access [all], está configurada como deny, bloqueando todos os sites por definição.
Dessa maneira podemos criar uma whitelist que irá liberar categorias de websites enquanto todo o resto está bloqueado, mas não é o que queremos nesse momento.
Aqui temos a lista configurada para deixar passar todos os sites, menos os que foram configurados para serem bloqueados, como redes sociais, sites de pornografia, notícias e chat.
Depois de terminar a configuração clique em Save e na aba General settings, clique em Apply, para que as configurações sejam aplicadas.
Agora podemos ver que podemos navegar nos sites que não estão bloqueados.
E se voltarmos para as configurações do proxy transparente no Squid, e adicionarmos o IP do Windows Server, por exemplo, no campo Bypass Proxy for These Source IPs, poderemos ver como o Windows Server pode acessar a internet normalmente.
Depois de colocar o IP da máquina que deseja que não tenha seu tráfego interceptado, clique no botão Save no final da página.
Aqui podemos ver que o Windows Server não só pode acessar websites que estão bloqueados para o resto da rede, mas como não tem o seu tráfego interceptado, como podemos ver pelo fato de o website estar utilizando o seu certificado original.
A opção Bypass Proxy for These Destination IPs funciona da mesma maneira, se adicionarmos um domínio, esse website ficará acessível para toda a rede sem passar pelo proxy.
E se voltarmos para a configuração da Common ACL, no SquidGuard, e bloquear o acesso a webmails, os clientes também deixarão de ter acesso a serviços de webmail, enquanto mantém o acesso ao resto dos websites.
Na imagem acima podemos ver que os serviços de webmail estão bloqueados.
Bloquear AnyDesk
Vamos bloquear o acesso a ferramentas de acesso remoto, como o AnyDesk, mas para isso é preciso primeiro permitir que ela funcione.
Quando foi feita a configuração inicial do firewall, foi removida a regra que permite o tráfego, tanto para dentro como para fora, de qualquer tipo de protocolo, em qualquer porta, para permitir apenas o tráfego web, por isso será preciso habilitar a regra no firewall que permite esse tráfego na rede Green.
Vá para a página das regras do firewall para a rede Green, aqui iremos habilitar a regra Default allow LAN to any rule, que foi desabilitada inicialmente, para isso clique no ícone de um quadrado com uma checkmark dentro.
Depois de a habilitar, a ferramenta AnyDesk, e outras, já deverão funcionar, podemos fazer um teste para experimentar.
O cliente AnyDesk funciona normalmente em um cliente na WAN, como é de esperar.
O cliente AnyDesk funcionando em um cliente na rede Green depois de habilitar a regra no firewall.
Existem algumas maneiras diferentes de bloquear o AnyDesk, é possível utilizar o pfBlockerNG e bloquear utilizando DNS, também é possível bloquear as portas utilizadas pelo serviço, e também é possível bloquear os IPs dos servidores do AnyDesk.
Irei bloquear utilizando os IPs, e também a porta utilizada. Para descobrir quais são os IPs que o AnyDesk utiliza é possível fazer uma captura de pacotes e analizar esse tráfego.
Clique em Diagnostics -> Packet Capture.
Aqui podemos fazer a captura de pacotes com o tcpdump.
Antes de fazer a captura, se certifique de que o AnyDesk está completamente encerrado no cliente.
A interface que será monitorada será a Green, para reduzir ruído, em Address Family selecione IPv4 e em Protocol TCP.
Host Address é o do cliente que tem o AnyDesk instalado, não iremos selecionar nenhuma porta, já que o programa pode utilizar diferentes portas, e ainda não sabemos quais são.
Em Count coloque um valor elevado, de 500 para cima, e selecione a opção Do reverse DNS lookup em Reverse DNS Lookup, isso irá facilitar a nossa vida, já que irá identificar os domínios associados aos endereços de IP, dessa maneira será mais fácil identificar os servidores utilizados pelo AnyDesk.
Depois disso clique em Start para iniciar a captura e abra o AnyDesk no cliente.
Após o AnyDesk se conectar aos servidores do serviço, inicie uma sessão de conexão remota com outra máquina, depois termine essa sessão, e pare a captura no Packet Capture clicando em Stop.
Em Packets Captures deverá ter várias linhas similares a essas:
12:24:24.903953 IP 172.29.170.40.56640 > 20.73.130.64.https: tcp 0 12:24:24.903994 IP 20.73.130.64.https > 172.29.170.40.56640: tcp 0 12:24:27.616956 IP 172.29.170.40.56641 > relay-2056cafc.net.anydesk.com.https: tcp 0 12:24:27.617022 IP relay-2056cafc.net.anydesk.com.https > 172.29.170.40.56641: tcp 0 12:24:27.617475 IP 172.29.170.40.56641 > relay-2056cafc.net.anydesk.com.https: tcp 0 12:24:27.810187 IP 172.29.170.40.56641 > relay-2056cafc.net.anydesk.com.https: tcp 273 12:24:27.810226 IP relay-2056cafc.net.anydesk.com.https > 172.29.170.40.56641: tcp 0 12:24:27.856224 IP relay-2056cafc.net.anydesk.com.https > 172.29.170.40.56641: tcp 1460
Copie tudo o que tiver nessa janela para um documento de texto em uma máquina ou VM linux e crie o seguinte script bash nessa mesma máquina:
#!/bin/bash
cat $1 | egrep -ho '(relay.*anydesk\.com)' | sort --unique >> unique-urls.txt
echo '' > IPs.txt
rm IPs.txt
cat unique-urls.txt | while read line
do
dig @1.1.1.1 $line | egrep -ho '([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)$' | egrep -ho '([0-9]+\.[0-9]+\.[0-9]+\.)' | sort --unique >> IPs.txt
done
rm unique-urls.txt
echo '' > $2
rm $2
cat IPs.txt | while read line
do
for x in {0..255}
do
dig @1.1.1.1 -x ${line}${x} | grep 'anydesk\.com\.$' >> $2
done
done
rm IPs.txt
Esse script é executado da seguinte maneira:
script.sh captura.txt ips.txt onde captura.txt é o nome do documento de texto onde colocou a saída dos pacotes capturados e ips.txt é o nome do documento de texto que irá conter os IPs dos servidores associados com o AnyDesk.
É comum empresas comprarem blocos de IPs, isso significa que é possível que em um intervalo de IPs contíguo é comum encontrar vários servidores/endereços que fazem parte do mesmo domínio. Esse script encontra todos os endereços únicos em que os três primeiros octetos do IP são iguais, e depois faz uma consulta reversa com todos os valores possíveis no quarto octeto, e faz isso para todas as redes únicas que foram encontradas.
Depois que o script terminar de ser executado, crie regras no firewall bloqueando o tráfego a esses IPs ou apenas às faixas de endereços associadas à AnyDesk, quando aplicar as regras, repita os passos da captura de pacotes, já que o programa irá tentar se conectar em servidores diferentes quando não conseguir se conectar aos que foram bloqueados, e quando não encontrar mais nenhum IP novo na captura de pacotes já não deve haver mais nenhum endereço novo com que se preocupar.
Também é possível criar uma regra bloqueando o tráfego destinado à porta 6568, que segundo as páginas de suporte do AnyDesk, é uma das portas utilizadas pelo serviço.
Fazendo isso o AnyDesk deixará de funcionar para os clientes que estão na rede onde foram aplicadas essas regras do firewall.
Aqui podemos ver as regras que foram criadas para bloquear o AnyDesk.
Também é possível criar um Alias com todos os endereços/faixas de IP e criar uma única regra associada a esse Alias.
Aqui podemos ver que o AnyDesk no cliente na rede Green não consegue se conectar aos servidores do serviço.
Configurar acesso pelo TeamViewer
Vamos primeiro confirmar que temos acesso de redes externas.
Na imagem acima temos uma máquina de fora da rede acessando uma máquina interna através do TeamViewer.
E na imagem acima vemos o cliente sendo acessado remotamente.
O processo para bloquear o acesso pelo TeamViewer é similar ao que foi feito para bloquear o AnyDesk.
O TeamViewer usa primariamente a porta 5938 para se conectar, mas infelizmente apenas bloquear essa porta não é suficiente, já que caso essa porta não esteja acessível, ele utiliza as portas 443 e 80 para iniciar as conexões.
Será preciso criar uma lista de IPs que o TeamViewer utiliza, o script anterior pode ser adaptado para criar essa lista.
Após fazer alguns ajustes no script, consegui a seguinte lista de IPs que o TeamViewer utiliza:
158.176.86.10 158.176.86.11 158.176.86.12 158.176.86.13 158.176.86.14 158.176.86.15 158.176.86.16 158.176.86.2 158.176.86.3 158.176.86.4 158.176.86.5 158.176.86.6 158.176.86.7 158.176.86.8 158.176.86.9 178.255.155.164 178.255.155.165 178.255.155.166 178.255.155.167 178.255.155.168 178.255.155.169 178.255.155.170 178.255.155.171 178.255.155.172 178.255.155.173 178.255.155.174 178.255.155.175 178.255.155.176 178.255.155.177 178.255.155.178 178.255.155.179 178.255.155.180 178.255.155.181 178.255.155.182 178.255.155.183 178.255.155.187 178.255.155.188 178.255.155.189 178.255.155.190 188.172.219.132 188.172.219.133 188.172.219.134 188.172.219.135 188.172.219.136 188.172.219.137 188.172.219.138 188.172.219.139 188.172.219.140 188.172.219.141 188.172.219.142 188.172.219.143 188.172.219.144 188.172.219.145 188.172.219.146 188.172.219.147 188.172.219.152 188.172.219.153 188.172.219.154 188.172.219.155 188.172.219.156 188.172.219.157 188.172.219.158 188.172.233.164 188.172.233.165 188.172.233.166 188.172.233.167 188.172.233.168 188.172.233.169 188.172.233.170 188.172.233.171 188.172.233.172 188.172.233.173 188.172.233.174 188.172.233.175 188.172.233.176 188.172.233.177 188.172.233.178 188.172.233.179 188.172.233.180 188.172.233.181 188.172.233.182 188.172.233.183 188.172.233.184 188.172.233.185 188.172.233.186 188.172.233.187 188.172.233.188 188.172.233.4 188.172.233.5 188.172.233.6 188.172.235.124 188.172.235.125 188.172.235.126 188.172.235.132 188.172.235.133 188.172.235.134 188.172.235.135 188.172.235.136 188.172.235.137 188.172.235.138 188.172.235.139 188.172.235.140 188.172.235.141 188.172.235.142 188.172.235.143 188.172.235.144 188.172.235.145 188.172.235.146 188.172.235.147 188.172.235.148 188.172.235.149 188.172.235.150 188.172.235.151 188.172.235.152 188.172.235.153 188.172.235.154 188.172.235.155 188.172.235.156 188.172.235.157 188.172.235.158 188.172.235.68 188.172.235.69 188.172.235.70 188.172.235.71 188.172.235.72 188.172.246.164 188.172.246.165 188.172.246.166 188.172.246.167 188.172.246.168 188.172.246.169 188.172.246.170 188.172.246.171 188.172.246.172 188.172.246.173 188.172.246.174 188.172.246.175 188.172.246.176 188.172.246.177 188.172.246.178 188.172.246.179 188.172.246.180 188.172.246.181 188.172.246.182 188.172.246.183 188.172.246.184 188.172.246.185 188.172.246.187 188.172.246.188 188.172.246.189 188.172.246.190 213.227.168.132 213.227.168.133 213.227.168.134 213.227.168.135 213.227.168.136 213.227.168.137 213.227.168.138 213.227.168.139 213.227.168.140 213.227.168.141 213.227.168.142 213.227.168.143 213.227.168.144 213.227.168.145 213.227.168.146 213.227.168.147 213.227.168.148 213.227.168.149 213.227.168.150 213.227.168.151 213.227.168.181 213.227.168.182 213.227.168.183 213.227.168.184 213.227.168.185 213.227.168.186 213.227.168.187 213.227.168.188 213.227.168.189 213.227.168.190 217.146.13.132 217.146.13.133 217.146.13.134 217.146.13.135 217.146.13.136 217.146.13.137 217.146.13.138 217.146.13.139 217.146.13.140 217.146.13.141 217.146.13.142 217.146.13.143 217.146.13.144 217.146.13.145 217.146.13.146 217.146.13.158 217.146.14.132 217.146.14.133 217.146.14.134 217.146.14.135 217.146.14.136 217.146.14.137 217.146.14.138 217.146.14.139 217.146.14.140 217.146.14.141 217.146.21.132 217.146.21.133 217.146.21.134 217.146.21.135 217.146.21.136 217.146.21.137 217.146.21.138 217.146.21.139 217.146.21.140 217.146.21.141 217.146.2.132 217.146.2.133 217.146.2.134 217.146.2.135 217.146.2.136 217.146.2.137 217.146.2.138 217.146.2.139 217.146.2.140 217.146.2.141 217.146.2.142 217.146.2.143
Como essa é uma lista extensa, com algumas centenas de IPs, é mais fácil utilizar um alias bloqueando essas faixas.
Clique em Firewall -> Aliases.
Depois clique em Add.
Dê um nome ao Alias, uma descrição, se achar necessário, e em Type, selecione Host(s).
No campo IP or FQDN iremos colocar as faixas de IPs, colocando o primeiro e último IP separados por um traço, dessa maneira:
158.176.86.2-158.176.86.16
Depois de colocar todas as faixas de IP relevantes, clique em Save.
Depois disso volte para a janela das regras para a rede Green e clique no botão Add com a seta apontando para cima.
A regra que irá bloquear o TeamViewer fica de acordo com a imagem acima.
E Action selecione Block, Interface fica como GREEN, em Protocol selecione TCP/UDP, em Source selecione GREEN net, em Destination selecione a opção Single host or alias e no campo da direita coloque o nome do alias que foi criado, com os endereços dos servidores do TeamViewer, coloque uma descrição se desejar e clique em Save.
Depois é só aplicar a regra, com isso o TeamViewer está bloqueado.
Na imagem acima podemos ver que o TeamViewer já não consegue mais se conectar.
Essa regra deve ser aplicada apenas em dias e horários específicos, para isso iremos criar um agendamento para que seja aplicada apenas quando necessário.
Clique em Firewall -> Schedules.
Clique em Add.
Aqui podemos fazer isso de duas maneiras, selecionar os dias úteis e o horário de trabalho, e aplicar esse horário em uma nova regra que irá permitir a conexão e que irá estar ativa apenas durante esses dias e horas, enquanto a regra que bloqueia continua ativa o tempo todo, ou criar algumas faixas de horários especificando quando essa regra que bloqueia o TeamViewer vai estar ativa, finais de semana e fora do horário de trabalho, e assim utilizar apenas uma regra no firewall.
Aqui irei fazer da segunda maneira, para isso será necessário três faixas diferentes, a primeira será de Segunda à Sexta, da meia noite (00:00) até as oito da manhã (8:00), a segunda também de Segunda à Sexta, mas dessa vez das seis da tarde (18:00) até a meia noite (tecnicamente não é até a meia noite, já que uma faixa de horário não pode terminar em um horário menor do que o que foi iniciado, nesse caso ficará até as 23:59), e a terceira ocupara os finais de semana inteiros (0:00 até 23:59).
Para selecionar os dias não é preciso clicar um a um, clique na parte de cima onde tem os nomes dos dias da semana: Mon, Tue, Wed…, fazendo isso irá selecionar automaticamente todos os dias da semana, não só no mês atual como nos meses seguintes, dessa maneira não é preciso criar regras para todos os meses (quando os dias selecionados estão com a cor azul, essa seleção é aplicada a todos os meses seguintes, quando estão a verde é apenas para o mês atual).
As faixas de horários devem ficar como na imagem acima.
Depois que terminar a criação da faixa de horários, clique em Save.
Com isso já temos essa faixa de horários criada, agora é só a aplicar na regra do firewall que está sendo utilizada para bloquear o TeamViewer.
Para editar a regra clique no ícone de um lápis, do lado direito, na regra a ser editada, nesse caso é a regra que bloqueia o TeamViewer.
Em Extra Options, clique em Display Advanced.
Em Schedule, selecione o horário que foi acabado de ser criado, nesse caso ele se chama TeamViewer.
Depois clique em Save, no final da página.
Aqui podemos ver que o horário foi aplicado com sucesso à regra.
E aqui podemos ver que o TeamViewer está funcionando.
Port Forwarding
Port Forwarding permite que uma porta, faixa de portas ou protocolo seja exposto a um IP privado em uma das redes internas.
Aqui iremos redirecionar duas portas externas, para portas específicas, e diferentes, para um host em uma rede interna. As portas 22222 e 42424 serão redirecionadas para as portas internas 61234 e 56789 respectivamente, e serão apontadas para o IP 10.18.170.2, que está na rede Orange e tem um webserver.
Para criar essa regra clique em Firewall -> NAT.
Para criar uma nova regra clique no botão Add.
Aqui iremos configurar a regra.
Como essa porta será exposta ao exterior, em Interface precisamos selecionar WAN.
Não estamos utilizando IPv6, por isso em Address Family certifique-se de que tem IPv4 selecionado.
Essa porta será utilizada apenas para fráfego web, por isso em Protocol selecione apenas TCP, não será preciso UDP nesse caso.
Em Destination selecione WAN address, isso fará com que o firewall redirecione essas portas quando algum cliente externo as tente acessar através do IP da interface WAN.
Em Destination port range, nos dois campos Custom, coloque o número da porta que será aberta na interface WAN, nesse caso será a porta 22222.
E em Redirect target IP selecione Single host e coloque o IP do webserver, que nesse caso será 10.18.170.2.
Em Redirect target port selecione a opção Other e em Custom coloque o número da porta que o host está esperando, nesse caso a porta 61234.
Dê uma descrição e clique em Save.
Da mesma maneira que as regras do firewall que foram criadas até agora, também é preciso aplicar as alterações, clique em Apply Changes, com isso já temos a primeira porta redirecionada.
Agora é só repetir esses passo para a outra porta.
Com isso já temos as duas portas redirecionadas, agora é só as testar para confirmar que está tudo funcionando corretamente.
Utilizando um cliente na WAN podemos ver que o redirecionamento está funcionando corretamente, aqui o servidor está pedindo autenticação para permitir o acesso à página.
Após a autenticação a página é carregada corretamente.
A mesma coisa para a porta 42424, redirecionamento feito com sucesso.
Instalar OPNsense
O processo de instalação do OPNsense é similar ao do pfSense, depois de terminada a instalação é preciso fazer a configuração inicial das interfaces de rede.
As interfaces serão configuradas de maneira similar a como foi feito no pfSense:
00:50:56:3C:1A:10 - R2/WAN - 10.155.170.2/30 00:50:56:3C:1A:11 - Green - 10.53.170.1/24 00:50:56:3C:1A:12 - Blue - 10.120.170.1/29 00:50:56:3C:1A:13 - Sync - 192.168.255.253/30 00:50:56:3C:1A:14 - Host - 10.10.10.21/24
O primeiro passo é configurar o papel das interfaces, para isso é só selecionar a opção número 1.
Depois disso será perguntado se desejamos configurar LAGG, ou Link Aggregation, isso não será necessário nesse momento, selecione n, a mesma coisa para VLANs, não serão necessárias.
As interfaces são selecionadas utilizando os seus nomes, e podem ser identificadas através dos endereços MAC.
Após selecionar as interfaces, confirme que deseja continuar.
Depois de selecionar as interfaces é preciso configurar alguns endereços de IP, para que seja possível acessar a interface web.
Selecione a opção 2 para configurar o IP de uma interface.
Primeiro introduza o IP da interface, depois a máscara de rede, e por fim o endereço do Gateway utilizado para acessar outras redes externas.
Não iremos utilizar o Gateway como DNS, selecione outro servidor DNS.
Não iremos utilizar IPv6, mas caso seja necessário, pode fazer essa configuração agora, também não iremos alterar o protocolo da interface web de http para https.
Após terminar de escolher as configurações desejadas é só aguardar um pouco para que essas configurações sejam aplicadas.
Depois disso é só repetir os mesmos passos para outras interfaces que deseje configurar já.
Caso deseje acessar a interface web através da interface LAN, pode utilizar o endereço de IP pré configurado, mas caso queira utilizar outra interface será preciso desativar temporariamente o firewall, assim como foi feito no pfSense.
Após desativar o firewall temporariamente já podemos acessar a interface web tanto pela interface WAN como pela interface OPT3 (Host).
Com isso já podemos continuar a configuração através da interface web.
O login pode ser feito com as mesmas credenciais que foram utilizadas durante a instalação e configuração inicial.
O processo de configuração inicial será iniciado, ele é muito similar ao processo do pfSense.
Aqui é possível configurar o hostname do firewall, assim como o domínio e outras configurações de DNS, após fazer as configurações adequadas clique em Next.
Selecione o fuso-horário de onde está e time servers que deseja utilizar e clique em Next.
Aqui não tem muito o que fazer, a única alteração é desselecionar as opções que bloqueiam redes privadas e similares na interface WAN, como foi feito no pfSense, depois disso clique em Next.
Aqui não tem nada a ser feito, o resto das configurações dessa rede serão feitas mais tarde, clique em Next.
Caso deseje alterar a senha da conta root pode o fazer aqui, depois disso clique em Next.
Com essa configuração inicial terminada, clique em Reload, tenha atenção que caso esteja acessando a interface web por uma interface que não seja a LAN, isso irá reativar o firewall, fazendo com que o acesso à interface web seja bloqueado novamente, por isso será necessário o desativar novamente na shell.
Como foi feito no pfSense, irei criar uma regra para permitir o acesso à interface web através da interface OPT3/Host, para isso clique em Firewall -> Rules -> OPT3.
Aqui temos a página com as regras para essa interface. Nesse momento ainda não temos nenhuma regra, para criar a nova regra clique no botão laranja com um ➕.
Similar à regra criada no pfSense, em Action selecione Pass, para permitir o tráfego, a interface é OPT3, em Direction selecione in.
Não vamos utilizar IPv6, por isso em TCP/IP Version selecione IPv4, em Protocol pode deixar como any, mas caso queira restringir um pouco mais, pode selecionar TCP.
Em Source selecione OPT3 net, isso irá permitir tráfego originado de máquinas originadas dessa rede, e não de redes diferentes, que por acaso cheguem através dessa interface, e em Destination selecione OPT3 address, para que apenas tráfego destinado ao IP dessa interface passe, não queremos que nenhuma outra máquina esteja acessível através dessa interface.
Dê uma descrição à regra e clique em Save.
Clique em Apply changes para aplicar a regra.
Isso pode demorar alguns instantes até que a regra esteja ativa, por isso é normal que a página não carregue, mas após alguns instantes já deve ter acesso à interface web através dessa interface.
Agora iremos alterar os nomes das interfaces, para que tenham nomes mais descritivos, vamos começar pela interface LAN, para isso clique em Interfaces -> [LAN].
Em Description coloque o nome que deseja dar a interface, nesse caso irá se chamar Green, depois disso clique no botão Save no final da página.
Clique em Apply changes para aplicar a nova configuração.
A interface Blue não estava ativa e nem tinha IP definido, nesse caso, para a habilitar, marque a opção Enable Interface em Enable, em Description dê o nome que desejar à interface, nesse caso será Blue, em IPv4 Configuration Type selecione Static IPv4 e em IPv4 address coloque o endereço de IP que deseja usar nessa interface, depois disso clique em Save.
Repita o processo para as outras interfaces.
Aqui podemos ver que todas as interfaces já estão configuradas.
DHCP no OPNsense
Foi pedido para fornecer IPs por DHCP, mas não foi especificado em qual das redes, por isso isso será feito apenas na rede Green, entretanto, caso seja preciso em outra rede, o processo é o mesmo.
![Services - DHCPv4 - [Green]](https://wordpress.pedrorotoli.com/wp-content/uploads/2022/02/189-Services-DHCPv4-Green.png)
Aqui podemos ver que o servidor DHCP não está ativo nessa interface.
O primeiro passo é o ativar, para isso marque a opção Enable DHCP server on the Green interface, em Enable.
Em Range é possível definir a faixa de IPs que serão utilizados para a atribuição de IPs, e caso queira criar diferentes pools, com diferentes faixas de IP, pode o fazer clicando no ícone laranja com um ➕, em Additional Pools.
Em DNS servers pode configurar os servidores DNS que deseja atribuir aos clientes, e em Gateway coloque o IP dessa própria interface.
Clique em Save no final da página para salvar as configurações e ativar o servidor DHCP.
O servidor DHCP está funcionando como esperado, o cliente Windows recebeu um IP sem problemas.
Na imagem acima podemos ver a lista de leases no OPNsense.
Bloquear domínios .de
Foi pedido para bloquear sites com o tld .de, isso pode ser feito de algumas maneiras diferentes, as mais comuns são DNS e proxy, sendo a primeira menos intrusiva e simples, mas relativamente fácil de ser contornada caso o usuário tenha privilégios administrativos na máquina cliente que esteja utilizando, e a segunda mais garantida, mas mais complexa, além de ser mais onerosa para o firewall e colocar em questão a privacidade dos usuários.
Como foi feito com o pfSense, aqui será feito esse bloqueio através de proxy.
Clique em System -> Trust -> Authorities.
Como foi feito no pfSense, é preciso criar uma autoridade certificadora, que irá emitir os certificados dos websites que serão acessados pelos clientes.
Aqui serão preenchidos os dados para criar a autoridade que irá gerar os certificados.
Da mesma maneira que foi feito no pfSense, é importante que não existam ambiguidades no nome e descrição da autoridade, não tentar enganar os usuários e deixar claro que o tráfego está sendo interceptado.
Em Descriptive name dê um nome que seja descritivo da finalidade dessa CA, em Method selecione Create an internal Certificate Authority.
Os próximos campos, até Country Code podem ficar com as configurações padrão, e caso queira que essa CA tenha uma vida mais longa, pode aumentar o valor no campo Lifetime (days).
Preencha os campos em Distinguished name de acordo com a localização e nome da organização, e em Common Name dê um nome adequado.
depois disso clique em Save.
Com isso já temos a autoridade certificadora criada e pronta para emitir novos certificados.
E da mesma maneira que foi feito no pfSense, é preciso exportar o certificado para que seja instalado nas máquinas cliente, para que os certificados gerados pelo firewall para os websites sejam aceitados pelos clientes.
A exportação do certificado pode ser feita clicando no ícone do com uma seta ⬇ apontando para baixo, do lado do ícone de um lápis.
Com isso já podemos fazer a configuração do proxy no OPNsense.
Clique em Services -> Web Proxy -> Administration.
Aqui temos a página de configuração do proxy.
O primeiro passo é o habilitar, marque a opção Enable proxy e clique no botão Apply.
Clique na aba Forward Proxy.
É aqui que iremos configurar o proxy transparente.
Aqui é preciso selecionar as opções Enable Transparent HTTP proxy e Enable SSL inspection, as portas podem ficar como estão, e em CA to use selecione a CA que foi criada anteriormente, clique em Apply.
Se habilitar a opção full help, no canto superior direito, vai ver onde o proxy transparente e a inspeção de tráfego SSL foi habilitada, tem um link para criar uma regra de firewall, cada um deles irá criar uma regra diferente, um para a porta 80, para tráfego http, e outro para a porta 443, para tráfego https.
O primeiro link cria uma regra para direcionar o tráfego direcionado à porta 80, não é preciso fazer nenhuma alteração nessa regra, apenas clique em Save.
Mesma coisa para a regra de direcionamento da porta 443.
Com as duas regras ativas o proxy já deve estar funcionando para os clientes.
Aqui podemos ver que o proxy está funcionando corretamente no cliente.
Agora é preciso bloquear o acesso aos websites com o tld .de, da Alemanha.
Voltando à página de configuração do proxy, na aba Forward Proxy, clique no ícone de um triângulo apontando para baixo 🔻, e na lista clique em Access Control List.
Aqui podemos fazer várias configurações referentes a ACLs, whitelists, blacklists, etc…
Para bloquear os TLDs .de é só colocar a seguinte expressão regular no campo Blacklist:
.+\.de
Depois disso clique em Apply.
Aqui podemos ver que os domínios foram bloqueados com sucesso.
VPN IPsec Entre OPNsense e pfSense
IPsec, ou Internet Protocol Security, é um dos tipos de VPN disponíveis, e relativamente simples de ser configurado no OPNsense e pfSense.
Iremos configurar um túnel site to site, ou seja, uma ligação entre duas, ou mais, redes remotas, que geralmente são utilizadas para fazer a ligação entre filiais e matriz.
Para começar, clique em VPN -> IPsec -> Tunnel Settings.
É nessa página que iremos iniciar as configurações do túnel IPsec.
O primeiro passo é clicar no botão laranja com um ➕, que está do lado direito da tela, em Phase 1.
Aqui iremos configurar a primeira fase da conexão, que vai cuidar da troca de chaves e parâmetros criptográficos da conexão.
Aqui iremos configurar a primeira parte da ligação, os primeiros campos podem ficar com as configurações padrão, em Connection method deixe como default, Key Exchange version (IKE – Internet Key Exchange) fica como V2, Internet Protocol vai ficar como IPv4 e Interface como WAN.
Em Remote gateway é preciso colocar o IP público do outro roteador, será esse IP que o OPNsense irá utilizar para encontrar o roteador remoto através da internet, aqui ficará com o IP 10.155.170.10.
Em Description coloque algo descritivo que identifique facilmente essa ligação.
Authentication method ficará como Mutual PSK (pre-shared key), significa que iremos utilizar uma senha para fazer a autenticação.
O mais seguro seria utilizar um certificado, entretanto, para simplificar, e para efeitos de demonstração da criação do túnel, será utilizada uma senha para a autenticação.
Em My identifier deixe como My IP address, mesma coisa em Peer Identifier, deixe como Peer IP address.
Em Pre-Shared Key coloque a senha que será utilizada para fazer a autenticação, essa senha deverá ser a mesma dos dois lados.
Em Encryption algorithm temos várias opções, aqui foi selecionada a opção 256 bit AES-GCM with 128 bit ICV porque permite a paralelização da encriptação, tendo assim melhor performance se o sistema tiver várias threads de processamento, selecione o algorítmo mais adequado à situação em que se encontre.
Em Hash algorithm selecione qualquer um, menos MD5 e SHA1, esses algorítmos são extremamente antiquados e considerados “quebrados”, aqui foi selecionado SHA256.
O resto das opções podem ficar como estão, não é preciso fazer mais nenhuma alteração.
Com essa configuração terminada, clique em Save.
Com isso temos a primeira fase terminada, clique em Apply changes antes de continuar, depois clique no ícone laranja com um ➕ que está do lado direito da entrada que acabamos de completar, isso irá iniciar a configuração da segunda fase.
Aqui iremos configurar a segunda parte do túnel, responsável pela encriptação dos dados a ser transmitidos e os endpoints da ligação, quais redes serão conectadas.
Essa configuração é mais simples, em Description dê uma descrição adequada, na seção Local Network iremos definir a rede local que será o endpoint local, em Type temos selecionada a opção Green subnet, para que a rede Green tenha acesso à rede remota.
Em Remote Network iremos identificar qual será a rede remota, em Type selecione Network e em Address coloque o endereço da rede, que nesse caso é a rede Green do pfSense.
Abaixo, em Protocol, selecione ESP.
Em Encryption algorithms temos várias opções, AES128-256, aes128-256gcm16 e NULL, caso selecione uma das três primeiras opções, AES128-256, também será preciso selecionar um Hash algorithm abaixo, para as próximas três já não é preciso, e a última opção não encripta os dados, e obviamente não é recomendada, e o resto das opções não serão necessárias nesse momento, podem ficar com as opções padrão.
Depois de terminar a configuração clique no botão Save.
Com isso já temos as configurações do túnel feitas no OPNsense, para que o túnel esteja ativo e pronto a receber ligações, selecione a opção Enable IPsec e clique em Apply changes, o último passo é criar uma regra no firewall para permitir o tráfego através dessa ligação.
Clique em Firewall -> Rules -> IPsec.
Aqui iremos criar uma regra para essa nova interface, da mesma maneira que foi feita anteriormente, clique no ícone laranja com um ➕ que está do lado direito.
Caso preciso de uma regra mais específica, pode a configurar de acordo com as suas necessidades, nesse caso, apenas para demonstrar a funcionalidade, foi criada uma regra que permite todo o tráfego.
Agora é preciso replicar essas configurações no pfSense.
No pfSense, clique em VPN -> IPsec.
Aqui podemos criar as VPNs IPsec, e ver as já existentes.
Para criar um novo túnel clique em Add P1.
As opções aqui são muito similares às que encontramos no OPNsense, mas com algumas diferenças na maneira como são apresentadas.
Em Description dê uma descrição adequada à ligação, como foi feito no OPNsense.
Na seção IKE Endpoint Configuration temos uma diferença em relação ao OPNsense, lá, em Key Exchange Version, tinhamos as opções V1 e V2, por exemplo, fazendo mencionando apenas a versão do protocolo, aqui temos o seu nome completo, IKEv1 e IKEv2, como selecionamos V2 no OPNsense, iremos selecionar a opção IKEv2 aqui no pfSense, o resto das opções são iguais, com a única diferença no Remote Gateway, que aqui obviamente irá apontar para o IP externo do OPNsense.
Da mesma maneira que foi configurada no OPNsense, em Phase 1 Proposal (Authentication), iremos usar as opções Mutual PSK, My IP address, Peer IP address e em Pre-Shared Key, a senha que foi usada no OPNsense.
Em Phase 1 Propostal (Encryption Algorithm) é preciso selecionar o mesmo algorítimo que foi selecionado no OPNsense, tenha apenas atenção que aqui essa configuração é apresentada de maneira diferente. Como foi selecionado no OPNsense, selecione AES256-GCM, 128 bits, SHA256 e por último, 14 (2048 bit).
O resto das configurações pode ficar com as opções padrão, depois de terminar a configuração clique em Save.
Com isso já temos a primeira fase criada, agora iremos criar a segunda fase, para isso clique no botão Show Phase 2 Entries.
Para criar a segunda fase clique no botão Add P2.
Aqui a configuração deverá, novamente, seguir a que foi feita anteriormente no OPNsense.
Em Description dê uma descrição adequada, e em Mode, certifique-se de Tunnel IPv4 está selecionado, como está no OPNsense.
Desse lado, a rede que será ligada será a Green, por isso, em Local Network, selecione GREEN subnet, e em Remote Network coloque o endereço da rede remota, que no caso do OPNsense é a sua rede Green, com o endereço 10.25.170.0/24.
Na seção Phase 2 Proposal (SA/Key Exchange) é preciso selecionar o mesmo protocolo e algorítimos que foram selecionados no OPNsense, por isso em Protocol selecione a opção ESP e em Encryption Algorithms selecione apenas a opção AES256-GCM de 128 bits, como foi feito no OPNsense, caso seja preciso mais algorítimos para acomodar outros endpoints com configurações diferentes, pode selecionar os algorítimos e configurações relevantes.
Como o único algorítimo que selecionamos foi o AES256-GCM, não só não é preciso selecionar um Hash Algorithm, como essas opções estão desativadas.
Não é preciso fazer nenhuma alteração nas configurações seguintes, clique em Save para salvar essas configurações.
Com isso já temos o túnel IPsec configurado no pfSense, e como foi feito no OPNsense, aqui também será preciso criar uma regra no firewall para permitir o tráfego através dessa conexão, por isso vá até as regras do firewall para a ligação IPsec, da mesma maneira que foi feito para as outras regras que foram criadas.
Novamente, caso seja preciso alguma configuração específica, pode o fazer da mesma maneira como qualquer outra regra, aqui foi criada apenas uma regra que permite todo o tipo de tráfego apenas para demonstrar a ligação.
Com isso já podemos verificar o estado do túnel, para isso clique em Status -> IPsec.
E aqui podemos ver que a ligação foi estabelecida com sucesso.
Na imagem acima podemos ver um cliente ligado à rede Green do OPNsense acessando uma partilha de rede no Windows Server que está na rede Green do pfSense.
VPN OpenVPN Entre OPNsense e pfSense
Agora iremos criar uma VPN utilizando o OpenVPN, para isso será preciso primeiro desligar a ligação através de IPsec.
Para desligar esse túnel é só desselecionar a opção Enable IPsec e clicar em Apply changes.
Com isso já podemos inicar a configuração da VPN OpenVPN.
Em um túnel IPsec são configurados os endpoints para que possam estabelecer uma ligação entre si, no caso de uma ligação OpenVPN, é preciso configurar um Servidor e um Cliente, qualquer um dos roteadores pode fazer o papel de Cliente ou Servidor, aqui o OPNsense será configurado como Servidor e o pfSense como cliente.
Iremos iniciar a configuração pelo OPNsense, para isso clique em VPN -> OpenVPN -> Servers.
Agora iremos configurar o Servidor, para isso clique no ícone laranja com um ➕ que está do lado direito.
Nessa página será configurado o servidor.
A configuração aqui será relativamente simples, será preciso dar uma descrição para o servidor, selecionar a interface, certificados, algorítmos de hashing e endereços das redes a serem conectadas e a rede utilizada para fazer essa ligação.
Em Description dê uma descrição adequada a esse servidor OpenVPN, em Interface selecione WAN, já que o servidor irá receber a conexão remota através dessa interface, a porta pode ficar a que está.
Em Cryptographic Settings, podemos deixar a maior parte dos campos com as configurações padrão, devemos apenas alterar a opção Auth Digest Algorithm para SHA256 ou melhor, por questões de segurança.
Em IPv4 Tunnel Network coloque o endereço de uma rede que não esteja a ser utilizada pelo firewall e nem pelos clientes remotos, para evitar conflitos, o número de IPs disponíveis para hosts vai depender de quantos clientes irão se ligar a esse servidor, aqui, como não teremos muitos clientes, apenas 3 bits serão suficientes.
Em IPv4 Local Network coloque o endereço da rede local que deseja expor à VPN, e em IPv4 Remote Network o endereço da rede remota que será ligada à rede local.
Com isso a configuração está completa.
Com isso já temos o servidor configurado, agora precisamos apenas de mais um passo desse lado, copiar a chave TLS que iremos utilizar no cliente que irá se conectar, para isso clique no botão com um ícone de um lápis, do lado direito.
Iremos precisar da chave no campo TLS Shared Key.
Com o servidor configurado e a chave identificada, é preciso criar uma regra no firewall para permitir a conexão através da interface WAN.
Será preciso criar uma regra permitindo a ligação de clientes remotos através da interface WAN.
Essa regram é simples, ela será aplicada à interface WAN e a direção é in, já que irá servir para aceitar ligações externas, o protocolo é UDP, que é o que foi configurado no servidor OpenVPN.
Em Source temos algumas opções diferentes, podemos restringir a um único endereço de IP ou permitir a ligação à partir de qualquer IP, sendo uma ligação site-to-site, o ideal é restringir apenas a um único IP, mas para facilitar, ficara como any, permitindo ligações de qualquer endereço.
Em Destination coloque WAN address, e em Destination port range, selecione OpenVPN.
Dê uma descrição para a regra e depois clique em Save, e aplique a regra.
Com isso podemos iniciar a configuração no pfSense.
No pfSense clique em VPN -> OpenVPN.
Na aba Clients clique no botão Add.
Em Description dê um nome adequado à ligação, abaixo, em Server mode, selecione Peer to Peer (Shared Key), como foi configurado no OPNsense, mais adiante iremos utilizar a chave gerada pelo OPNsense.
Em Server host or address coloque o IP externo do OPNsense, que nesse caso é 10.155.170.2, o resto nessa seção pode ficar como está.
Em Cryptographic Settings é preciso configurar da mesma maneira que está configurado o servidor no OPNsense.
Desselecione a opção Auto generate e no campo Shared Key que irá aparecer logo abaixo coloque a chave gerada pelo OPNsense.
Em Data Encryption Algorithms é preciso selecionar a opção que foi configurada no OPNsense, não é preciso selecionar outros algorítmos, apenas o que o servidor irá utilizar, que nesse caso é AES-128-CBC (128 bit key, 128 bit block), e em Fallback Data Encryption Algorithm pode selecionar o mesmo, não fará diferença, já que o servidor está configurado para utilizar um único algorítmo, e esse cliente irá se conectar exclusivamente ao OPNsense, por isso não é preciso suportar algorítmos diferentes.
Em Auth digest algorithm selecione o mesmo que foi selecionado no OPNsense, que nesse caso é o SHA256.
Em Tunnel Settings será preciso configurar apenas dois campos, IPv4 Tunnel Network, com a mesma rede que foi configurada no OPNsense, e IPv4 Remote network(s), que será o endereço da rede do OPNsense que ficará acessível através da VPN, que aqui será a rede 10.53.170.0/24.
A última opção a ser configurada será Gateway creation, que deve ser alterada de Both para IPv4 only, depois disso clique em Save.
E com isso já temos o cliente configurado, agora será preciso voltar ao OPNsense.
Na Dashboard do OPNsense, em Services, podemos ver que o serviço openvpn não está ativo, clique no botão play para o iniciar, depois disso será preciso criar uma regra no firewall para permitir o tráfego através dessa ligação.
As regras para essa interface funcionam da mesma maneira que as regras criadas anteriormente, caso seja necessário pode criar regras para permitir apenas o mínimo necessário, nesse caso, para facilitar o processo, foi criada uma regra que permite qualquer tipo de tráfego.
Na imagem acima podemos ver que o túnel OpenVPN está conectado com sucesso, enquanto o túnel IPsec está desligado.
Da mesma maneira que foi feito para a ligação IPsec, será preciso criar uma regra no pfSense para permitir o tráfego através to túnel OpenVPN.
Novamente, para simplificar, foi criada uma regra que permite todo tipo de tráfego, em uso real é preciso criar regras apropriadas para o uso pretendido.
Acesso ao Windows Server por Remote Desktop através da VPN funcionando.
Remote Users
Com as VPNs site-to-site configuradas, agora é preciso configurar a VPN para remote users.
Também é preciso um certificado para esse tipo de ligação, podemos utilizar o mesmo certificado que foi usado anteriormente, ou criar um novo, vamos criar um novo para haver alguma distinção, começando pela Certificate Authority.
Com a nova Certificate Authority criada, já é possível criar o novo certificado.
Com o certificado criado podemos tratar da autenticação dos users, essa autenticação será feita através Windows Server, para que apenas os users autorizados possam ter acesso remoto através da VPN.
Clique em System -> User Manager.
Depois em Authentication Servers, aqui iremos configurar o acesso às contas da AD pelo firewall, para que a autenticação possa ser feita, para isso clique em Add.
Acima temos a configuração necessária para se conectar e autenticar com o Windows Server, o conteúdo do campo Authentication containers (distinguishedName) vai depender da estrutuda da AD, e o caminho pode ser encontrado utilizando a ferramenta ADSI Edit no Windows Server.
Depois de colocar o distinguishedName clique em Select a container.
Selecione os containers adequados e clique em Save, depois novamente em Save no final da página.
Agora será preciso criar um novo servidor OpenVPN.
No mesmo local onde foi criado o cliente OpenVPN, mas dessa vez na aba Servers, clique em Add, para adicionar o servidor OpenVPN.
Acima temos a configuração do servidor para esse cenário.
Já temos o servidor criado, agora será preciso criar algumas regras no firewall para permitir as ligações dos clientes.
Com a regra criada agora é preciso instalar um pacote para exportar as configurações para os clientes, para que possam se conectar.
O processo de instalação é o mesmo que foi feito anteriormente, pesquise por “openvpn” e instale o pacote chamado openvpn-client-export.
Depois será preciso criar uma nova conta no firewall, para que as configurações possam ser exportadas, para isso clique em System -> User Manager.
Clique em Add.
Essa nova conta não será utilizada para acessar a interface web, ou para qualquer tipo de acesso direto ao firewall, por isso deve ser desativada, para isso selecione a opção Disabled – This user cannot login.
Preencha os campos como achar melhor, e em Certificate, selecione a opção Click to create a user certificate, depois selecione a CA que foi criada anteriormente para a VPN e dê um nome adequado ao certificado, depois clique em Save.
Com isso já temos a nova conta criada.
Nas configurações da OpenVPN, clique na aba Client Export.
Aqui não será preciso fazer nenhuma alteração, apenas clique no botão Save as default no final da página.
Logo no final da página temos várias opções de configurações e clientes para fazer o download, aqui iremos utilizar o cliente Windows de 64-bits, faça o download para a máquina que irá se conectar à VPN.
Inicie a instalação do cliente OpenVPN no cliente que irá fazer o acesso remoto.
Uma nova janela irá abrir para continuar a instalação, clique em Install.
Após a instalação terminar, o ícone do cliente OpenVPN irá aparecer na bandeja de sistema, clique com o botão direito sobre ele e selecione a opção Connect.
Faça a autenticação com uma conta adequada.
A ligação foi feita com sucesso.
Aqui podemos ver que temos acesso ao servidor.
Agora é preciso restringir o acesso à VPN durante o período das 8-20h, para isso será preciso criar um novo agendamento, da mesma maneira que foi feita com o TeamViewer.
Com o agendamento criado já é possível o aplicar à regra do firewall.
O agendamento foi aplicado, agora já não será mais possível se conectar fora do horário especificado.
O cliente já não consegue mais fazer a ligação.
Entretanto, ainda não temos o proxy funcionando através da VPN, para isso será preciso primeiro o habilitar na interface da VPN.
Clique em Interfaces -> Assignments.
Em Available network ports selecione a segunda opção, ovpns2 (RemoteClients) e clique em Add.
A interface foi adicionada com o nome OPT5, clique sobre ela para a habilitarmos e alterar seu nome.
Selecione a opção Enable interface e em Description dê um nome adequado.
Depois será preciso parar o serviço OpenVPN temporariamente, para isso clique em Status -> OpenVPN.
Aqui podemos ver o status dos clientes e servidores, para parar o serviço, clique no botão com o símbolo ⏹, em Actions.
Com isso temos o serviço parado.
Adicione uma regra de firewall que permite todo o tráfego na interface OpenVPNServer.
Agora será preciso fazer com que os clientes remotos utilizem o proxy, para isso acesse a página de configuração do Squid Proxy e nos campos Proxy Interface(s), Transparent Proxy Interface(s) e SSL INtercep Interface(s), selecione a interface OpenVPNServer, depois clique em Save no final da página.
Depois, em ACLs, adicione a rede que selecionou para a VPN no campo Allowed Subnets, e novamente, clique em Save no final da página.
Depois disso volte para Status -> OpenVPN e inicie novamente o serviço.
Aqui podemos ver que o proxy está funcionando corretamente.
Remote Users OPNsense
Vamos agora configurar uma VPN para mobile clients no OPNsense, para que tenha acesso à rede Green (10.52.170.0/24).
Como foi feito no pfSense, iremos precisar de um certificado para o servidor OpenVPN.
Vá em System -> Trust -> Authorities.
Aqui podemos ver a CA que criamos anteriormente para o proxy, podemos utilizar essa mesma CA, mas para distinguir entre os dois usos, vamos criar uma nova, da mesma maneira que foi feito anteriormente.
Com a nova CA criada já podemos gerar um novo certificado.
No momento temos apenas um certificado, clique no botão ➕ para criar um novo certificado.
Aqui, o importante é, em Certificate authority, selecionar a CA que foi acabada de criar, em em Type, selecionar Server Certificate, o resto da informação pode ficar como achar melhor.
Com isso já temos o novo certificado criado, agora é preciso criar a nova conta de usuário que irá ser utilizada para fazer a autenticação do cliente.
Vá em System -> Access -> Users e clique no ícone ➕ para adicionar uma nova conta.
Especifique o username e senha e clique em Save and go back no final da página.
Com a nova conta criada, clique no ícone do lápis ✏ do lado direito, para editar a conta recém criada.
EM User Certificates, clique no botão ➕ para gerar um novo certificado.
Em Certificate authority selecione a CA que foi criada para esse fim, e em Type selecione Client Certificate, o resto das configurações podem ficar como achar melhor.
Com isso já temos o certificado para esse user, clique em Save and go back.
Agora iremos criar o servidor OpenVPN para os clientes remotos, como foi feito antes, vá em VPN -> OpenVPN -> Servers e clique no ícone ➕ para criar um novo servidor.
Dê uma descrição adequada ao servidor, em Server Mode selecione a opção Remote Access (User Auth), e em Backend for authentication selecione Local Database, para que a autenticação seja feita com os users do próprio firewall, o resto da configuração dessa parte é igual à que foi feita anteriormente, o firewall automaticamente seleciona a porta 1195, já que a porta 1194 já está em uso pelo outro servidor OpenVPN que foi configurado anteriormente.
Nas configurações criptográficas selecione a CA que foi criada para esse fim, OpenVPN-CA, em Peer Certificate Authority, e em Server Certificate selecione o certificado que foi criado para esse servidor OpenVPN.
O resto das configurações, como o algorítmo e chaves, devem ser escolhidos levando em conta o nível de segurança desejado e as capacidades do sistema.
Em IPv4 Tunnel Network especifique uma rede que não esteja em uso, ou acessível, pelo firewall, essa será a rede que será utilizada no túnel que faz a ligação entre o cliente e o firewall.
Habilite a opção Redirect Gateway para que o cliente acesse a internet através do firewall.
Selecione a opção Dynamic IP e Address Pool, também selecione a opção DNS Servers e configure os servidores DNS que o cliente irá utilizar.
Nessa parte não é preciso fazer nenhum tipo de configuração especial, o que pode fazer é alterar o Verbosity level para ter mais ou menos informações nos logs, caso seja necessário, depois disso clique em Save.
Com isso já temos o novo servidor OpenVPN configurado e ativo na porta 1195, como foi feito com o outro, é preciso criar uma regra no firewall na interface WAN para permitir a ligação através dessa porta.
Com a regra criada podemos ir para o próximo passo, exportar a configuração para o cliente que irá se conectar ao servidor.
Vá em VPN -> OpenVPN -> Client Export.
Aqui, em Remote Access Server selecione o servidor que acabamos de criar, em Export type selecione Archive.
Existem várias opções diferentes de tipos de configurações que podem ser exportadas, a opção Archive exporta a configuração necessária para se utilizar o cliente OpenVPN que já está instalado no cliente.
Mais abaixo na página temos as opções que podem ser exportadas, clique no ícone ☁ para o user mdafe para exportar a configuração.
Para importar a configuração no cliente é só abrir a pasta onde o cliente OpenVPN vai buscar as configurações, o local dessa pasta pode ser encontrado nas configurações do cliente.
Extraia o conteúdo do arquivo .zip para dentro dessa pasta.
Com a configuração importada já podemos nos conectar ao servidor OpenVPN no OPNsense, dessa vez o cliente irá mostrar as configurações disponíveis, em vez de apenas dar a opção para se conectar, quando havia apenas uma configuração.
Faça a autenticação utilizando as credenciais do user que foi criado no firewall.
A ligação foi feita com sucesso.
Aqui podemos ver que o cliente tem acesso à internet e que o tráfego está passando pelo firewall.
Captive Portal no pfSense
Agora iremos configurar um Captive Portal na rede Blue do pfSense.
Para isso será preciso configurar um servidor DHCP para que os clientes possam receber um IP automaticamente, e o acesso à internet será condicionado, tendo a velocidade e volumes de dados transferidos limitados.
Clique em Services -> DHCP Server.
Selecione a aba BLUE para configurar o servidor DHCP na interface Blue.
Selecione a opção Enable para habilitar o serviço, em Range defina o início e o fim da faixa de IPs que serão atribuídos aos clientes.
Também será preciso configurar o serviço para que os clientes usem o firewall como servidor DNS, mais abaixo, em DNS servers, coloque o IP da interface Blue do firewall, e depois disso clique no botão Save no final da página.
Crie duas regras no firewall para a interface Blue, uma permitindo o acesso à internet e outra que bloqueia o acesso a qualquer servidor DNS que não seja o próprio firewall, na ordem que está na imagem acima.
Agora iremos configurar o Captive Portal, clique em Services -> Captive Portal.
Clique em Add para iniciarmos a criação da zona para a rede Blue.
Dê um nome e uma descrição apropriados e clique Save & Continue.
Antes de habilitar e iniciar a configuração da zona, vamos criar um novo certificado para a página de autenticação do Captive Portal.
Crie um certificado para um endereço que será utilizado na página de autenticação, nesse caso o endereço é captiveportal.rotolip.local, mas pode ser qualquer endereço que queira, não precisa ser do domínio do Windows Server.
Voltando para a página de configuração do Captive Portal, clique no ícone do lápis ✏ para entrar no modo de edição.
Selecione a opção Enable para abilitar o Captive Portal, e em Interfaces selecione a interface BLUE.
Em Traffic quota (Megabytes) podemos definir a quantidade máxima de dados transferidos por sessão, nesse caso serão 500MB.
Caso queira que os users sejam redirecionados automaticamente para uma página específica após serem autenticados, pode definir a página no campo After authentication Redirection URL.
Para limitar a largura de banda de cada user, selecione a opção Per-user bandwidth restriction e em Default download (Kbit/s) e Default upload (Kbit/s) defina as velocidades máximas de download e upload, respectivamente.
Em Authentication Method selecione Use an Authentication backend e em Authentication Server selecione Local Database.
Para que a autenticação seja feita através de HTTPS, e não HTTP, habilite a opção Login – Enable HTTPS login, e em HTTPS server name coloque a URL do servidor de autenticação, abaixo, em SSL/TLS Certificate selecione o certificado que foi criado para o Captive Portal, para a mesma URL que foi indicada acima, depois clique em Save no final da página.
Agora será preciso gerar os vouchers que serão utilizados para fazer a autenticação, para isso clique na aba Vouchers.
Para que possamos gerar os vouchers é preciso primeiro habilitar a sua criação e gerar um par de chave pública/privada, para isso selecione a opção Enable – Enable the creation, generation and activation of rolls with vouchers, e abaixo clique no botão Generate new keys, depois disso clique no botão Save no final da página.
Agora já podemos gerar os vouchers, para isso clique no botão Add.
Aqui pode configurar como os vouchers serão gerados, a opção Minutes per ticket serve para configurar a duração máxima da sessão, nesse caso 120 minutos (2 horas), em Count o número de vouchers a serem gerados é indicado, nesse caso apenas 10 vouchers, a opção Comment é auto explicativa.
Depois de configurar como quer gerar os vouchers, clique em Save.
Com os vouchers gerados, clique no ícone de uma folha com um x, que está do lado direito dos vouchers, para fazer o download do arquivo .csv com os códigos.
Aqui temos os vouchers que foram gerados, e que serão utilizados na autenticação no Captive Portal.
Entretanto, se tentar acessar a internet não irá conseguir acessar o portal de autenticação do Captive Portal, já que ainda não existe nenhuma entrada no serviço DNS para o endereço que foi configurado anteriormente.
Para que a página de autenticação do Captive Portal possa ser acessada, será preciso criar um A Record no servidor DNS do firewall, para isso clique em Services -> DNS Resolver.
Em Host Overrides clique no botão Add.
Aqui iremos configurar o A Record que irá apontar a URL captiveportal.rotolip.local para o IP da interface Blue.
Em Host coloque captiveportal, em Domain coloque rotolip.local e em IP Address coloque o IP da interface Blue, dê uma descrição apropriada e clique em Save.
Com isso já temos o A Record criado e já podemos verificar se o serviço está funcionando corretamente.
Aqui podemos ver que ao tentar acessar alguma página da internet é pedido para fazer login primeiro.
E temos acesso à página de autenticação, e podemos ver na barra de endereço que a URL está funcionando como esperado.
Após a autenticação, foi feito com sucesso o redirecionamento para a página que foi configurada.
No pfSense podemos ver que temos uma sessão iniciada com o primeiro voucher.
As velocidades de download e upload foram limitadas, e o cliente está utilizando o firewall como servidor DNS.
Captive Portal no OPNsense
Agora iremos fazer a mesma coisa, mas no OPNsense.
Clique em System -> Access -> Servers.
Dê um nome descritivo e em Type selecione Voucher, clique em Save.
Com isso temos o servidor de vouchers criado.
Clique em Services -> Captive Portal -> Administration, iremos criar a configuração para a zona Blue.
Habilite a zona e em interfaces selecione apenas a interface Blue, em Authenticate using selecione o servidor de vouchers que foi criado anteriormente.
Aqui também é possível utilizar HTTPS para o portal de autenticação, caso queira o fazer, se não desejar, apenas dê uma descrição para essa zona e clique em Save.
Clique em Apply para aplicar as alterações feitas.
Agora iremos criar os vouchers, para isso clique em Services -> Captive Portal -> Vouchers, e depois no botão Create vouchers.
Aqui podemos alterar algumas configurações dos vouchers gerados, esses vouchers também terão a duração de 2 horas, para isso, em Validity, selecione a opção Custom (mninutes) e indique a duração no campo logo abaixo, também pode configurar se os vouchers expiram, e o número de vouchers a serem gerados, nesse caso serão apenas 10, como foi feito anteriormente, em Groupname dê um nome para identificar esse lote de vouchers que serão gerados, para terminar clique em Generate.
Ao clicar em Generate, os vouchers serão gerados automaticamente e será feito o download do arquivo .csv com os vouchers gerados, salve-os em um local apropriado.
Aqui podemos ver os vouchers que foram gerados.
Aqui, ao contrário do pfSense, os vouchers não são apenas um código que é introduzido, mas sim um par de username/password.
Para habilitar o servidor DHCP vá em Services -> DHCPv4 -> [Blue].
Selecione a opção Enable DHCP Server on the Blue interface, em Range indique o início e fim da faixa de IPs que serão distribuídos aos clientes, e como também iremos restringir os clientes apenas ao DNS do firewall, em DNS servers também é preciso colocar o IP da interface Blue.
Quando terminar clique em Save no final da página.
Crie duas regras no firewall para a interface Blue, uma para permitir o acesso à internet e outra para bloquear o acesso a qualquer servidor DNS que não seja o firewall.
Para limitar a largura de banda para os users do Captive Portal no OPNsense é preciso fazer um procedimento diferente.
Clique em Firewall -> Shaper -> Pipes, depois clique no botão com o ➕ para criar um novo pipe.
Em Bandwidth especifique a largura de banda que deseja alocar, em Bandwidth Metricpode especificar as unidades.
Não é preciso fazer mais nenhuma configuração além de dar uma descrição para o pipe, quando terminar clique em Save.
Repita o processo para o pipe para o upload.
Com os pipes criados podemos criar as regras que irão aplicar os limites.
Clique na aba Rules e no botão ➕.
Ative o switch advanced mode e se certifique de que a regra está ativa.
Em Interface selecione a interface Blue, em Protocol selecione ipv4.
Em Direction selecione out, já que vamos limitar a velocidade do tráfego que sai da interface e vai para os clientes, e em Target selecione o pipe que foi criado para os downloads, dê uma descrição e clique em Save.
Repita o processo para criar uma regra para os uploads, dessa vez selecionando como target o pipe de upload, e a direção in.
Com as duas regras criadas já podemos testar o Captive Portal no cliente.
Como podemos ver na imagem acima, é pedido para iniciar sessão para poder acessar a internet.
O portal de acesso do Captive Portal no OPNsense é ligeiramente diferente do pfSense, aqui não temos a opção de utilizar um token, apenas uma combinação de username e password.
A largura de banda foi limitada com sucesso, e o cliente não tem acesso a outros servidores DNS além do próprio firewall.
E no OPNsense podemos ver a sessão do Captive Portal ativa.
High Availability no pfSense
Uma segunda instância do pfSense será instalada e configurada para assumir as funções da instância atual, caso ela falhe.
O primeiro passo será fazer algumas pequenas alterações na rede que liga o pfSense e o R3, no momento a rede configurada é a 10.155.170.8/30, que tem apenas 2 IPs disponíveis, o primeiro, 10.155.170.9, para o R3 e o segundo, 10.155.170.10, para o pfSense, entretanto, será preciso mais 2 IPs, um para a segunda instância do pfSense e outro para a interface virtual que será partilhada entre as duas instâncias, por isso a rede será expandida, de /30 para /29, com a primeira instância passando a 10.155.170.11, segunda instância do pfSense ficando com o endereço 10.155.170.12 e a interface virtual 10.155.170.10.
Também será preciso configurar a interface OPT3, que no momento não está em uso, para servir como link de sincronização entre as duas instâncias.
A configuração dessa nova instância, que ficará com o hostname zidPR, terá uma configuração inicial muito semelhante à da instância atual, ballaPR.
Será preciso mudar os IPs de todas as interfaces do firewall ballaPR, para um IP à frente, por exemplo, o endereço da interface Green vai passar de 172.29.170.1 para 172.29.170.2, e os IPs da segunda instância, zidPR, serão os endereços seguintes, isso será feito para que não seja preciso alterar as configurações de servidores DHCP, ou outros serviços que estejam configurados para usar os endereços originais da instância ballaPR.
Os IPs da instância zidPR ficação da seguinte forma:
00:50:56:20:02:80 – R3-pf/WAN 10.155.170.12/29
00:50:56:20:02:81 – pfGreen 172.29.170.3/23
00:50:56:20:02:82 – pfOrange 10.18.170.3/29
00:50:56:20:02:83 – pfBlue 10.0.170.3/24
00:50:56:20:02:84 – pfSync 172.168.255.2/30
00:50:56:20:02:85 – Host 10.10.10.22/24
Nas imagens acima podemos ver que as duas instâncias tem as mesmas interfaces físicas com os mesmos nomes e com os IPs em sequência.
Com as interfaces já configuradas, é preciso agora instalar os mesmos pacotes que foram instalados no ballaPR.
Agora é preciso criar as regras no firewall na interface Sync para possa haver a sincronização.
É preciso replicar essas regras nos dois firewalls.
Agora será preciso ativar a Alta Disponibilidade nos dois firewalls, para isso vá em System -> High Avail. Sync, nos dois firewalls.
Selecione a opção Synchronize states, e em Synchronize Interface, selecione a interface que foi configurada para esse propósito, nesse caso é a interface Sync.
Em pfSunc Synchronize Peer IP coloque o IP da interface Sync do outro firewall, no firewall ballaPR esse IP é 172.168.255.2 e no zidPR é 172.168.255.1.
Não é preciso fazer mais nenhuma configuração nessa página para o segundo firewall, nesse caso pode clicar em Save no final da página e continuar a configuração no primeiro firewall.
Em Synchronize Config to IP coloque novamente o IP do segundo firewall, em Remote System Username coloque o username da conta de administrador, e em Remote System Password coloque a senha, pode deixar a opção Synchronize admin ativa.
Aqui serão selecionadas as opções que serão sincronizadas, selecione todas as que se apliquem e clique em Save.
Agora é preciso criar os Virtual IPs, que serão partilhados entre os dois firewalls.
Clique em Firewall -> Virtual IPs.
Para criar um novo Virtual IP clique em Add.
Vamos começar pelo VIP da interface WAN.
Em Type selecione CARP, em Interface selecione WAN.
Address type fica como Single address, e em Address(es) coloque o IP que deseja, que nesse caso será o IP que a interface WAN desse firewall usava anteriormente.
Em Virtual IP Password coloque uma senha e a confirme.
VHID Group geralmente é configurado como o último octeto do endereço de IP, por isso fica como 10 nesse caso.
Em Description coloque uma descrição adequada para esse VIP e clique em Save.
Repita os passos para o resto das interfaces, colocando os endereços apropriados.
Com a criação dos VIPs terminadas podemos ir para o próximo passo, NAT.
Clique em Firewall -> NAT e depois na aba Outbound.
Selecione a opção Manual Outbound NAT rule generation e clique em Save.
Aqui podemos ver todas as regras que foram geradas automaticamente, será preciso alterar todas elas.
Para isso clique no ícone do lápis ✏ do lado direito para as editar.
Em Translation – Address, altere de Interface Address para o VIP da interface WAN, depois clique em Save no final da página.
Com isso já temos a primeira regra alterada, repita esses passos para o resto das regras.
Com as regras alteradas podemos continuar o processo.
Se clicar em Status -> CARP (failover) poderá ver o estado do serviço.
Aqui vemos que o primeiro firewall, ballaPR, está como MASTER.
E o segundo como BACKUP.
A maioria das configurações estão sendo replicadas automaticamente com essas configurações, mas ainda é preciso fazer algumas alterações em alguns serviços.
No caso do servidor DHCP é preciso recondigurar o IP do Gateway para o VIP da interface.
No Squid Proxy é preciso ativar a sincronização, para isso, em CARP Status VIP selecione o VIP de alguma das interfaces que está configurada para utilizar o proxy, nesse caso é o VIP da interface Green, repita esses passos nos dois firewalls.
Clique em Save no final da página.
No firewall principal, na aba Sync do Squid Proxy, em Enable Sync selecione a opção Sync to host(s) defined below.
Habilite a opção Replication Targets e a configure com o protocolo que esteja utilizando na interface web, HTTPS, nesse caso, o IP deve ser o queo firewall está utilizando naquela interface, nesse caso é o IP 172.29.170.3 na interface Green, mesma coisa para a porta, as credenciais são as utilizadas para acessar a interface web.
Essa configuração só é feita no firewall principal.
Essa configuração precisa ser repetida para o SquidGuard, e é feita na aba XMLRPC Sync.
Agora é preciso atualizar as configurações das VPNs.
No servidor OpenVPN, em Endpoint Configuration, altere a Interface para o VIP da WAN e salve.
O mesmo deve ser feito para a VPN IPsec, em IKE Endpoint Configuration, altere a Interface para o VIP da WAN e salve.
Agora será preciso alterar as regras no firewall na interface WAN referentes ao servidor OpenVPN, que no momento estão configuradas para o IP da interface WAN, mas precisam ser configuradas para o VIP da WAN.
Com isso os clientes remotos poderão se conectar.
Acima temos um cliente remoto ligado ao servidor OpenVPN que está ativo no firewall principal.
E nenhum no secundário.
O cliente se conectou com sucesso através do VIP da WAN.
Com o firewall principal desconectado de todas as redes podemos testar se a ligação passa automaticamente para o firewall secundário.
A ligação foi automaticamente reestabelecida no firewall secundário.
O cliente continua tendo acesso à rede.
Na segunda fase (Phase 2) da ligação, ative a opção Keep Alive e coloque um IP da rede remota, para permitir a conexão automática do túnel.
Ao contrário do túnel OpenVPN, o túnel IPsec pode demorar algum tempo até ter sua ligação reestabelecida depois da mudança de estado dos firewalls.
Túnel IPsec ativo através do segundo firewall, com a ligação estabelecida automaticamente após assumir o papel de MASTER.
Cliente remoto com acesso à rede.
High Availability no OPNsense
O mesmo processo de configuração de um segundo firewall para alta disponibilidade será feito OPNsense, seguindo os mesmos princípios que foram mostrados no pfSense.
Os IPs serão alterados para o próximo endereço disponível e o CIDR da rede WAN passará de /30 para /29.
WAN: 10.155.170.2/30 -> 10.155.170.3/29
Green: 10.53.170.1 -> 10.53.170.2
Blue: 10.120.170.1 -> 10.120.170.2
As interfaces Host e Sync continuarão com os mesmos endereços, já que não precisarão de Virtual IP.
A instância tabakPR ficará com os seguintes IPs:
WAN: 10.155.170.2
Green: 10.53.170.1
Blue: 10.120.170.1
Host: 10.10.10.23
Sync: 192.168.255.254
E os Virtual IPs nas duas instâncias ficarão com os endereços originais da instância tellisPR.
Como foi feito no pfSense, é preciso criar regras permitindo o tráfego na interface Sync.
O mesmo processo para criação dos VIPs.
Acima temos todos os VIPs configurados no OPNsense, eles serão sincronizados automaticamente quando o processo de configuração do CARP for terminado.
Como foi preciso fazer no pfSense, é necessário reconfigurar o Gateway no servidor DHCP.
A mesma coisa para as regras NAT.
Và em System -> High Availability -> Settings para configurar a alta disponibilidade.
Selecione a opção Synchronize States para habilitar a sincronização das configurações desse firewall para o secundário.
Em Synchronize Interface selecione a interface de sincronização, nesse caso é a interface Sync, e em Synchronize Peer IP coloque o IP do firewall secundário.
Em Synchronize Config to IP coloque novamente o IP do firewall secundário, para que essa instância replique suas configurações para o secundário.
Em Remote System Username e Remote System Password coloque as credenciais da conta de administrador.
Como foi feito no pfSense, selecione todas as opções que deseja sincronizar e depois clique em Save no final da página.
No firewall secundário é preciso apenas habilitar o serviço, selecionar a interface correta e colocar o IP do firewall primário, não é preciso fazer mais nenhuma configuração, já que esse firewall irá receber as configurações do firewall primário.
Como foi preciso fazer no pfSense, aqui também é preciso atualizar as configurações das VPNs IPsec e OpenVPN, para utilizar o VIP da WAN.
Depois de atualizar as interfaces das das VPNs é preciso atualizar as regras do firewall, da mesma maneira que foi feita no pfSense.
Com as regras atualizadas a configuração está completa, se desligar o firewall primário, o secundário irá assumir as responsabilidades.
Nas imagens acima podemos ver o cliente por trás dos firewalls OPNsense (com o segundo em failover) se conectando à rede do outro lado do pfSense.
OpenVPN em failover no firewall secundário.
O cliente Windows 10 acessando o Windows Server através da VPN OpenVPN site to site em failover.
Com o firewall em failover, um cliente remoto ligado ao servidor OpenVPN.
Windows 10 acessando a internet através da VPN no firewall secundário em failover.
Conclusão
Nesse trabalho foram abordados inúmeros temas referentes a firewalls e VPNs.
Existem diferentes maneiras de fazer a mesma coisa, é importante avaliar as necessidades e recursos disponíveis para encontrar a melhor solução.
