[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] 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] 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] 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.
