Почему OSPF Hello не проходят через GRE/IPSec VPN туннель в одну сторону?
Добрые люди подсказали правильную команду. Проблема решилась ручным указанием ttl для туннеля:ip link set dev vpntap1 type gretap ttl 30
Или можно указать при создании туннеляauto vpntap1
iface vpntap1 inet manual
        pre-up ip link add $IFACE type gretap local A.B.C.D  remote X.Y.Z.F  key 111.111.111.101 ttl 30
        post-up ip link set $IFACE mtu 1400 || true
        post-down ip link delete $IFACE
Суть проблемы в ttl. GRE пакеты наследуют ttl инкапсулированного пакета, даже если это gretap туннель, т.е. L2 и инкапсулируются Ethernet фреймы, а не IP пакеты как в случае с обычным GRE. Далее ttl наследуется зашифрованными IPSec ESP пакетами. В результате в интернет уходит ESP пакет с ttl=1 и естественно он пропадает. На старом ядре 2.6.32-30-pve для gretap такого наследования ttl очевидно нет, поэтому все работало "из коробки".
Я изначально пробовал сменить ttl у туннелья с помощью ip tunnel change vpntap3 ttl 10 но для gretap эта команда не работает, ошибка:get tunnel "vpntap3" failed: Operation not supported
Встроенная в ip справка мне не очень помогла ip link help - нет ни слова про ttl, но оказывается если уточнить рамки помощи вот таким образомip link help gretap, можно получить ценную информацию:# ip link help gretap
Usage: ip link { add | set | change | replace | del } NAME
          type { gre | gretap } [ remote ADDR ] [ local ADDR ]
          [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ]
          [ ttl TTL ] [ tos TOS ] [ [no]pmtudisc ] [ dev PHYS_DEV ]
          [ noencap ] [ encap { fou | gue | none } ]
          [ encap-sport PORT ] [ encap-dport PORT ]
          [ [no]encap-csum ] [ [no]encap-csum6 ] [ [no]encap-remcsum ]

Where: NAME := STRING
       ADDR := { IP_ADDRESS | any }
       TOS  := { NUMBER | inherit }
       TTL  := { 1..255 | inherit }
       KEY  := { DOTTED_QUAD | NUMBER }
В Debian 7 кстати последний вариант не работает, выводит ровно то же что просто ip link help.
Респект за подробно описанную ситуацию :-) Всё ниасилил, но имею предложить следующее :-) У некоторых провайдеров (замечены Ростелеком, Онлайм) некорректно отрабатывает то ли cgnat, то ли какой-то ALG по дороге. Что приводит к блокированию НЕКОТОРЫХ типов пакетов в туннелях, либо при согласовании туннелей. У меня по этой схеме не устанавливаются L2TP сессии -- просто блочится определённый пакет в ответе клиента серверу, и всё.
Так я это всё к чему. Попробуйте поменять тип туннеля с проблемным IP. Либо попробуйте включить шифрование в этом туннеле, чтобы скрыть трафик. Возможно, тогда всё заработает.