Почитал заграничных гуру, появилось два правила:

$IPT -A FORWARD -m policy --dir in --pol ipsec --mode tunnel --tunnel-dst ${WAN_IP} --tunnel-src 0.0.0.0/0 -i $WAN -s 192.168.0.0/24 -o $LAN1 -d ${LAN1_IP_RANGE} -j ACCEPT
$IPT -A FORWARD -m policy --dir out --pol ipsec --mode tunnel --tunnel-dst 0.0.0.0/0 --tunnel-src ${WAN_IP} -i $LAN1 -s ${LAN1_IP_RANGE} -o $WAN -d 192.168.0.0/24 -j ACCEPT

Теперь из Сети А полностью видна Сеть В, а вот в обратку совсем засада :(

читаю дальше

В обратку надо d-link смотреть, скорее всего он что-то не пускает.

все заработало!!!

со стороны CentOS iptables выглядит так:

$IPT -A FORWARD -m policy --dir in --pol ipsec --mode tunnel -j ACCEPT
$IPT -A FORWARD -m policy --dir out --pol ipsec --mode tunnel -j ACCEPT

$IPT -t nat -A POSTROUTING -o $WAN -s $LAN_местная ! -d $LAN_удаленная -j MASQUERADE

Доброго времени суток, коллеги!

Может быть, кто-то сможет подсказать куда покопать.

Пытаемся настроить ipsec-соединение между двумя удалёнными офисами/локальными сетями.

Ситуация вполне классическая:

• с обеих сторон шлюзы CentOS 7.2.15.11
• на каждом шлюзе 2 интерфейса: первый наружу - оба белые статические IP, второй - в локалку 192.168.5.0/24 и 192.168.8.0/24 соответственно
• в качестве реализации пока пробуем использовать ipsec-tools(racoon+setkey)

Удалось пробиться через iptables, создать нужные правила (топикстартеру спасибо, помог), туннель устанавливается, но проблема в том, что устанавливается очень нестабильно. Пока конкретно перечислить последовательность действий, при которых он точно поднимается  не могу, будем ещё тестировать. Пока можно сказать следующее:

• если туннель уже поднят, то перезагрузка сервисов network, iptables, racoon на любом из шлюзов туннель не рушит, точнее - после рестарта сервиса туннель поднимается сам
• проблемы начинаются, если перезагрузить один из шлюзов, после этого  подниматься не хочет ни в какую, в отличие от того же IPIP-туннеля, который мы также в своей практике используем на других машинах.

Сразу скажу, что используются дефолтный, конфиг racoon.conf, файл $remote_wan_ip.conf создаётся, как  и должен, автоматически и прописывается в racoon.conf, ключ из keys-ipsec прописывается в psk.txt.

На мой взгляд проблема кроется в создаваемых racoon'ом при успешном обмене ключами записях SAD (setkey -D). На перезагружаемом шлюзе они стираются и после запуска системы база данных пустая. На втором шлюзе все записи остаются, в результате соединение не устанавливается. Чтобы заново поднять туннель нужно, чтобы на обоих шлюзах база данных SAD была пустой, чистить записи можно или руками (setkey flush или racoonctl flush-sa esp/ah) или перезапуском сервиса racoon. Правда после таких чисток туннель опять же поднимается нестабильно (пока точно не пойму закономерность, если дойду - отпишу), зависит от того, какой из шлюзов инициирует соединение. Сразу оговорюсь, что процессе наших танцев установку соединения проверяем пингом машин по "внутренним/локальным" адресам. Так вот иногда после очистки SAD туннель поднимается сразу (то есть ответ на пинг приходит), а иногда нужно вообще проделать странную последовательность:

• запустить пинг с одной стороны. Соединения и ответа при этом нет.
• одновременно запустить пинг с другой стороны. Сразу же (ping $remote_lan_ip, Enter) хосты успешно обмениваются ключами, соединение устанавливается, ответы на пинг начинают идти на обоих шлюзах.

Простите за многобукоф, хотелось донести, что удалось нарыть. Пока никакие логи не прикреплял, чтобы ещё больше не увеличивать коммент. В итоге на данный момент мой вопрос таков - как заставить racoon убивать записи SAD при невозможности установить соединение? В манах нашёл по этому вопросу только параметр

initial_contact (on | off);
Enable this to send an INITIAL-CONTACT message. The default value is on. This message is useful
only when the responder implementation chooses an old SA when there are multiple SAs with different
established time and the initiator reboots. If racoon did not send the message, the responder would
use an old SA even when a new SA was established. For systems that use a KAME derived IPSEC stack,
the sysctl(8) variable net.key.preferred_oldsa can be used to control this preference. When the
value is zero, the stack always uses a new SA.

То есть к примеру на BSD был параметр для sysctl.conf - net.key.preferred_oldsa=0, который заставлял racoon всегда использовать новые SA. С RHEL пока неясно. Может, это вообще работает как-то не так?

Я никогда не настраивал подобную связку. Но мне просто интересно, а почему не использовать openvpn, если надо соединить 2 шлюза между собой? С помощью openvpn это делается буквально за 10 минут без плясок с бубном. В чем в данном случае преимущество ipsec?