[FUG-BR] PFSENSE e BGP e TABLES e PF

[Renato Frederick]

Pessoal, bom dia!

Desculpem o cross-posting, mas a PFSENSE-PT e FUG é lugar de gente fera 
neste assunto e meu email faz referência a ambos.

Vamos lá, já peço perdão pelo email grande!

No FREEBSD/OPENBSD, com OPENBGPD e PF, eu posso fazer isto:

1 - criar uma table no PF, por exemplo: table <ctbc> persist

2 - lá no openbgpd.conf, eu entrego todas as redes aprendidas da sessão 
BGP desta operadora para a table criada, por exemplo:

match from 189.x.x.x set pftable ctbc #onde 189.x.x.x é o peer BGP

3 - por fim, lá no pf.conf, eu posso fazer um PBR de saída, forçando, 
por exemplo, que toda a rede 200.1.1.0/24 saia pela ctbc, mesmo que um 
outro peer BGP(por exemplo, um PTT), entregue uma rota mais específica:

pass out quick route-to ($ctbc_if $ctbc_gw) from200.1.1.0/24 to <ctbc> 
keep state

Porque eu faço este processo todo e não faço simplesmente um:

pass out quick route-to ($ctbc_if $ctbc_gw) from200.1.1.0/24 to any keep 
state

Para garantir que quando o link com a ctbc cair(e obviamente a sessão 
bgp parar), a table ctbc vai ficar vazia e a rede 200.1.1.0/24 vai sair 
ou pela rota padrão(que vai usar outra operadora), ou por outra sessão 
BGP(que vai ter as rotas injetadas no kernel). Também garante que se por 
algum motivo a ctbc não enviar todo o fullrouting(por problemas do tipo 
rompimento de fibra internacional, etc), estas redes que não forem 
aprendidas serão enxergadas por alguma outra operadora.

Se eu usasse a segunda sintaxe (to any), o PBR ficaria estático.

Dei exemplo aqui de CTBC mas isto é aplicado a qq BGP.

Porque em alguns casos eu faço isto e não deixo que o BGP faça o papel 
dele de achar a rota mais curta para um destino?
Porque muitas vezes, eu tenho um cenário de links de backup 
assimétricos, por exemplo:

CTBC 300Mb
GVT 100Mb

e eu poderia ocorrer em uma situação de usar 90% GVT e só 30% CTBC. 
Então analiso a rede com netflow e as origens com maior tráfego são 
forçadas para a CTBC, por exemplo. É o feijão com arroz de qq ISP.

Isto funciona muito bem e a gora vem a questão: A ideia é usar isto 
também no PFSENSE, sabem como é, a interface gráfica é algo muito útil. 
Porém me deparei com algumas dúvidas e não tenho como testar isto em 
laboratório:

No pfsense, o que a interface gráfica chama de "aliases de firewall" são 
tables <table1> ou aliases mesmo $alias1?

Para replicar o cenário que eu tenho hoje, pensei em configurar o 
bgpd.conf pela interface web, deixaria ele gerar um bgpd.conf "padrão" e 
depois, ativaria a opção de editar o bgpd.conf manualmente pela 
interface WEB e colocaria a linha "match"? Notei que ao fazer isto ele 
avisa que as alterações via WEB não serão usadas mais até eu apagar o 
que eu fiz manualmente. o que acham?

Outra coisa, notei que no pfsense, as table do pf criada não são 
"persist". Assim, se o "alias de firewall" está vazio, não é criada a 
table, certo? Qual seria um truque, criar o alias e lá digitar um IP 
qualquer tipo 1.1.1.1, prá ela sempre ser criada(lembrando que esta 
table o bgp que vai popular)
O que eu notei é que quando a table não tem nenhum IP, o PF não a cria, 
daí o openbgpd não preenche ela(claro, ela não existe) e só volta a 
preencher se eu matar e voltar o bgpd(nem um rbgpctl eload resolve).

Por fim, a última dúvida: ao aplicar as alterações feitas na regra de 
firewall via web, o que o PF vai fazer com esta table, zerar ela e 
preencher com o que tem nos aliases, sobrescrevendo o que o bgpd populou?

o problema todo, que me leva a fazer isto é que muitas vezes, meu 
gateway que fecha a sessão com a operadora está UP(então não posso usar 
os TIERS do PFSENSE em roundroubin/redundância), ou pior, até a sessão 
BGP estar UP, mas com 0 rotas recebidas. E aí o PBR de saída não vai 
chegar a lugar nenhum, eu teria que ter um técnico 24h alterando o 
route-to, hehe

Como eu falei, o PBR de saída eu uso para fazer um uso mais racional de 
links de tamanhos diferentes(para o tráfego de volta eu tento fazer uma 
otimização divulgando redes específicas, usando no-export e famigerados 
prepends e por aí vai).
Este PBR também pode ser usado para estratégias do tipo operadoras com 
SLA maior serão usadsa para clientes comerciais, etc, etc

Obrigado e desculpem o email gigante novamente!