[FUG-BR] Saiu o 10.1R no releng/10.1
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser atualizado à partir da árvore releng/10.1 através do svn. :) []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Saiu o 10.1R no releng/10.1
Em 11/11/2014 10:42, Marcelo Gondim escreveu: Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser atualizado à partir da árvore releng/10.1 através do svn. :) []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd É agora que o 10.0 Stable volta ao comum ? -- Paulo Henrique. Grupo de Usuários do FreeBSD no Brasil. Fone: (21) 96713-5042 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Saiu o 10.1R no releng/10.1
Em 11/11/2014, à(s) 11:07, Paulo Henrique - BSDs Brasil paulo.rd...@bsd.com.br escreveu: Em 11/11/2014 10:42, Marcelo Gondim escreveu: Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser atualizado à partir da árvore releng/10.1 através do svn. :) []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd É agora que o 10.0 Stable volta ao comum ? Atualizei um 10.1-RELEASE ontem e ficou assim: root@firewall:/usr/src # uname -sr FreeBSD 10.1-RC4-p1 -- www.bsdjf.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Saiu o 10.1R no releng/10.1
Em 11/11/2014, à(s) 11:13, Tiago Ribeiro sha...@gmail.com escreveu: Em 11/11/2014, à(s) 11:07, Paulo Henrique - BSDs Brasil paulo.rd...@bsd.com.br escreveu: Em 11/11/2014 10:42, Marcelo Gondim escreveu: Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser atualizado à partir da árvore releng/10.1 através do svn. :) []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd É agora que o 10.0 Stable volta ao comum ? Atualizei um 10.1-RELEASE ontem e ficou assim: root@firewall:/usr/src # uname -sr FreeBSD 10.1-RC4-p1 E um -STABLE: root@fw:/usr/src # uname -sr FreeBSD 10.1-PRERELEASE -- www.bsdjf.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] ipfw nat in-kernel FreeBSD 9.2
Bom dia pessoal, devido a um problema com Pipe + MAC Address no FreeBSD 10 para controle de upload (thread antiga aqui), estou fazendo testes na versão 9.2 do Nat do IPFW usando libalias. Pois bem, independentemente das demais regras (testei somente com as de NAT) o comportamento no FreeBSD 9.2 ficou diferente do FreeBSD 10. Considerem o seguinte: ipfw nat 123 config if WAN_IF log ipfw add 50 nat 123 ip from any to me in recv WAN_IF ipfw add 51 nat 123 ip from 192.168.0.0/16 to any out xmit WAN_IF ipfw add 52 nat 123 ip from 172.16.1.0/24 to any out xmit WAN_IF ipfw add 65000 allow ip from any to any Pois bem, esse cenário na versão 10 funciona, mais na 9 não, todos os pacotes incrementam somente a regra 50, mesmo que eu tente acessar o endereço IP configurado na interface WAN. outros detalhes sysctl: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.fw.one_pass=1 kernel: options IPFIREWALL options IPFIREWALL_FORWARD #(somente no 9, no 10 não existe) options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options DEVICE_POLLING options HZ=1000 options IPFIREWALL_NAT options LIBALIAS Alguma ideia de como configurar essas regras de NAT usando IPFW no FreeBSD 9? -- Att. __ Márcio Elias Hahn do Nascimento Bacharel em Tecnologias da Informação e Comunicação - TIC Cel: (55) 48-8469-1819 Emails: marcioel...@bsd.com.br / marcioel...@gmail.com Skype: marcioeliash...@hotmail.com FreeBSD - The Power To Serve - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Saiu o 10.1R no releng/10.1
On 11/11/2014 11:13, Tiago Ribeiro wrote: Em 11/11/2014, à(s) 11:07, Paulo Henrique - BSDs Brasil paulo.rd...@bsd.com.br escreveu: Em 11/11/2014 10:42, Marcelo Gondim escreveu: Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser atualizado à partir da árvore releng/10.1 através do svn. :) []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd É agora que o 10.0 Stable volta ao comum ? Atualizei um 10.1-RELEASE ontem e ficou assim: root@firewall:/usr/src # uname -sr FreeBSD 10.1-RC4-p1 -- saiu no releng: (root@mail)[/usr/src]# svnlite info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/releng/10.1 Relative URL: ^/releng/10.1 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 274375 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 274371 Last Changed Date: 2014-11-11 03:54:50 -0200 (Tue, 11 Nov 2014) (root@mail)[/usr/src]# uname -a FreeBSD mail.bsdinfo.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #20 r274375: Tue Nov 11 11:16:37 BRST 2014 r...@mail.bsdinfo.com.br:/usr/obj/usr/src/sys/GONDIM amd64 []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Saiu o 10.1R no releng/10.1
On 11/11/2014 11:07, Paulo Henrique - BSDs Brasil wrote: Em 11/11/2014 10:42, Marcelo Gondim escreveu: Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser atualizado à partir da árvore releng/10.1 através do svn. :) []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd É agora que o 10.0 Stable volta ao comum ? Opa Paulo, Desde que saiu o releng, o stable passou à espelhar o que será o 10.2. :) []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ipfw nat in-kernel FreeBSD 9.2
Talvez o divert natd seja o q esteja funcionando no seu script add divert natd all from 192.168.0.0/16 to any via wan0 eu costumava usar assim, inclusive com pipes. mas o seu one_pass está me fazendo refletir se deveria ser setado em 1 ou nao... [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 11 de novembro de 2014 11:37, Márcio Elias marcioel...@gmail.com escreveu: Bom dia pessoal, devido a um problema com Pipe + MAC Address no FreeBSD 10 para controle de upload (thread antiga aqui), estou fazendo testes na versão 9.2 do Nat do IPFW usando libalias. Pois bem, independentemente das demais regras (testei somente com as de NAT) o comportamento no FreeBSD 9.2 ficou diferente do FreeBSD 10. Considerem o seguinte: ipfw nat 123 config if WAN_IF log ipfw add 50 nat 123 ip from any to me in recv WAN_IF ipfw add 51 nat 123 ip from 192.168.0.0/16 to any out xmit WAN_IF ipfw add 52 nat 123 ip from 172.16.1.0/24 to any out xmit WAN_IF ipfw add 65000 allow ip from any to any Pois bem, esse cenário na versão 10 funciona, mais na 9 não, todos os pacotes incrementam somente a regra 50, mesmo que eu tente acessar o endereço IP configurado na interface WAN. outros detalhes sysctl: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.fw.one_pass=1 kernel: options IPFIREWALL options IPFIREWALL_FORWARD #(somente no 9, no 10 não existe) options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options DEVICE_POLLING options HZ=1000 options IPFIREWALL_NAT options LIBALIAS Alguma ideia de como configurar essas regras de NAT usando IPFW no FreeBSD 9? -- Att. __ Márcio Elias Hahn do Nascimento Bacharel em Tecnologias da Informação e Comunicação - TIC Cel: (55) 48-8469-1819 Emails: marcioel...@bsd.com.br / marcioel...@gmail.com Skype: marcioeliash...@hotmail.com FreeBSD - The Power To Serve - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Saiu o 10.1R no releng/10.1
Em 11/11/2014, à(s) 12:05, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 11/11/2014 11:07, Paulo Henrique - BSDs Brasil wrote: Em 11/11/2014 10:42, Marcelo Gondim escreveu: Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser atualizado à partir da árvore releng/10.1 através do svn. :) []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd O STABLE está ainda como PRERELEASE root@fw:/usr/src # svnlite info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 274379 Node Kind: directory Schedule: normal Last Changed Author: kib Last Changed Rev: 274375 Last Changed Date: 2014-11-11 09:06:10 -0200 (Tue, 11 Nov 2014) root@fw:/usr/src # uname -sr FreeBSD 10.1-PRERELEASE -- www.bsdjf.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ipfw nat in-kernel FreeBSD 9.2
Fabricio, eu uso o divert em alguns cases (mais de 20), só que o consumo de cpu e a latência conforme a banda consumida e o número de sub-redes com alias na placa interna aumenta está ficando inviável. A tentativa de utilizar essa forma de NAT é reduzir esse consumo de CPU e também manter uma latência mais baixa na rede. Já tentei com one_pass 1 e 0. Estava testando o FreeBSD 10.1 RC4 para ver se ainda tinha o bug do MAC com PIPE mais o mesmo está dando kernel panic assim que eu ativo o dummynet para controlar a banda (subo as regras do firewall). Vejo relatos deste nat usando libalias deste a versão 8, deve ser algum tratamento diferenciado nos pacotes que obriga a criação de regras de nat diferentes na versão 9, e por isso esteja errando, mais não encontrei a lógica correta. Vi alguns usuários usando duas FIBs, mais não sei se isso seria necessário. -- Att. __ Márcio Elias Hahn do Nascimento Bacharel em Tecnologias da Informação e Comunicação - TIC Cel: (55) 48-8469-1819 Emails: marcioel...@bsd.com.br / marcioel...@gmail.com Skype: marcioeliash...@hotmail.com FreeBSD - The Power To Serve 2014-11-11 12:13 GMT-02:00 Fabricio Lima lis...@fabriciolima.com.br: Talvez o divert natd seja o q esteja funcionando no seu script add divert natd all from 192.168.0.0/16 to any via wan0 eu costumava usar assim, inclusive com pipes. mas o seu one_pass está me fazendo refletir se deveria ser setado em 1 ou nao... [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 11 de novembro de 2014 11:37, Márcio Elias marcioel...@gmail.com escreveu: Bom dia pessoal, devido a um problema com Pipe + MAC Address no FreeBSD 10 para controle de upload (thread antiga aqui), estou fazendo testes na versão 9.2 do Nat do IPFW usando libalias. Pois bem, independentemente das demais regras (testei somente com as de NAT) o comportamento no FreeBSD 9.2 ficou diferente do FreeBSD 10. Considerem o seguinte: ipfw nat 123 config if WAN_IF log ipfw add 50 nat 123 ip from any to me in recv WAN_IF ipfw add 51 nat 123 ip from 192.168.0.0/16 to any out xmit WAN_IF ipfw add 52 nat 123 ip from 172.16.1.0/24 to any out xmit WAN_IF ipfw add 65000 allow ip from any to any Pois bem, esse cenário na versão 10 funciona, mais na 9 não, todos os pacotes incrementam somente a regra 50, mesmo que eu tente acessar o endereço IP configurado na interface WAN. outros detalhes sysctl: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.fw.one_pass=1 kernel: options IPFIREWALL options IPFIREWALL_FORWARD #(somente no 9, no 10 não existe) options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options DEVICE_POLLING options HZ=1000 options IPFIREWALL_NAT options LIBALIAS Alguma ideia de como configurar essas regras de NAT usando IPFW no FreeBSD 9? -- Att. __ Márcio Elias Hahn do Nascimento Bacharel em Tecnologias da Informação e Comunicação - TIC Cel: (55) 48-8469-1819 Emails: marcioel...@bsd.com.br / marcioel...@gmail.com Skype: marcioeliash...@hotmail.com FreeBSD - The Power To Serve - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Saiu o 10.1R no releng/10.1
Testes que eu fiz com a versão 10.1-RC4, se alguem puder fazer algo semelhante no PRERELEASE pra ver se o resultado é o mesmo. Options no Kernel: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options DEVICE_POLLING options HZ=1000 options IPFIREWALL_NAT options LIBALIAS Variáveis sysctl: sysctl net.inet.ip.forwarding=1 sysctl net.inet.ip.fastforwarding=1 sysctl net.inet.ip.fw.one_pass=1 sysctl net.link.ether.ipfw=1 sysctl net.inet.ip.dummynet.pipe_slot_limit=4096 Regras de Firewall: ipfw -f flush ipfw pipe -f flush ipfw nat -f flush ipfw pipe 10 config bw 10Mbps ipfw pipe 20 config bw 10Mbps ipfw nat 123 config if xn0 log ipfw add 50 nat 123 ip from any to me in recv WAN_IF ipfw add 51 nat 123 ip from 172.16.1.0/24 to any out xmit WAN_IF ipfw add 100 pipe 10 ip from any to 172.16.1.2 MAC xx:xx:xx:xx:xx:xx any ipfw add 110 pipe 20 ip from 172.16.1.2 to any MAC any xx:xx:xx:xx:xx:xx ipfw add 120 allow ip from any to 172.16.1.2 not layer2 ipfw add 130 allow ip from 172.16.1.2 to any not layer2 Configuração da rede: onde o IP da placa conectada a rede interna é: 172.16.1.1/24, o IP do cliente é 172.16.1.2 e o MAC da interface do cliente é xx:xx:xx:xx:xx:xx Aqui está o resultado: Nov 11 14:29:12 freebsd101 kernel: Nov 11 14:29:12 freebsd101 kernel: Nov 11 14:29:12 freebsd101 kernel: Fatal trap 12: page fault while in kernel mode Nov 11 14:29:12 freebsd101 kernel: Nov 11 14:29:12 freebsd101 kernel: cpuid = 0; Nov 11 14:29:12 freebsd101 kernel: apic id = 00 Nov 11 14:29:12 freebsd101 kernel: Fatal trap 12: page fault while in kernel mode Nov 11 14:29:12 freebsd101 kernel: fault virtual address= 0x188 Nov 11 14:29:12 freebsd101 kernel: cpuid = 3; fault code= supervisor read data, page not present Nov 11 14:29:12 freebsd101 kernel: apic id = 06 Nov 11 14:29:12 freebsd101 kernel: instruction pointer = 0x20:0x809f0b1f Nov 11 14:29:12 freebsd101 kernel: fault virtual address= 0x188 Nov 11 14:29:12 freebsd101 kernel: stack pointer= 0x28:0xfe003d0a5a90 Nov 11 14:29:12 freebsd101 kernel: fault code = supervisor read data, page not present Nov 11 14:29:12 freebsd101 kernel: frame pointer= 0x28:0xfe003d0a5ab0 Nov 11 14:29:12 freebsd101 kernel: instruction pointer = 0x20:0x809f0b1f Nov 11 14:29:12 freebsd101 kernel: code segment = base 0x0, limit 0xf, type 0x1b Nov 11 14:29:12 freebsd101 kernel: stack pointer= 0x28:0xfe003d1fe640 Nov 11 14:29:12 freebsd101 kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Nov 11 14:29:12 freebsd101 kernel: frame pointer= 0x28:0xfe003d1fe660 Nov 11 14:29:12 freebsd101 kernel: processor eflags = code segment = base 0x0, limit 0xf, type 0x1b Nov 11 14:29:12 freebsd101 kernel: interrupt enabled, = DPL 0, pres 1, long 1, def32 0, gran 1 -- Att. __ Márcio Elias Hahn do Nascimento Bacharel em Tecnologias da Informação e Comunicação - TIC Cel: (55) 48-8469-1819 Emails: marcioel...@bsd.com.br / marcioel...@gmail.com Skype: marcioeliash...@hotmail.com FreeBSD - The Power To Serve On Tue, Nov 11, 2014 at 1:15 PM, Tiago Ribeiro sha...@gmail.com wrote: Em 11/11/2014, à(s) 12:05, Marcelo Gondim gon...@bsdinfo.com.br escreveu: On 11/11/2014 11:07, Paulo Henrique - BSDs Brasil wrote: Em 11/11/2014 10:42, Marcelo Gondim escreveu: Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser atualizado à partir da árvore releng/10.1 através do svn. :) []´s Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd O STABLE está ainda como PRERELEASE root@fw:/usr/src # svnlite info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 274379 Node Kind: directory Schedule: normal Last Changed Author: kib Last Changed Rev: 274375 Last Changed Date: 2014-11-11 09:06:10 -0200 (Tue, 11 Nov 2014) root@fw:/usr/src # uname -sr FreeBSD 10.1-PRERELEASE -- www.bsdjf.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ipfw nat in-kernel FreeBSD 9.2
Entendi... seu objetivo (q estaria causando o kernel panic) é o MAC + pipes Duvida: -sem as regras de mac address, está tudo carregando normal ne? (pipes por IP) e baixa cpu? -pra estar gerando tanta carga na cpu assim, qual o throughput q estamos falando? (pra saber se a alta demanda de cpu é a filtragem dos MAC, ou o dummynet em si) geralmente eu nao tinha problemas de cpu qndo usava, mas eram poucos clientes aplicados dummynet. tenta refazer suas regras em pf (mas ele so suporta filtragem por mac operando como bridge) ou poderia cogitar migrar os usuarios para pppoe, levantando um servidor de pppoe na sua ponta. se tudo mais falhar, poderia usar uma integraçao dhcp + reserva por mac + dummynet + script levantando o firewall pra este ip dinamicamente, validando a origem do mac, e aplicando sua limitaçao de banda por IP ao inves de mac. ou seja, caso nao resolva, tem 2 paleativos pra vc fugir da alta cpu, com outras soluçoes. ou refazendo em outro fw. mas nao esqueça de responder as perguntas acima. [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 11 de novembro de 2014 14:36, Márcio Elias marcioel...@gmail.com escreveu: Fabricio, eu uso o divert em alguns cases (mais de 20), só que o consumo de cpu e a latência conforme a banda consumida e o número de sub-redes com alias na placa interna aumenta está ficando inviável. A tentativa de utilizar essa forma de NAT é reduzir esse consumo de CPU e também manter uma latência mais baixa na rede. Já tentei com one_pass 1 e 0. Estava testando o FreeBSD 10.1 RC4 para ver se ainda tinha o bug do MAC com PIPE mais o mesmo está dando kernel panic assim que eu ativo o dummynet para controlar a banda (subo as regras do firewall). Vejo relatos deste nat usando libalias deste a versão 8, deve ser algum tratamento diferenciado nos pacotes que obriga a criação de regras de nat diferentes na versão 9, e por isso esteja errando, mais não encontrei a lógica correta. Vi alguns usuários usando duas FIBs, mais não sei se isso seria necessário. -- Att. __ Márcio Elias Hahn do Nascimento Bacharel em Tecnologias da Informação e Comunicação - TIC Cel: (55) 48-8469-1819 Emails: marcioel...@bsd.com.br / marcioel...@gmail.com Skype: marcioeliash...@hotmail.com FreeBSD - The Power To Serve 2014-11-11 12:13 GMT-02:00 Fabricio Lima lis...@fabriciolima.com.br: Talvez o divert natd seja o q esteja funcionando no seu script add divert natd all from 192.168.0.0/16 to any via wan0 eu costumava usar assim, inclusive com pipes. mas o seu one_pass está me fazendo refletir se deveria ser setado em 1 ou nao... [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 11 de novembro de 2014 11:37, Márcio Elias marcioel...@gmail.com escreveu: Bom dia pessoal, devido a um problema com Pipe + MAC Address no FreeBSD 10 para controle de upload (thread antiga aqui), estou fazendo testes na versão 9.2 do Nat do IPFW usando libalias. Pois bem, independentemente das demais regras (testei somente com as de NAT) o comportamento no FreeBSD 9.2 ficou diferente do FreeBSD 10. Considerem o seguinte: ipfw nat 123 config if WAN_IF log ipfw add 50 nat 123 ip from any to me in recv WAN_IF ipfw add 51 nat 123 ip from 192.168.0.0/16 to any out xmit WAN_IF ipfw add 52 nat 123 ip from 172.16.1.0/24 to any out xmit WAN_IF ipfw add 65000 allow ip from any to any Pois bem, esse cenário na versão 10 funciona, mais na 9 não, todos os pacotes incrementam somente a regra 50, mesmo que eu tente acessar o endereço IP configurado na interface WAN. outros detalhes sysctl: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.fw.one_pass=1 kernel: options IPFIREWALL options IPFIREWALL_FORWARD #(somente no 9, no 10 não existe) options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options DEVICE_POLLING options HZ=1000 options IPFIREWALL_NAT options LIBALIAS Alguma ideia de como configurar essas regras de NAT usando IPFW no FreeBSD 9? -- Att. __ Márcio Elias Hahn do Nascimento Bacharel em Tecnologias da Informação e Comunicação - TIC Cel: (55) 48-8469-1819 Emails: marcioel...@bsd.com.br / marcioel...@gmail.com Skype: marcioeliash...@hotmail.com FreeBSD - The Power To Serve - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico:
Re: [FUG-BR] ipfw nat in-kernel FreeBSD 9.2
Entendi... seu objetivo (q estaria causando o kernel panic) é o MAC + pipes Não dá Kernel Panic no 9.2, somente no 10.1, no 10 simplesmente não há navegação, nem com MAC nem com IP direto. Sobre PPPoE é meu futuro, estou caminhando para isso mais são muitos clientes e tenho muitos concentradores que preciso otimizar antes de tudo virar PPPoE. Estamos falando de 600 aliases de IP em média por concentrador, e de até uns 60Mb de banda. Eu já uso o que vc sugeriu, DHCP por MAC + IPFW + dummynet + scripts. O problema de deixar o IP atrelado somente ao DHCP é que algum usuário mal intencionado pode setar um IP manualmente de alguma subrede roteada e sair navegando. Ou seja, eu limito a banda ao IP e ao MAC atrelados. 2014-11-11 15:31 GMT-02:00 Fabricio Lima lis...@fabriciolima.com.br: Entendi... seu objetivo (q estaria causando o kernel panic) é o MAC + pipes Duvida: -sem as regras de mac address, está tudo carregando normal ne? (pipes por IP) e baixa cpu? -pra estar gerando tanta carga na cpu assim, qual o throughput q estamos falando? (pra saber se a alta demanda de cpu é a filtragem dos MAC, ou o dummynet em si) geralmente eu nao tinha problemas de cpu qndo usava, mas eram poucos clientes aplicados dummynet. tenta refazer suas regras em pf (mas ele so suporta filtragem por mac operando como bridge) ou poderia cogitar migrar os usuarios para pppoe, levantando um servidor de pppoe na sua ponta. se tudo mais falhar, poderia usar uma integraçao dhcp + reserva por mac + dummynet + script levantando o firewall pra este ip dinamicamente, validando a origem do mac, e aplicando sua limitaçao de banda por IP ao inves de mac. ou seja, caso nao resolva, tem 2 paleativos pra vc fugir da alta cpu, com outras soluçoes. ou refazendo em outro fw. mas nao esqueça de responder as perguntas acima. [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 11 de novembro de 2014 14:36, Márcio Elias marcioel...@gmail.com escreveu: Fabricio, eu uso o divert em alguns cases (mais de 20), só que o consumo de cpu e a latência conforme a banda consumida e o número de sub-redes com alias na placa interna aumenta está ficando inviável. A tentativa de utilizar essa forma de NAT é reduzir esse consumo de CPU e também manter uma latência mais baixa na rede. Já tentei com one_pass 1 e 0. Estava testando o FreeBSD 10.1 RC4 para ver se ainda tinha o bug do MAC com PIPE mais o mesmo está dando kernel panic assim que eu ativo o dummynet para controlar a banda (subo as regras do firewall). Vejo relatos deste nat usando libalias deste a versão 8, deve ser algum tratamento diferenciado nos pacotes que obriga a criação de regras de nat diferentes na versão 9, e por isso esteja errando, mais não encontrei a lógica correta. Vi alguns usuários usando duas FIBs, mais não sei se isso seria necessário. -- Att. __ Márcio Elias Hahn do Nascimento Bacharel em Tecnologias da Informação e Comunicação - TIC Cel: (55) 48-8469-1819 Emails: marcioel...@bsd.com.br / marcioel...@gmail.com Skype: marcioeliash...@hotmail.com FreeBSD - The Power To Serve 2014-11-11 12:13 GMT-02:00 Fabricio Lima lis...@fabriciolima.com.br: Talvez o divert natd seja o q esteja funcionando no seu script add divert natd all from 192.168.0.0/16 to any via wan0 eu costumava usar assim, inclusive com pipes. mas o seu one_pass está me fazendo refletir se deveria ser setado em 1 ou nao... [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 11 de novembro de 2014 11:37, Márcio Elias marcioel...@gmail.com escreveu: Bom dia pessoal, devido a um problema com Pipe + MAC Address no FreeBSD 10 para controle de upload (thread antiga aqui), estou fazendo testes na versão 9.2 do Nat do IPFW usando libalias. Pois bem, independentemente das demais regras (testei somente com as de NAT) o comportamento no FreeBSD 9.2 ficou diferente do FreeBSD 10. Considerem o seguinte: ipfw nat 123 config if WAN_IF log ipfw add 50 nat 123 ip from any to me in recv WAN_IF ipfw add 51 nat 123 ip from 192.168.0.0/16 to any out xmit WAN_IF ipfw add 52 nat 123 ip from 172.16.1.0/24 to any out xmit WAN_IF ipfw add 65000 allow ip from any to any Pois bem, esse cenário na versão 10 funciona, mais na 9 não, todos os pacotes incrementam somente a regra 50, mesmo que eu tente acessar o endereço IP configurado na interface WAN. outros detalhes sysctl: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.fw.one_pass=1 kernel: options IPFIREWALL options IPFIREWALL_FORWARD #(somente no 9, no 10 não existe) options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options
Re: [FUG-BR] ipfw nat in-kernel FreeBSD 9.2
faz o pipe apenas pelo IP... e a regra do accept faça atraves de AND do ip e mac. assim vc 'nao complicou' o seu script de fw fazendo regra dummynet em layer2... e liberou apenas os clientes com MAC previamente cadastrados o mal intencionado teria q saber q vc faz isso, e clonar o mac de alguem. tem furo, mas pqp, é meio 'impossivel'... so se vcs derem a dica. eu fazia assim qndo vendia internet predial: ipfw add pipe 1 ip from 192.168.0.1 to any ipfw config pipe 1 bw 10Mbp/s ipfw add accept from 192.162.168.0.1 to any allow all ip from any to any MAC xx:xx:xx:xx any # MAC do usuario do IP .1 ipfw add pipe 2 ip from 192.168.0.2 to any ipfw config pipe 2 bw 10Mbp/s ipfw add accept from 192.162.168.0.2 to any allow all ip from any to any MAC xx:xx:xx:xx any # MAC do usuario do IP .2 (claro q tem q fazer as regras de retorno tb..) Dois pontos a considerar: # sysctl net.link.ether.ipfw=1 The other thing to realise is that MAC addresses are written in reverse order: *dest src*; whereas IP rules are written in forward order: *src dest* . [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 11 de novembro de 2014 15:42, Márcio Elias marcioel...@gmail.com escreveu: Entendi... seu objetivo (q estaria causando o kernel panic) é o MAC + pipes Não dá Kernel Panic no 9.2, somente no 10.1, no 10 simplesmente não há navegação, nem com MAC nem com IP direto. Sobre PPPoE é meu futuro, estou caminhando para isso mais são muitos clientes e tenho muitos concentradores que preciso otimizar antes de tudo virar PPPoE. Estamos falando de 600 aliases de IP em média por concentrador, e de até uns 60Mb de banda. Eu já uso o que vc sugeriu, DHCP por MAC + IPFW + dummynet + scripts. O problema de deixar o IP atrelado somente ao DHCP é que algum usuário mal intencionado pode setar um IP manualmente de alguma subrede roteada e sair navegando. Ou seja, eu limito a banda ao IP e ao MAC atrelados. 2014-11-11 15:31 GMT-02:00 Fabricio Lima lis...@fabriciolima.com.br: Entendi... seu objetivo (q estaria causando o kernel panic) é o MAC + pipes Duvida: -sem as regras de mac address, está tudo carregando normal ne? (pipes por IP) e baixa cpu? -pra estar gerando tanta carga na cpu assim, qual o throughput q estamos falando? (pra saber se a alta demanda de cpu é a filtragem dos MAC, ou o dummynet em si) geralmente eu nao tinha problemas de cpu qndo usava, mas eram poucos clientes aplicados dummynet. tenta refazer suas regras em pf (mas ele so suporta filtragem por mac operando como bridge) ou poderia cogitar migrar os usuarios para pppoe, levantando um servidor de pppoe na sua ponta. se tudo mais falhar, poderia usar uma integraçao dhcp + reserva por mac + dummynet + script levantando o firewall pra este ip dinamicamente, validando a origem do mac, e aplicando sua limitaçao de banda por IP ao inves de mac. ou seja, caso nao resolva, tem 2 paleativos pra vc fugir da alta cpu, com outras soluçoes. ou refazendo em outro fw. mas nao esqueça de responder as perguntas acima. [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 11 de novembro de 2014 14:36, Márcio Elias marcioel...@gmail.com escreveu: Fabricio, eu uso o divert em alguns cases (mais de 20), só que o consumo de cpu e a latência conforme a banda consumida e o número de sub-redes com alias na placa interna aumenta está ficando inviável. A tentativa de utilizar essa forma de NAT é reduzir esse consumo de CPU e também manter uma latência mais baixa na rede. Já tentei com one_pass 1 e 0. Estava testando o FreeBSD 10.1 RC4 para ver se ainda tinha o bug do MAC com PIPE mais o mesmo está dando kernel panic assim que eu ativo o dummynet para controlar a banda (subo as regras do firewall). Vejo relatos deste nat usando libalias deste a versão 8, deve ser algum tratamento diferenciado nos pacotes que obriga a criação de regras de nat diferentes na versão 9, e por isso esteja errando, mais não encontrei a lógica correta. Vi alguns usuários usando duas FIBs, mais não sei se isso seria necessário. -- Att. __ Márcio Elias Hahn do Nascimento Bacharel em Tecnologias da Informação e Comunicação - TIC Cel: (55) 48-8469-1819 Emails: marcioel...@bsd.com.br / marcioel...@gmail.com Skype: marcioeliash...@hotmail.com FreeBSD - The Power To Serve 2014-11-11 12:13 GMT-02:00 Fabricio Lima lis...@fabriciolima.com.br: Talvez o divert natd seja o q esteja funcionando no seu script add divert natd all from 192.168.0.0/16 to any via wan0 eu costumava usar assim, inclusive com pipes. mas o seu one_pass está me fazendo refletir se deveria ser setado em 1 ou nao... [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb.
