Почему не пингуется локалка за VPN?

Question

[Андрей]

Имеем настроенный Openvpnserver на Pfsense (Mode: Peer to Peer ( SSL/TLS )) + подключенный к нему mikrotik.
полученный клиентом ip 10.0.78.2 с сервера 10.0.78.1 (Pfsense) пингуется, но когда пытаюсь пропингавать комп в локалке за микротиком или бридж микротика (192.168.11.1) пинг не идёт .

Настройки фаервола

0    ;;; Input
      chain=input action=accept connection-state=established,related log=no 
      log-prefix="" 

 1    chain=input action=accept protocol=icmp log=no log-prefix="" 

 2    chain=input action=accept protocol=tcp src-address-list=WanAcceptIP 
      in-interface-list=WAN dst-port=8291 log=no log-prefix="" 

 3    ;;; DNS
      chain=input action=accept protocol=udp in-interface-list=LAN dst-port=53 
      log=no log-prefix="" 

 4    ;;; Dostup   Mikrotik iz Lan
      chain=input action=accept protocol=tcp in-interface-list=LAN 
      dst-port=8291 log=no log-prefix="" 

 5    chain=input action=accept protocol=tcp in-interface-list=LAN dst-port=80 
      log=no log-prefix="" 

 6    ;;; Ping  accept
      chain=input action=accept protocol=icmp in-interface=bridge1 log=no 
      log-prefix="" 

 7    ;;; drop all input
      chain=input action=drop connection-state=invalid log=no log-prefix="" 

 8    chain=input action=drop log=no log-prefix="" 

11    chain=forward action=accept protocol=icmp log=no log-prefix="" 

12    chain=forward action=accept out-interface=VpntoUSA in-interface-list=LAN 
      log=no log-prefix="" 

13    chain=forward action=accept in-interface=VpntoUSA out-interface-list=LAN 
      log=no log-prefix="" 

14    chain=forward action=accept in-interface-list=LAN out-interface-list=WAN 
      log=no log-prefix="" 

15    chain=forward action=accept connection-state=established,related log=no 
      log-prefix="" 

16    ;;; drop all forward
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

17    chain=forward action=drop log=no log-prefix=""

nat

0    chain=srcnat action=masquerade out-interface=ether1 log=no log-prefix=""

rout на микротик

[dracon@MikroTik] > /ip route print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, d - DHCP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS      GATEWAY        DISTANCE
DAd 0.0.0.0/0        94.180.57.254         1
DAc 10.0.78.0/24     VpntoUSA              0
DAc 10.0.78.0/32     VpntoUSA              0
DAc 94.180.57.0/24   ether1                0
DAc 192.168.11.0/24  bridge1               0

Подскажите в чем проблема ?

Comments

[Юрий MikroTik]

Обратный маршрут на pfSense не увидел
Покажи трассировку

[Андрей]

Гммм а разве это не они ?

DAc 10.0.78.0/24     VpntoUSA              0
DAc 10.0.78.0/32     VpntoUSA              0

К сожалению сейчас нет доступа к устройствам в локалке за микротом(Но насколько я помню трафик доходит до 192.168.11.1 это bridge и далше не идёт)
с самого микрота (10.0.78.2 он же VpntoUSA интерфейс который создается при подклчении по openvpn к серверу )

[dracon@MikroTik] > /tool traceroute 10.0.78.1                               
Columns: ADDRESS, LOSS, SENT, LAST, AVG, BEST, WORST, STD-DEV
#  ADDRESS    LOSS  SENT  LAST     AVG    BEST   WORST  STD-DEV
1  10.0.78.1  0%       6  146.9ms  209.2  146.7  292.4       63

С бриджа

[dracon@MikroTik] > /tool traceroute address=10.78.0.1 src-address=192.168.11.1
Columns: ADDRESS, LOSS, SENT, LAST, AVG, BEST, WORST, STD-DEV
#  ADDRESS          LOSS  SENT  LAST     AVG  BEST  WORST  STD-DEV
1  176.214.183.253  0%       1  0.9ms    0.9  0.9   0.9          0
2                   100%     1  timeout                           
3                   100%     1  timeout                           
4                   100%     1  timeout                           
5                   100%     1  timeout                           
6                   0%       1  0ms

[theurs]

2 основных причины какие надо проверить - обратные маршруты и отвечают ли клиенты на пинги вообще (винда по умолчанию никому не отвечает)

[Ziptar]

Андрей,
pfsence уведомлен о том, что должен искать путь к 192.168.11.0/24 через 10.0.78.2?

[Андрей]

Ziptar, да маршрут есть

[Ziptar]

Андрей, не обратил внимание на трассировку с бриджа микрота; он сразу же к провайдеру уходит. Ничего в routing policy не накурочено случаем?
upd ну хотя вряд ли, были бы видны следы в таблице маршрутов

[Ziptar]

Андрей, если используешь tun интерфейс, а не tap - попробуй использовать tap

[Андрей]

Ziptar, Два пива этому писателю. Переключил все на tap в mikrote и pfsense. Добавил gateway на pfsense на полученный микротом ip и static routes на локалку за микротом и трафик пошел

[Ziptar]

Андрей, ValdikSS как-то писал, что там нужна l2 связность для таких случаев (поэтому tap а не tun), я сам плохо понимаю зачем для l3 маршрутизации нужна l2 связность, есть смутные догадки на тему того, как работают on-link маршруты, но проверять и уточнять как-то не досуг всё

[agpecam]

В pfSense в настройках сервера пропишите IPv4 Remote Network/s: 192.168.11.0/24 - у OpenVPN есть внутренний маршрутизатор, системных маршрутов в сеть клиента недостаточно

[Ziptar]

agpecam, intenal routing по-дефолту выключен, емнип (включается опцией client-to-client)

[agpecam]

Ziptar, а что по-вашему мешает нескольким клиентам подключаться к одному серверу в режиме tun? И как различать какая за кем сеть? В pfSense есть даже специальный режим Remote Access (SSL/TLS + User Auth) и он таки может быть tun. И для него приходится прописывать сети за клиентами в Client Specific Overrides, а клиенты различаются по common name в их сертификатах. То же самое справедливо для режима Peer to Peer ( SSL/TLS ), как у автора, что конечно несколько контринтуитивно и Client Specific Overrides в этом случае действительно не нужно, но, тем не менее такова реализация в данном конкретном случае

[Ziptar]

agpecam, то есть iroute работает в любом случае, и это мешает прозрачной маршрутизации в tun режиме? А на tap воздействия не оказывает, потому что l2 и фактически iroute в трафик не лезет?

[agpecam]

Ziptar, давайте посмотрим конфиги сгенеренные pfSense:
Remote Access (SSL/TLS + User Auth):

dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
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 udp4
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 134.19.xxx.xxx
tls-server
server 172.27.1.0 255.255.255.0
client-config-dir /var/etc/openvpn/server1/csc
username-as-common-name
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user TG9jYWwgRGF0YWJhc2U= true server1 1194
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'openvpn-s1' 1"
lport 1194
management /var/etc/openvpn/server1/sock unix
remote-cert-tls client
capath /var/etc/openvpn/server1/ca
cert /var/etc/openvpn/server1/cert 
key /var/etc/openvpn/server1/key 
dh /etc/dh-parameters.1024
data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC
data-ciphers-fallback AES-128-CBC
allow-compression asym
persist-remote-ip
float
topology subnet

- здесь есть client-config-dir /var/etc/openvpn/server1/csc - т. е. в терминах pfSense - Client Specific Overrides, где и прописаны маршруты в сеть клиента.

Peer to Peer ( SSL/TLS ):

dev ovpns5
verb 1
dev-type tun
dev-node /dev/tun5
writepid /var/run/openvpn_server5.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 134.19.xxx.xxx
tls-server
server 172.27.5.0 255.255.255.0
client-config-dir /var/etc/openvpn/server5/csc
ifconfig 172.27.5.1 172.27.5.2
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'openvpn-s1' 1"
lport 1196
management /var/etc/openvpn/server5/sock unix
route 192.168.55.0 255.255.255.0
capath /var/etc/openvpn/server5/ca
cert /var/etc/openvpn/server5/cert 
key /var/etc/openvpn/server5/key 
dh /etc/dh-parameters.1024
data-ciphers AES-128-GCM:AES-128-CBC
data-ciphers-fallback AES-128-CBC
allow-compression asym
persist-remote-ip
float
topology subnet
reneg-sec 0

- здесь есть route 192.168.55.0 255.255.255.0 - маршрут в сеть клиента, даже, не смотря на то, что клиент по сути один
https://community.openvpn.net/openvpn/wiki/RoutedLans

[Ziptar]

agpecam, ок, спасибо, действительно контринтуитивно, хотя в целом понятно зачем так сделано

Answer 1

[Андрей]

Проблема решена (коменты под 1 постом). Использовать tap , не забываем прописать маршрут к локалке за микротом в static routes на pfsense.

Answer 2

[hint000]

На сервере OpenVPN нужно создать файл:
/etc/openvpn/ccd/имяКлиента
имяКлиента - такое, как задавали при создании ключей для клиента
внутри файла должна быть строчка с маршрутом:
push "route 192.168.11.0 255.255.255.0"
Кроме того в конфиге сервера должны бчть строчки:
client-config-dir ccd
route 192.168.11.0 255.255.255.0

Я хз, почему в OpenVPN требуется в двух местах прописывать маршрут, но факт остаётся фактом: если прописать в одном месте, то не работает. :)

Кроме того в файл /etc/openvpn/ccd/имяКлиента можно добавить
iroute 192.168.22.0 255.255.255.0
если захочется, чтобы и серверу была доступна локалка за клиентом (вместо 192.168.22.0 прописать вашу клиентскую локалку).

А, погодите... Микротик у вас на стороне сервера или на стороне клиента? Из вопроса не совсем понятно. Если на стороне клиента, то поменяйте местами route и iroute.

Comments

[Андрей]

Микротик на стороне клиента . Использую связку Pfsense+mikrotik