Добрые люди подсказали правильную команду. Проблема решилась ручным указанием 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.
