Проблема с межсайтовым OpenVPN и pfSense, не пропускающим трафик

Я пытаюсь получить туннель OpenVPN, работающий на pfSense 1.2.3-RELEASE на встроенных маршрутизаторах.

У меня локальная локальная сеть 10.34.43.0/254. Удаленная локальная сеть - 10.200.1.0/24. Локальный pfSense настроен как клиент, а удаленный - как сервер.

Мой туннель OpenVPN внутренне использует диапазон IP-адресов 10.99.89.0/24. На удаленной стороне также есть несколько дополнительных локальных сетей, маршрутизируемых через туннель, но проблема не в них, поскольку у меня происходит сбой подключения до этой точки в цепочке.

Туннель идет нормально, и бревна выглядят здоровыми. Я обнаружил следующее:

Я могу пинговать и telnet в удаленную локальную сеть и дополнительные удаленные локальные сети из локальной оболочки pfSense.
Я не могу подключиться к удаленным локальным сетям с помощью ping или telnet из локальной сети.
Я не могу пинговать или telnet в локальную сеть из удаленной LAN или удаленной оболочки pfSense.
Если я tcpdump интерфейсы tun с обеих сторон и пингую из локальной LAN, я вижу, что пакеты попадают в туннель локально, но они не появляются на удаленной стороне (и не появляются на интерфейсе удаленной LAN, если я tcpdump это).
Если я tcpdump интерфейсы tun с обеих сторон и пингую из локальной оболочки pfSense, я вижу, что пакеты попадают в туннель локально и выходят с удаленной стороны. Я также могу tcpdump удаленного интерфейса LAN и видеть, как они проходят там тоже.
Если я tcpdump интерфейсы tun с обеих сторон и пингую из удаленной оболочки pfSense, я вижу, что пакеты попадают в удаленную оболочку tun, но не выходят из локальной.

Вот файл конфигурации, который использует удаленная сторона: -

#user nobody
#group nobody
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
dev tun
proto udp
cipher BF-CBC
up /etc/rc.filter_configure
down /etc/rc.filter_configure
server 10.99.89.0 255.255.255.0
client-config-dir /var/etc/openvpn_csc
push "route 10.200.1.0 255.255.255.0"
lport <port>
route 10.34.43.0 255.255.255.0
ca /var/etc/openvpn_server0.ca
cert /var/etc/openvpn_server0.cert
key /var/etc/openvpn_server0.key
dh /var/etc/openvpn_server0.dh
comp-lzo
push "route 205.217.5.128 255.255.255.224"
push "route 205.217.5.64 255.255.255.224"
push "route 165.193.147.128 255.255.255.224"
push "route 165.193.147.32 255.255.255.240"
push "route 192.168.1.16 255.255.255.240"
push "route 192.168.2.16 255.255.255.240"

Вот локальная конфигурация: -

writepid /var/run/openvpn_client0.pid
#user nobody
#group nobody
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
dev tun
proto udp
cipher BF-CBC
up /etc/rc.filter_configure
down /etc/rc.filter_configure
remote <host> <port>
client
lport 1194
ifconfig 10.99.89.2 10.99.89.1
ca /var/etc/openvpn_client0.ca
cert /var/etc/openvpn_client0.cert
key /var/etc/openvpn_client0.key
comp-lzo

Вы можете увидеть соответствующие части таблиц маршрутизации, извлеченные из pfSense, здесь http://pastie.org/5365800

Локальный брандмауэр разрешает все ICMP из локальной сети, а моему ПК разрешено все куда угодно. Удаленный межсетевой экран считает свою локальную сеть надежной и разрешает весь трафик на этом интерфейсе.

Может ли кто-нибудь подсказать, почему это не работает, и что я могу попробовать дальше?

С SSL / TLS между сайтами VPN вам нужен маршрут на сервере и iroute в специфическом для клиента переопределении. Описание здесь похоже на то, что вам не хватает этого iroute. В отличие от общего ключа, где достаточно маршрута на сервере. В случае таких VPN маршрут на сервере отправляет этот трафик в этот конкретный экземпляр OpenVPN, а его внутренняя маршрутизация через iroutes должна знать, какой клиент маршрутизирует эту конкретную сеть.

В разделе VPN> OpenVPN, вкладка Client Specific Override, добавьте новую запись. Для «Общее имя» введите CN из сертификата на стороне клиента. В поле «Дополнительно» введите «iroute 10.34.43.0 255.255.255.0» (без кавычек). Для остальных оставьте значения по умолчанию, нажмите «Сохранить». Перезапустите клиент OpenVPN, выбрав «Состояние»> «Службы» в клиентской системе, и после повторного подключения он должен работать, если это действительно отсутствующий iroute.