LINUX.ORG.RU
решено Форум — Admin  

mikrotik ipsec + strongswan и проблемы с mtu?

 , ,


0

2

всем привет, настраиваю ipsec между микротиком и strongswan столкнулся с проблемой, не знаю как победить, помогите пожалуйста туннель поднялся: 

#ip xfrm state
src - dst -
        proto esp spi 0x0223bc31 reqid 1 mode tunnel
        replay-window 32 flag nopmtudisc af-unspec
        auth-trunc hmac(sha1) 0xacb19fcf0117373368b89bfeb6418cb879fcb9e6 96
        enc cbc(aes) 0x629f57cfff27bbbe9c5f1a5e8b462ecd
src - dst -
        proto esp spi 0xcd27d8a8 reqid 1 mode tunnel
        replay-window 32 flag nopmtudisc af-unspec
        auth-trunc hmac(sha1) 0x00191b3ae74495e657231e71aa7a0b81537b8bee 96
        enc cbc(aes) 0x2905a01d846c7e2371835097fb77979a
пинг ходит

telnet 192.168.1.98 22 (машина в удаленной сети) дает приглашение

а вот дальше начинается интересное. тем же putty открыть 192.168.1.98 22 уже не могу, отваливается по таймауту к веб серверу в удаленной сети тоже подключиться не могу

вот пинги : 

C:\Users\rr>ping -f -l 1472 192.168.1.98

Обмен пакетами с 192.168.1.98 по с 1472 байтами данных:
Ответ от 192.168.1.98: число байт=1472 время=10мс TTL=62
Ответ от 192.168.1.98: число байт=1472 время=14мс TTL=62

C:\Users\rr>ping -f -l 1473 192.168.1.98

Обмен пакетами с 192.168.1.98 по с 1473 байтами данных:
Требуется фрагментация пакета, но установлен запрещающий флаг.

это я уже отключил nat-t чтобы меньше оверхед в пакете был, думал дело в этом.

подскажите куда копать, если надо могу конфиги подробнее скинуть спасибо!


Попробуй в iptables -t mangle -A OUTPUT добавить на удаленную подсеть с IPsec правило с таргетом TCPMSS со значением скажем в 1400 (или можешь точно посчитать, 1472 - 20 (IPv4 hdr) - 20 (TCP header) = 1432)

whoami ★
()

не помогло к сожалению это правило. я делал подобное правило цепочке forward, также не помогло.

блин ребят подскажите куда копать?? я вечерком дома буду сдамплю пакеты и сюда скину. а то у меня мысли чета вообще кончились (

vlad_t
() автор топика
Ответ на: комментарий от vlad_t

На микротике подобное тоже нужно настроить, иначе пакеты от винды могут не проходить.

whoami ★
()
Ответ на: комментарий от anton_jugatsu 
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-128-cbc lifetime=8m
/ip ipsec peer
add address=88.88.88.3/32 enc-algorithm=aes-128 lifetime=8m nat-traversal=no secret=AtDykgecatNiph7
/ip ipsec policy
add dst-address=192.168.1.0/24 sa-dst-address=88.88.88.3 sa-src-address=77.77.77.4 src-address=192.168.20.0/24 tunnel=yes

внешние адреса поменял, остальное оставил как есть

пытаюсь подключиться с адреса 192.168.1.28 к 192.168.20.101 по RDP а теперь самое интересно (микротик и сеть 192.168.20.0/24 при этом для меня удаленные шлюз и сеть) хотел пакеты засниффить на микротике чтобы сюда выложить так вот как только я включаю сниффер, соединение устанавливается как ни в чем не бывало О_о выключаю сниффер, все по прежнему, пинг работает, соединение не устанавливается, рвется по таймауту

в общем я выкладываю скриншот, там размер пакета виден, может дело в нем? http://prntscr.com/b3fece

это tcpdump c шлюза 192.168.1.1 (сейчас я в этой сети нахожусь) при выключенном сниффере на удаленном микротике 

09:27:50.806921 IP (tos 0x0, ttl 128, id 23053, offset 0, flags [DF], proto TCP (6), length 87)
    192.168.1.28.37074 > 192.168.20.101.3389: Flags [P.], cksum 0x25eb (correct), seq 2954449220:2954449267, ack 3839071636, win 64308, length 47
09:27:55.607154 IP (tos 0x0, ttl 128, id 23238, offset 0, flags [DF], proto TCP (6), length 87)
    192.168.1.28.37074 > 192.168.20.101.3389: Flags [P.], cksum 0x25eb (correct), seq 0:47, ack 1, win 64308, length 47
09:27:57.379133 IP (tos 0x0, ttl 128, id 23330, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.28.36985 > 192.168.20.101.47913: Flags [R.], cksum 0x7ca8 (correct), seq 3219730403, ack 2473381241, win 0, length 0
09:27:57.379182 IP (tos 0x0, ttl 128, id 23331, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.28.36984 > 192.168.20.101.47913: Flags [R.], cksum 0x2861 (correct), seq 413668585, ack 40596735, win 0, length 0
а вот дамп оттуда же, но при включенном выбрал кусочек рандомно т.е. это когда соединение работает

09:29:19.866543 IP (tos 0x0, ttl 126, id 10228, offset 0, flags [none], proto TCP (6), length 221)
    192.168.20.101.3389 > 192.168.1.28.37515: Flags [P.], cksum 0x15d6 (correct), seq 3568:3749, ack 313, win 64049, length 181
09:29:19.867592 IP (tos 0x0, ttl 128, id 26998, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.28.37515 > 192.168.20.101.3389: Flags [.], cksum 0x6146 (correct), seq 313, ack 3749, win 63480, length 0
09:29:19.877835 IP (tos 0x0, ttl 126, id 10229, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.20.101.3389 > 192.168.1.28.37515: Flags [.], cksum 0x8440 (correct), seq 3749:5209, ack 313, win 64049, length 1460
09:29:19.878267 IP (tos 0x0, ttl 126, id 10230, offset 0, flags [none], proto TCP (6), length 1500)
    192.168.20.101.3389 > 192.168.1.28.37515: Flags [.], cksum 0x6c52 (correct), seq 5209:6669, ack 313, win 64049, length 1460
09:29:19.878283 IP (tos 0x0, ttl 126, id 10231, offset 0, flags [none], proto TCP (6), length 421)
    192.168.20.101.3389 > 192.168.1.28.37515: Flags [P.], cksum 0xfdbb (correct), seq 6669:7050, ack 313, win 64049, length 381
09:29:19.879583 IP (tos 0x0, ttl 128, id 26999, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.28.37515 > 192.168.20.101.3389: Flags [.], cksum 0x52a2 (correct), seq 313, ack 6669, win 64308, length 0

вот где-то рядом уже, но где ))))

vlad_t
() автор топика
Ответ на: комментарий от targitaj

блин так у меня policy routing же, маршрута нет в ip r я пробовал сделать ip route change default via цензура mtu lock 1300 не помогло

ребят смотрите чего нашел у забугорных коллег https://lists.strongswan.org/pipermail/users/2014-August/006499.html афаик пакет, направленный в туннель ipsec проходит файрвол дважды - один раз до шифрации, другой - после. может снять с него флажок df до шифрования? но я что-то не нашел способа. есть идеи?

и еще такой момент пришел в голову. Ведь когда включаю сниффер, пакеты ходят. Получается до микротика они доходят, когда сниффер выключен.

Куда еще копнуть?

vlad_t
() автор топика

Когда с циской впн настраивали, постоянно отваливался тунель. Проблема решилась обновлением микротика. Так что попробуй, чем черт не шутит.

Deleted
()
Ответ на: комментарий от vlad_t

есть идеи? )) микротик обновлён также.

пока в качестве воркэраунда ssh-сессия с хоста поднтята, а там уже сниффер запущен )))

anton_jugatsu ★★★★
()
Ответ на: комментарий от Deleted

не, с dpd слава богу проблем вроде нет, соединение у меня стабильное но последний пост в треде по ссылке доставил Х)

ну что, похоже надо писать в форумы микротика и мейллисты стронгсвана, потому как у меня сейчас все работает по такому же принципу как и у anton_jugatsu, разве что без ssh сессии, но это просто гнуснейший костыль имхо, оставлять все в таком виде не хочу ))))

кстати, с openswan у меня такой же микротик работает, норм, без всяких снифферов. Собственно я с той парочки (openswan + mikrotik) и брал настройки ipsec.conf и файрвола, как-то раз давно помнится поднял такую связку и тиражирую ее теперь если надо. А вот со стронгсваном не прокатило. Да и некоторые директивы работавшие в openswan в стронгсване не работают.

vlad_t
() автор топика
Ответ на: комментарий от vlad_t

как только я включаю сниффер, соединение устанавливается как ни в чем не бывало

Включить promiscuous mode на интерфейсе.

anc ★★★★★
()
Ответ на: комментарий от anton_jugatsu

Как это связано?

tcpdump переводит интерфейс в promiscuous (если не был включен) при выходе возвращает назад.
А вот почему только так работает, у меня особо мыслей нет. Что там на микротике накрутили неизвестно.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)

господа, проблема решена и как обычно rubber duck debugging рулит в общем сел я описывать проблему на http://forum.mikrotik.com/ ну и соответственно пробежался по настройкам еще раз. тупняк детектед, оказалось не было правила в файрволе 

add chain=forward src-address=192.168.20.0/24

а что, получается, packet sniffer отключает файрвол?

vlad_t
() автор топика
Ответ на: комментарий от anc

то что он переводит я в курсе, но какого только так работает )

anton_jugatsu ★★★★
()
Ответ на: комментарий от anton_jugatsu

так вот я тоже так думал! в общем дело в том что для UDP по которым ходит IPSEC это правило не работает, он без состояния. при этом внутри-то протокол TCP запакован, он-то с состоянием. НО! я где-то натыкался на упоминание, что RELATED,ESTABLISHED для IPSEC не работает, перед тем эту тему поднять тут просто я был уверен что пускаю в обе стороны трафик в файрволе, а оказалось нет, пролюбил это правило. 

[admin@MikroTik] /ip firewall filter> print chain=forward
Flags: X - disabled, I - invalid, D - dynamic 
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward 

 1    chain=forward action=accept src-address=192.168.1.0/24 log=no log-prefix="" 

 2    chain=forward action=accept src-address=192.168.20.0/24 log=no log-prefix="" 

 3    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix="" 

 4    ;;; defconf: accept established,related
      chain=forward action=accept connection-state=established,related log=no log-prefix="" 

 5    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

 6    ;;; defconf:  drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether1 log=no log-prefix=""

vlad_t
() автор топика
Ответ на: комментарий от anton_jugatsu

в том-то и дело что у меня правило related, established тоже было как тут редактировать свои сообщения я не нашел, так что добавляю

попробую поискать, где я это упоминание находил про related established, но точно помню что натыкался где-то

vlad_t
() автор топика
Ответ на: комментарий от vlad_t

По-прежнему не работает.

[ak@r18] > ip firewall filter print chain=forward 
Flags: X - disabled, I - invalid, D - dynamic 
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward 

 1    ;;; Default configuration.
      chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix="" 

 2    chain=forward action=accept src-address=192.168.18.0/25 log=no log-prefix="" 

 3    chain=forward action=accept src-address=192.168.0.0/24 log=no log-prefix="" 

 4    chain=forward action=accept src-address=192.168.1.0/24 log=no log-prefix="" 

 5    ;;; Accept ESTABLISHED and RELATED states.
      chain=forward action=accept connection-state=established,related log=no log-prefix="" 

 6    chain=forward action=drop protocol=tcp src-address=!1.1.1.1 dst-address=192.168.18.80 in-interface=eth6-wan1 out-interface=br0 dst-port=6000 log=no log-prefix="" 

 7    ;;; default configuration
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

 8    ;;; default configuration
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=eth1 log=no log-prefix="" 

 9    chain=forward action=reject reject-with=icmp-network-unreachable src-address=192.168.18.128/28 dst-address=192.168.18.0/25 in-interface=br1 log=no log-prefix=""
anton_jugatsu ★★★★
()
Ответ на: комментарий от vlad_t 
chain=forward action=accept connection-state=established,related src-address=192.168.18.0/25 log=no log-prefix="" 

 2    chain=forward action=accept connection-state=established,related src-address=192.168.0.0/24 log=no log-prefix="" 

 3    chain=forward action=accept connection-state=established,related src-address=192.168.1.0/24 log=no log-prefix=""

Вообщем это должно быть до 

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

о чём и написано по ссылке http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#NAT_and_Fasttrack_Bypass

Доку надо внимательнее читать ))

anton_jugatsu ★★★★
()
Ответ на: комментарий от vlad_t

.... при этом внутри-то протокол TCP запакован, он-то с состоянием. НО! я где-то натыкался на упоминание, что RELATED,ESTABLISHED для IPSEC не работает

Не знаю как это реализовано в микротике, но если в терминах linux то ipsec реализован на уровне ядра, т.е. у вас нет конкретного интерфейса тунеля как например в случае с openvpn, трафик будет отправляться в соответствии с таблицей роутинга. Для рулением трафика ipsec у iptables есть модуль policy в котором так же не забываем указывать направление.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin