pfSense A VPN Site-toSite com o OpenVPN se conecta, mas não roteia o tráfego

Question

Usando dois roteadores pfSense, criei uma VPN de chave compartilhada entre dois sites. Ambos os roteadores são pfSense 1.2.2. A caixa pfSense no site do cliente é o roteador de gateway para esse site, mas no site do servidor o pfSense NÃO é o gateway para essa LAN. O site do cliente se conecta ao site do servidor e recebo a mensagem de log "Sequência de inicialização concluída", indicando que a conexão foi bem-sucedida.

No site do cliente, posso usar qualquer máquina na LAN do cliente para fazer ping na caixa pfSense no site do servidor em seu endereço de LAN (e até mesmo configurá-la pela interface da Web, para que a VPN funcione para esse endereço em menos). Também posso executar o ping nos dois endereços no intervalo de IP "Interface IP" (configuração do cliente) / "Pool de endereços" (configuração do servidor), que são da mesma sub-rede privada e NÃO estão nos intervalos de LAN do cliente ou servidor.

O problema é que não consigo acessar nenhum outro IP na LAN do site do servidor. Eu não preciso poder acessar máquinas na LAN do site do cliente a partir do site do servidor, mas eu preciso ser capaz de obter mais do que apenas o servidor do site do cliente. Atualmente, qualquer pessoa na LAN do cliente pode fazer ping até a interface da LAN do servidor, e qualquer pessoa na LAN do cliente pode receber um ping do próprio servidor do pfSense, mas não da LAN do servidor. Eu adicionei um < > qualquer regra nas regras de firewall da interface da LAN no servidor.

Se eu capturar o tráfego na interface de LAN do servidor, vejo pacotes passados do site de LAN do cliente, mas se eu cheirar não vejo esses pacotes fazendo isso na LAN do servidor. Como eu disse, eu adicionei uma regra na interface LAN para permitir any-to-any como abaixo, então o que mais eu preciso fazer para permitir o tráfego do túnel para a LAN e vice-versa?

Atualização: adicionei uma rota de envio para a LAN do servidor no cliente pfSense e vice-versa. Eu também tentei atualizar para o RC do pfSense 1.2.3 e adicionar uma interface Opt1 definida para tun0, em seguida, adicionando regras de permissão entre opt1 e a LAN. Ainda sem sorte.

Atualização 2: Necessário para definir o roteamento correto na LAN do servidor conforme descrito na resposta aceita, mas deixei de mencionar que a unidade pfSense / OpenVPN do servidor estava sendo executada como um sistema operacional convidado no KVM e a outra metade do problema era que o encaminhamento de IP precisava ser ativado no /etc/ufw/before.rules do sistema operacional host. Isso é o que eu recebo por não explicar a configuração mais completamente.

    

Answer 1

Veja o que pode ser um problema. Imagine que você tenha a seguinte rede:

address pool: 10.1.1.0/255.255.255.0
router: 10.1.1.1
internal interface on internal vpn server: 10.1.1.2
some external machine that VPNs to network: 10.2.2.2
some internal client machine: 10.1.1.90

Quando você tenta acessar o SIC da caixa VPN externa, a rota de tráfego é assim:

• 10.2.2.2
• vpn (internet)
• 10.1.1.2
• 10.1.1.90
• OK

Parece bom, NO ENTANTO, para que o tráfego flua, a máquina 10.1.1.90 deve ser capaz de responder e isso significa que os pacotes devem ser roteáveis para 10.2.2.2 também. O cliente interno tem obviamente ip: 10.1.1.90, mask: 255.255.255.0 e roteador: 10.1.1.90. Portanto, os pacotes seriam roteados assim:

• 10.1.1.90
• 10.1.1.1 (seno é roteador e 10.2.2.2 não é endereçável diretamente)
• internet
• NÃO ENCONTRADO

Basicamente, os pacotes de resposta nem chegam à VPN. O que você pode fazer? Obviamente, o que vai funcionar é adicionar rota ao cliente interno para rotear todos os pacotes para 10.2.2.2 não para a caixa VPN em vez do roteador, como (caixa do Windows):

route add 10.2.2.0 mask 255.255.255.0 10.1.1.2

isso resolverá o problema no nível de uma única máquina. Pacotes de resposta irão:

• 10.1.1.90
• 10.1.1.2 (rota explícita)
• vpn (internet)
• 10.2.2.2

Para resolver o problema no nível da rede, você deve modificar o roteador em um mesmo assunto para redirecionar todo o tráfego que vai para 10.2.2.0 a 10.1.1.2. Desta forma, o pacote de resposta irá:

• 10.1.1.90
• 10.1.1.1
• 10.1.1.2
• vpn (internet)
• 10.2.2.2

Outra solução é: faça sua caixa VPN para NAT na interface 10.1.1.2. Desta forma, para máquinas internas, parecerá que todo o tráfego é originário do 10.1.1.2, e as respostas irão para 10.1.1.2. Eu aconselharia a passar pelo roteamento, já que o NAT exigirá recursos adicionais na caixa VPN para rastreador de conexão

    

Answer 2

Você criou regras de firewall para permitir que o tráfego flua onde você deseja?