Eu tenho o OpenVPN rodando no pfSense 2.3.2. Agora eu tenho isso funcionando principalmente, exceto por uma pequena coisa: eu posso conectar a qualquer coisa na minha rede exceto o próprio servidor pfSense.
Alguns detalhes:
O motivo pelo qual estou usando o tap e o bridging é porque tenho muitos dispositivos da Apple e quero que o Bonjour e outras coisas baseadas em difusão / difusão funcionem corretamente na VPN.
Tudo isso funciona corretamente para qualquer endereço na rede LAN, exceto 172.16.104.1 (o firewall). Nenhum dos clientes pode efetuar ping ou conectar-se a 172.16.104.1 e 172.16.104.1 não pode efetuar ping ou conectar-se a nenhum dos clientes.
Usar o tcpdump revela alguma outra estranheza:
Se eu pingar o servidor de um cliente com o tcpdump em execução em outra sessão, parece que estou recebendo respostas, mas elas não estão sendo reportadas pelo ping?
ping -c2 172.16.104.1
PING 172.16.104.1 (172.16.104.1) 56(84) bytes of data.
--- 172.16.104.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1009ms
Mas na sessão do tcpdump na mesma máquina:
IP 172.16.105.3 > 172.16.104.1: ICMP echo request, id 17069, seq 1, length 64
IP 172.16.104.1 > 172.16.105.3: ICMP echo reply, id 17069, seq 1, length 64
IP 172.16.105.3 > 172.16.104.1: ICMP echo request, id 17069, seq 2, length 64
IP 172.16.104.1 > 172.16.105.3: ICMP echo reply, id 17069, seq 2, length 64
E a partir do servidor pfSense:
tcpdump -n -i ovpns1 -t icmp
tcpdump: WARNING: ovpns1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpns1, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 172.16.105.3 > 172.16.104.1: ICMP echo request, id 17084, seq 1, length 64
IP 172.16.104.1 > 172.16.105.3: ICMP echo reply, id 17084, seq 1, length 64
IP 172.16.105.3 > 172.16.104.1: ICMP echo request, id 17084, seq 2, length 64
IP 172.16.104.1 > 172.16.105.3: ICMP echo reply, id 17084, seq 2, length 64
Esta é uma máquina Ubuntu Linux sem firewall.
Então a máquina pfSense acha que está enviando uma resposta, a máquina Linux acha que está recebendo uma resposta, mas o ping ainda reporta 100% de perda de pacotes?
E se eu fizer um ping em um endereço diferente do servidor, recebo uma resposta:
ping -c2 172.16.104.2
PING 172.16.104.2 (172.16.104.2) 56(84) bytes of data.
64 bytes from 172.16.104.2: icmp_seq=1 ttl=64 time=34.6 ms
64 bytes from 172.16.104.2: icmp_seq=2 ttl=64 time=34.1 ms
--- 172.16.104.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 34.165/34.401/34.638/0.300 ms
E no shell tcpdump:
IP 172.16.105.3 > 172.16.104.2: ICMP echo request, id 17068, seq 1, length 64
IP 172.16.104.2 > 172.16.105.3: ICMP echo reply, id 17068, seq 1, length 64
IP 172.16.105.3 > 172.16.104.2: ICMP echo request, id 17068, seq 2, length 64
IP 172.16.104.2 > 172.16.105.3: ICMP echo reply, id 17068, seq 2, length 64
Aqui está minha configuração do servidor OpenVPN descartada do pfSense:
dev ovpns1
verb 1
dev-type tap
dev-node /dev/tap1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local <omitted>
tls-server
server-bridge 172.16.104.1 255.255.248.0 172.16.105.10 172.16.105.50
client-config-dir /var/etc/openvpn-csc/server1
tls-verify "/usr/local/sbin/ovpn_auth_verify tls '<omitted>' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 172.16.104.0 255.255.248.0"
client-to-client
duplicate-cn
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server1.tls-auth 0
persist-remote-ip
float
mode server
E do cliente:
dev tap
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote <omitted> 1194 udp
lport 0
verify-x509-name "<omitted>" name
pkcs12 udp-1194.p12
tls-auth udp-1194-tls.key 1
ns-cert-type server
Que diabos está acontecendo aqui?
Tags networking vpn openvpn firewall pfsense