OpenVPN туннель PFsense+Mikrotik



  • Приветствую, уважаемые!

    Понадобилось связать две локалки туннелем через интернет. Выбрал OpenVPN, так как много раз такое успешно проделывал в различных комбинациях (серверы под windows/linux, роутеры с openWRT и т.д.). Но на этот раз связка PFsense+Mikrotik не задалась.

    Что сделано:
    PFsense 2.3.4_1 выступает в роли OpenVPN сервера, имеет белый IP, пусть для примера будет 88.88.88.88

    Mikrotik 6.40.1 - в качестве клиента. (его внешний IP пусть будет 99.99.99.99)

    Туннель настроен, маршруты автоматически прописаны, пинги между маршрутизаторами ходят. На этом хорошее заканчивается: с клиентских машин не ходят даже пинги до удалённых машин, и даже не пингуется локальный (192.168.16.254) IP удаленного маршрутизатора.

    Вот таблица маршрутов с PF:
    Internet:
    Destination        Gateway            Flags      Netif Expire
    default            88.88.88.1    UGS        rl1
    192.168.16.0/24    link#1            U          em0
    192.168.16.254      link#1            UHS        lo0 (192.168.16.254 - локальный IP маршрутизатора)
    88.88.88.0/24  88.88.88.1    UGS        rl1
    127.0.0.1          link#7            UH          lo0
    172.16.1.0/24      172.16.1.2        UGS      ovpns1
    172.16.1.1        link#10            UHS        lo0 (172.16.1.1 - IP туннеля на этом конце)
    172.16.1.2        link#10            UH      ovpns1 (172.16.1.2 -  - IP туннеля на удалённом конце)
    192.168.1.0/24    172.16.1.2        UGS      ovpns1  (192.168.1.0/24- подсеть удалённого офиса)

    в ifconfig адаптеру присваивается адрес:

    tap1: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
            options=80000 <linkstate>ether 00:bd:db:c2:00:01
            hwaddr 00:bd:db:c2:00:01
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
            status: no carrier
    ovpns1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
            options=80000 <linkstate>inet6 fe80::219:d1ff:fe9f:f6de%ovpns1 prefixlen 64 scopeid 0xa
            inet 172.16.1.1 --> 172.16.1.2 netmask 0xffffff00
            nd6 options=21 <performnud,auto_linklocal>Opened by PID 21647</performnud,auto_linklocal></linkstate></up,pointopoint,running,multicast></performnud,auto_linklocal></linkstate></broadcast,simplex,multicast> 
    

    Настройки openvpn на стороне сервера:

    dev ovpns1
    verb 6
    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 tcp-server
    cipher AES-256-CBC
    auth SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    tls-server
    server 172.16.1.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc/server1
    ifconfig 172.16.1.1 172.16.1.2
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server' 1"
    lport 2194
    management /var/etc/openvpn/server1.sock unix
    max-clients 5
    push "route 192.168.16.0 255.255.255.0"
    route 192.168.1.0 255.255.255.0
    ca /var/etc/openvpn/server1.ca
    cert /var/etc/openvpn/server1.cert
    key /var/etc/openvpn/server1.key
    dh /etc/dh-parameters.4096
    persist-remote-ip
    float
    topology subnet
    
    

    В логах VPN сервера вылазят такие строки:

    Aug 18 13:22:19 	openvpn 	21647 	client/99.99.99.99:50902 MULTI: bad source address from client [192.168.1.110], packet dropped
    ```  (192.168.1.110 - IP адрес тестовой машины, с которой пущены пинги)
    
    Уже от безнадёжности переключил тип соединения с tun на tap. И, о чудо, пинги пошли и связь установилась. Правда пришлось вручную на PF добавить маршрут в удалённую локалку.
    

    route add 192.168.1.0/24 172.16.1.2

    
    Конфиг сервера при этом стал таким:
    

    dev ovpns1
    verb 3
    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 tcp-server
    cipher AES-256-CBC
    auth SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    tls-server
    server 172.16.1.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc/server1
    ifconfig 172.16.1.1 255.255.255.0
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server' 1"
    lport 2194
    management /var/etc/openvpn/server1.sock unix
    max-clients 5
    push "route 10.132.16.0 255.255.255.0"
    route 192.168.1.0 255.255.255.0
    ca /var/etc/openvpn/server1.ca
    cert /var/etc/openvpn/server1.cert
    key /var/etc/openvpn/server1.key
    dh /etc/dh-parameters.4096
    persist-remote-ip
    float

    
    Теперь почему-то не добавляется маршрут после установки соединения, хотя строчка```
    route 192.168.1.0 255.255.255.0
    ```в конфиге присутствует, но в логах вылазит другая ошибка:```
    
    Aug 18 13:52:57 	openvpn 	17171 	OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
    Aug 18 13:52:57 	openvpn 	17171 	OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.1.0 
    

    Меня бы устроил и tap вариант, лишь бы он нормально отрабатывал переподключения.





  • Пока решил через костыль: прописал в Custom options route-gateway 172.16.1.2.
    Но скорость через туннель крайне низкая, где-то 300кбайт в сек.
    И в логах постоянно записи:

    Aug 18 14:47:48 	openvpn 	3197 	MANAGEMENT: CMD 'quit'
    Aug 18 14:47:48 	openvpn 	3197 	MANAGEMENT: Client disconnected
    Aug 18 14:48:50 	openvpn 	3197 	MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
    Aug 18 14:48:50 	openvpn 	3197 	MANAGEMENT: CMD 'status 2'
    Aug 18 14:48:50 	openvpn 	3197 	MANAGEMENT: CMD 'quit'
    Aug 18 14:48:50 	openvpn 	3197 	MANAGEMENT: Client disconnected
    Aug 18 14:49:51 	openvpn 	3197 	MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
    Aug 18 14:49:52 	openvpn 	3197 	MANAGEMENT: CMD 'status 2'
    Aug 18 14:49:52 	openvpn 	3197 	MANAGEMENT: CMD 'quit'
    Aug 18 14:49:52 	openvpn 	3197 	MANAGEMENT: Client disconnected 
    

    хотя на удалённой стороне в логах обрывов нет.



  • У меня pfsence 2.3.3 и микротик, всё настроенно, всё прекрасно работает.
    Peer-to-peer. tun. Без компрессии. Давайте скрины настроек, фаерволов, маршрутов там и там.



  • Аналогично.
    Несколько филиалов работают с клиентами на Микротик.
    Не осилите - приведу скриншоты.
    По поводу скоростей. Несмотря на TCP-only со стороны Микротика скорости практически равны максимальным по тарифам провайдеров, т.е. 2-2,5 Мегабайт\сек.

    P.S. Для tun про iroute (IPv4 Remote Network/s ) в Client Specific Overrides не забыли?



  • Доброе
    @Sonya:

    Но скорость через туннель крайне низкая, где-то 300кбайт в сек.

    https://habrahabr.ru/post/246953/

    На стороне сервера в Доп. настройках попробуйте :

    sndbuf 100000;
    rcvbuf 100000;
    push "sndbuf 100000";
    push "rcvbuf 100000";
    
    

    И перезапустить туннель.



  • @pigbrother:

    P.S. Для tun про iroute (IPv4 Remote Network/s ) в Client Specific Overrides не забыли?

    Делал по этому руководству, там про iroute нет упоминания. Как это реализовать в pfsense?



  • @werter:

    На стороне сервера в Доп. настройках попробуйте :

    sndbuf 100000;
    rcvbuf 100000;
    push "sndbuf 100000";
    push "rcvbuf 100000";
    
    

    И перезапустить туннель.

    Добавил. Вроде стало чуток получше, пиковая скорость поднялась до 800килов, а средняя осталась прежней. Скорее всего, это потолок для моего подключения.



  • @Sonya:

    @pigbrother:

    P.S. Для tun про iroute (IPv4 Remote Network/s ) в Client Specific Overrides не забыли?

    Делал по этому руководству, там про iroute нет упоминания. Как это реализовать в pfsense?

    iroute оно же - IPv4 Remote Network/s  указывается  в записи в Client Specific Overrides , вручную создаваемой вами для Common Name сертификата вашего Микротик-клиента.



  • @pigbrother:

    IPv4 Remote Network/s  указывается  в записи в Client Specific Overrides , вручную создаваемой вами для Common Name сертификата вашего Микротик-клиента.

    Благодарю за подсказку.
    Прописал в Client Specific Overrides те же параметры, что и в основном соединении, через tun теперь тоже заработало.
    Вопрос можно считать закрытым.



  • Вопрос можно считать закрытым

    А что со скоростью?



  • @pigbrother:

    А что со скоростью?

    Сейчас соединил оба роутера напрямую. Скорость по туннелю 2800 кбайт (внутри локалки 11400 кбайт между теми же машинами). Что с настройками буфера, что без них.
    Такое ощущение, что у туннеля большие накладные расходы.



  • Да, OpenVPN не отличается особой производительностью на не очень мощных устройствах.
    Проверьте загрузку CPU в Микротике под полной нагрузкой, наверняка она будет близка к 100%.



  • Доброе.
    @pigbrother:

    Да, OpenVPN не отличается особой производительностью на не очень мощных устройствах.
    Проверьте загрузку CPU в Микротике под полной нагрузкой, наверняка она будет близка к 100%.

    Дело в том, что МТ умеет OpenVPN только по TCP . Соотвественно все накладные расходы по контролю передачи данных ложатся на CPU уст-ва.

    P.s. И еще. МТ не умеет hw nat. Совсем. И снова все накл. расходы на CPU. Не зря у них CCR по неск. десятков ядер имеют. Без hw nat passthrough по др. никак.



  • Соотвественно все накладные расходы по контролю передачи данных ложатся на CPU уст-ва.
    UDP не сильно разгружает CPU. Тестировал на pfSense, при сходных скоростях разница в загрузке CPU при TCP\UDP не была драматической.
    Дело в "слабости" CPU МТ. IPsec, реализация которого в МТ весьма достойна, тоже ощутимо грузит CPU.
    А так - я вами согласен и ваше писал:
    Проверьте загрузку CPU в Микротике под полной нагрузкой, наверняка она будет близка к 100%.

    И еще. МТ не умеет hw nat.
    В последних версиях появились FastTrack и Fast Path. Это, конечно, не hw nat, но эффект от нововведений ощутим.



  • @pigbrother
    доброго времени суток,
    борюсь с pfsense 2.4.3...
    связка openvpn pfsense(srv)-mikrotik(client)
    все сделал как было сказано выше...
    но сеть видна только в одну сторону. со стороны mikrotik'а я вижу сеть за pfsense, а вот наоборот никак...
    Client Specific Overrides прописан, в таблице маршрутизации запись есть... но пинг на устройства за mikrotik'ом не ходят...
    2_1532336076325_vpn1.JPG
    3_1532336076325_vpn2.JPG
    4_1532336076325_vpn3.JPG
    0_1532336076325_client.JPG
    1_1532336076325_ping.JPG
    0_1532336264234_route.JPG



  • Запись iroute - это часом не настройки сервера? Или все же в Client Specific Overrides. Не вижу упоминаний о common name клиента.



  • @pigbrother
    iroute в Client Specific Overrides.

    ЗЫ: Спасибо добрый человек... была очепятка в common name клиента.
    ее поправил и все полетело :)