Procura no youtube. Por lá tu vai encontrar alguma coisa pra te auxiliar.

Após verificar melhor a lista de compatíveis é que me apercebi que de facto esta pen n\ao é compatível, o iDProduct desta pen é o 0x1c05.

Na verdade, a partir do RDP 8 (Windows 7 + ) ele também pode usar a UDP para melhorar a performance https://blogs.technet.microsoft.com/enterprisemobility/2013/04/09/get-the-best-rdp-8-0-experience-when-connecting-to-windows-7-what-you-need-to-know/

o link 1 caiu, e o 2 estava instavel… então, assumimos o link 1 como off-line de verdade, e o 2 como estava oscilando, pelo monitoramento, provavelmente pela latência ou perda de pings, o pfsense também o considerou off-line. regule os thresholds dentro da aba SYSTEM --> ROUTING e em STATUS --> SYSTEM LOGS --> GATEWAYS você consegue saber porque/como caiu os 2 links

Tu tem uma regra liberando o acesso da VLAN pra LAN?

@rvl: empbilly, valeu pelo help atraves do video consegui me orientar e resolvi o problema. forte abraço! Show de bola!! :D Abraço,

rafamello Tive a mesma situação e fiz o seguinte; Retira os alias do Bypass no squid, reinicia o serviço e testa se navegação está gerando o log. Se der certo, um dos seus alias precisa ser editado/revisado. Espero ter ajudado.

@empbilly: Qual o endereço link dos modulos que tu baixou? esse mesmo que vc citou so que em outro tutorial que mandei o link. Tambem tentei baixar no site da realtek. so que lá vieram outros 2 arquivos. if_re.c if_rereg.h um Makefile. e readme: Mas não tenho intimidade assim com o kernel ainda mais freebsd. ================================================================================= =  Realtek 8169S/8169SB/8169SC/8168B/8168C/8168CP/8168D/8168DP/8168E/8168F      = =  8168FB/8168G/818GU/8168H/8168EP/8411                                        = =  8101E/8102E/8103E/8401/8105E/8106E/8402 Driver                              = =  for FreeBSD v4.x/5.x/6.x/7.x/8.x/9.x                                        = ================================================================================= This driver is modified by Realtek Semiconductor corp. and it has been tested OK on FreeBSD v5.4, FreeBSD v6.4, FreeBSD v7.3, FreeBSD v8.0, and FreeBSD v9.0\. To update the driver, you may use method 1\. If method 1 failed, you must use method 2 which is more complex. Method 1: 1.Copy if_re.ko in "modules" directory to "/modules" directory and overwrite   the existing file. 2.Modify the file "/boot/defaults/loader.conf" and set "if_re_load" in "Network   drivers" section to "Yes" 3.Reboot. Method 2: Because the FreeBSD kernel has default drivers to support RTL8139C and RTL8169S. To use the RTL8139C+, RTL8169SB, RTL8169SC, RTL8168B, and RTL8101E, you need to update your NIC driver by recompiling your FreeBSD kernel. The main steps you have to do:(FreeBSDSrcDir means the directory of FreeBSD source code and it may be "/usr/src/sys") 1\. keep the orginal driver source code: # cd /usr/src/sys/dev/re # cp if_re.c if_re.c.org # cd /usr/src/sys/modules # cp Makefile Makefile.org # cd /usr/src/sys/modules/re # cp Makefile Makefile.org # cd /usr/src/sys/i386/conf/ # cp GENERIC GENERIC.org 2\. recompile your kernel (you must install your FreeBSD source code first !!) # vim /usr/src/sys/i386/conf/GENERIC and delete re # vim /usr/src/sys/modules/Makefile and delete re # cd /usr/src/sys/i386/conf # /usr/sbin/config GENERIC (for FreeBSD 5.x/6.x/7.x/8.x/9.x) # cd ../compile/GENERIC (for FreeBSD 4.x) # cd ../../compile/GENERIC # make cleandepend # make depend # make # make install # reboot 3\. update the driver source code:     Copy the dirver source code( if_re.c and if_rereg.h) into /usr/src/sys/dev/re     Copy the Makefile into /usr/src/sys/modules/re 4\. build the driver: # cd /usr/src/sys/modules/re # make clean # make 5\. install the driver # cd /usr/src/sys/modules/re # kldload ./if_re.ko 6\. configurate the static IP address # ifconfig re0 xxx.xxx.xxx.xxx 7\. configurate the IP address by DHCP # /sbin/dhclient re0

@marcelloc: Instale o pacote cron e remova a linha que executa o sarg. Valeu. Muito obrigado.

Me desculpe, em nenhum momento me passou que poderia ser bloqueio do Windows. Pesquisei a manhã toda, acredite, mas não me ocorreu esse "detalhe". De fato foi isso: C:\Windows\system32>dnscmd /info /globalqueryblocklist Query result: String:  wpad String:  isatap Command completed successfully. Acabei dando meia volta ao mundo enquanto a solução é bem mais fácil. Muito obrigado

@chipbr: Saiu update do pf2ad para 2.3.3 Alguem ja testou? Não consigo parar meu ambiente para testar no momento  :-[ [/quote] Como informei no primeiro post, eu fiz o teste com a versão do pf2ad para o pfsense 2.3.2 no 2.3.3 e funcionou belezinha, sem problemas. Utilizei a que possui o Samba4 (beta). Vi também que saiu agora para o 2.3.3, não testei ainda mais creio não ter muita diferença em relação a 2.3.2( já que o da 2.3.2 funcionou no 2.3.3) e que deve funcionar normalmente. Assim que eu testa-la, venho informar.

Aqui usando Chrome 56.0.2924.87 também os campos não mudam ao trocar o tipo. Com Edge, funcionou normal. OBS: você quer criar um alias CARP? Senão, os campos que vem habilitados no IP alias são realmente os que precisam.

Mano, não ressuscita tópico de 1 ano atrás….

veja isso https://forum.pfsense.org/index.php/topic,39470.0.html

boa noite. Amigo utilizo CP + radius com banco de dados interno do PF sem nenhum problema, os roteadores são openwrt tb, creio que seu problema esteja na comunicação com o servidor Mysql externo, no CP tem uns parâmetros para ativar o envio dos dados para o sv do radius, pode ser que ajude. Dá uma olhada nisso, recomendo rodar com banco interno do freeradius no PF pra ver se continua o problema. Boa sorte.

Resolvido. https://forum.pfsense.org/index.php?topic=126065.msg697933#msg697933

@hugoeyng: @empbilly: @hugoeyng: Olá. Meu pfSense está na versão 2.3.3. Uso o UltraVNC (reverso) para prestar suporte remoto a usuários. O cliente "chama" o suporte remoto e uma mensagem é exibida aqui no servidor interno e o técnico atende. Configurei NAT para e liberei as portas no Firewall (pfSense). Isso tem funcionado há uns quatro anos. Desde sexta-feira parou de funcionar. De que maneira eu posso saber se é o pfSense que está impedindo a conexão ou se é alguma outra coisa? Tem como filtrar o trafego entrando pelo pfSense (talvez tcpdump) ou alguma outra forma no shell ou na GUI? Pode utilizar o tcpdump via ssh e também via Diagnostics > Packet Capture. Até o tráfego rejeitado é exibido nessas opções? Acabei tendo que desligar o servidor e religar. Aparentemente o antivírus é que estava travado. Reiniciar não foi o suficiente. Aliás, tentei desligar pelo Shell e ele não desliga tive desligar pelo On/Off do computador.

Depois de sofrer um pouco e fazer alguns ajustes, o erro na porta 953 parou. porén ainda continuo sem saber em que lugar devo colocar a chave RNDC gerei a chave RNDC com o comando rdc-confgen -a o correto agora é adicionar ao named.conf key "rndc-key" { algorithm hmac-md5; secret "nxi2/a+06VMbMtXGQvRzDA=="; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; Bom ate aqui tudo bem. observei que tenho dois named.conf um no chroot em /cf/named/etc/namedb//named.conf (inclusive ele tem a linha já pronta para eu apenas colocar a chave, porém no arquivo esta escrito para não editar ele) [image: Captura_de_Tela_2017_02_27_a_s_09_11_33.png] e tenho o named.conf em /usr/local/etc/namedb/named.conf (aqui o link do arquivo inteiro http://txt.do/d138n) e também em services > Bind DNS eu vi que tem os seguinte campos [image: Captura_de_Tela_2017_02_27_a_s_09_16_12.png] eu tentei colocar key "rndc-key" { algorithm hmac-md5; secret "nxi2/a+06VMbMtXGQvRzDA=="; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; nos dois campos, mais o serviço do bind para e não inicia mais ate eu remover o texto acima. em resumo, estou perdido e não sei aonde devo colocar a chave RNDC

o problema é que na instalação do bind, ele automaticamente já cria o CHROOT para o Bind, porém no CHROOT faltava o arquivo keys. Copiei ele e agora esta tudo certinho.

Depois de um longo tempo, o problema voltou a surgir. O assunto está sendo tratado neste post: https://forum.pfsense.org/index.php?topic=126131.new;topicseen