URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID6
Нить номер: 219
[ Назад ]
Исходное сообщение
"Не поднимается GRE после падения канала."
Отправлено foxdenis , 19-Окт-12 10:21 
Реализовал резервирование VPN туннелей средствами EIGRP и GRE.
Т.е. есть 2 ASA, между ними поднято 2 туннеля IPSEC, в туннели с каждой стороны уходят 2 подсети. За ASA с каждой стороны стоят роутеры (2911, 2921). На каждом роутере подняты GRE туннели до другого роутера. И включен EIGRP. Первое время после настройки все ОК, оба туннеля работают, делят трафик. Но стоит одному упасть, он больше не поднимается. Помогает только пересоздание интерфейсов tunnel да и то не всегда.
При этом с обоих роутеров destination пингуется.
Tunnel1 is up, line protocol is up
Но при этом вторая сторона туннеля не пингуется.
Иногда пингуется, если в качестве source указать какой-нибудь иной интерфейс, иногда нет.
Конечными точками туннелей являются vlan порты роутеров, смотрящие в сторону ASA.

Сначала подумал, что дело может быть в NAT, но убрав его, дело не исправилось.
Уже 2 дня ломаю голову, единственное что на ум приходит, глюк прошивки. Может кто сталкивался?


Туннели с одной стороны:

interface Tunnel0
ip address 192.168.11.1 255.255.255.252
ip nat inside
tunnel source 192.168.4.2
tunnel destination 192.168.6.1
!
interface Tunnel1
ip address 192.168.10.1 255.255.255.252
ip nat inside
tunnel source 192.168.3.2
tunnel destination 192.168.6.5
!
Туннели с другой стороны:

interface Tunnel0
ip address 192.168.11.2 255.255.255.252
tunnel source 192.168.6.1
tunnel destination 192.168.4.2
!
interface Tunnel1
ip address 192.168.10.2 255.255.255.252
tunnel source 192.168.6.5
tunnel destination 192.168.3.2

NAT:
access-list 8 permit 10.192.2.0 0.0.1.255
access-list 8 permit 10.192.4.0 0.0.0.255
access-list 8 permit 10.192.6.0 0.0.0.255
ip nat pool regions 10.36.212.1 10.36.212.254 netmask 255.255.255.0
ip nat inside source list 8 pool regions

Содержание
Сообщения в этом обсуждении
"Не поднимается GRE после падения канала."
Отправлено fantom , 19-Окт-12 11:28 
>[оверквотинг удален]
> interface Tunnel1
> ip address 192.168.10.2 255.255.255.252
> tunnel source 192.168.6.5
> tunnel destination 192.168.3.2
> NAT:
> access-list 8 permit 10.192.2.0 0.0.1.255
> access-list 8 permit 10.192.4.0 0.0.0.255
> access-list 8 permit 10.192.6.0 0.0.0.255
> ip nat pool regions 10.36.212.1 10.36.212.254 netmask 255.255.255.0
> ip nat inside source list 8 pool regions

keepalive на тунелях добавте.

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 19-Окт-12 11:43 
>[оверквотинг удален]
>> ip address 192.168.10.2 255.255.255.252
>> tunnel source 192.168.6.5
>> tunnel destination 192.168.3.2
>> NAT:
>> access-list 8 permit 10.192.2.0 0.0.1.255
>> access-list 8 permit 10.192.4.0 0.0.0.255
>> access-list 8 permit 10.192.6.0 0.0.0.255
>> ip nat pool regions 10.36.212.1 10.36.212.254 netmask 255.255.255.0
>> ip nat inside source list 8 pool regions
> keepalive на тунелях добавте.

Добавлял, ничего не меняется. При этом странная штука, если ронять каналы, то поднимается всегда один и тот же туннель, второй остается лежать. Если пересоздать лежащий туннель с двух сторон, то он опять работает.

PS Если keepalive оставить, то интерфейс, после поднятия канала в состоянии: Tunnel1 is up, line protocol is down

"Не поднимается GRE после падения канала."
Отправлено fantom , 19-Окт-12 12:55 
>[оверквотинг удален]
>>> access-list 8 permit 10.192.4.0 0.0.0.255
>>> access-list 8 permit 10.192.6.0 0.0.0.255
>>> ip nat pool regions 10.36.212.1 10.36.212.254 netmask 255.255.255.0
>>> ip nat inside source list 8 pool regions
>> keepalive на тунелях добавте.
> Добавлял, ничего не меняется. При этом странная штука, если ронять каналы, то
> поднимается всегда один и тот же туннель, второй остается лежать. Если
> пересоздать лежащий туннель с двух сторон, то он опять работает.
> PS Если keepalive оставить, то интерфейс, после поднятия канала в состоянии: Tunnel1
> is up, line protocol is down

И это правильно, говорит о том, что реально интерфейс "не фурычит"

sh ip ro 192.168.6.0
sh ip ro 192.168.6.4
sh ip ro 192.168.4.0
sh ip ro 192.168.4.4

c обоих роутеров когда работает только 1 тунель.

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 19-Окт-12 14:28 
>[оверквотинг удален]
>> поднимается всегда один и тот же туннель, второй остается лежать. Если
>> пересоздать лежащий туннель с двух сторон, то он опять работает.
>> PS Если keepalive оставить, то интерфейс, после поднятия канала в состоянии: Tunnel1
>> is up, line protocol is down
> И это правильно, говорит о том, что реально интерфейс "не фурычит"
> sh ip ro 192.168.6.0
> sh ip ro 192.168.6.4
> sh ip ro 192.168.4.0
> sh ip ro 192.168.4.4
> c обоих роутеров когда работает только 1 тунель.

После тщетных попыток немного поменялась адресация, сейчас выглядит все следующим образом:

Роутер1:

interface Tunnel0
ip address 192.168.11.1 255.255.255.252
tunnel source 192.168.4.2
tunnel destination 192.168.6.1
!
interface Tunnel1
ip address 192.168.21.1 255.255.255.252
tunnel source 192.168.3.2
tunnel destination 192.168.7.1

1#sh ip ro 192.168.6.0
Routing entry for 192.168.6.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.4.1
      Route metric is 0, traffic share count is 1

1#sh ip ro 192.168.7.0
Routing entry for 192.168.7.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.3.1
      Route metric is 0, traffic share count is 1

1#sh ip ro 192.168.4.0
Routing entry for 192.168.4.0/24, 2 known subnets
  Attached (2 connections)
  Variably subnetted with 2 masks
C        192.168.4.0/24 is directly connected, GigabitEthernet0/1.55
L        192.168.4.2/32 is directly connected, GigabitEthernet0/1.55

1#sh ip ro 192.168.3.0
Routing entry for 192.168.3.0/24, 2 known subnets
  Attached (2 connections)
  Variably subnetted with 2 masks
C        192.168.3.0/24 is directly connected, GigabitEthernet0/1.56
L        192.168.3.2/32 is directly connected, GigabitEthernet0/1.56

Роутер2:

interface Tunnel0
ip address 192.168.11.2 255.255.255.252
tunnel source 192.168.6.1
tunnel destination 192.168.4.2
!
interface Tunnel1
ip address 192.168.21.2 255.255.255.252
tunnel source 192.168.7.1
tunnel destination 192.168.3.2

2#sh ip ro 192.168.3.0
Routing entry for 192.168.3.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.7.2
      Route metric is 0, traffic share count is 1
2#sh ip ro 192.168.4.0
Routing entry for 192.168.4.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.6.2
      Route metric is 0, traffic share count is 1
2#sh ip ro 192.168.6.0
Routing entry for 192.168.6.0/24, 2 known subnets
  Attached (2 connections)
  Variably subnetted with 2 masks
C        192.168.6.0/24 is directly connected, GigabitEthernet0/1.101
L        192.168.6.1/32 is directly connected, GigabitEthernet0/1.101
2#sh ip ro 192.168.7.0
Routing entry for 192.168.7.0/24, 2 known subnets
  Attached (2 connections)
  Variably subnetted with 2 masks
C        192.168.7.0/24 is directly connected, GigabitEthernet0/1.102
L        192.168.7.1/32 is directly connected, GigabitEthernet0/1.102

"Не поднимается GRE после падения канала."
Отправлено fantom , 19-Окт-12 14:59 
>[оверквотинг удален]
> L        192.168.6.1/32 is directly connected,
> GigabitEthernet0/1.101
> 2#sh ip ro 192.168.7.0
> Routing entry for 192.168.7.0/24, 2 known subnets
>   Attached (2 connections)
>   Variably subnetted with 2 masks
> C        192.168.7.0/24 is directly connected,
> GigabitEthernet0/1.102
> L        192.168.7.1/32 is directly connected,
> GigabitEthernet0/1.102

все-таки поставьте keepalive с обоих сторон на каждом тунеле, потом debug tunnel keepalive - и смотрите какие куда улетели/прилетели.

Если с одного рутера все уходит, а на второй не приходит, то 2 варианта:
1. грабли с маршрутизацией
2. что-то где-то фильтрует gre трафик....

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 19-Окт-12 15:23 
>[оверквотинг удален]
>> C        192.168.7.0/24 is directly connected,
>> GigabitEthernet0/1.102
>> L        192.168.7.1/32 is directly connected,
>> GigabitEthernet0/1.102
> все-таки поставьте keepalive с обоих сторон на каждом тунеле, потом debug tunnel
> keepalive - и смотрите какие куда улетели/прилетели.
> Если с одного рутера все уходит, а на второй не приходит, то
> 2 варианта:
> 1. грабли с маршрутизацией
> 2. что-то где-то фильтрует gre трафик....

Это логично, но тогда бы туннель вообще бы не поднимался бы никогда. А тут он поднимается и прекрасно работает, но после обрыва канала, больше не поднимается.
Еще одна странная вещь: другая сторона пингуется с роутера 2 в следующем варианте:

2#ping 192.168.21.1 source 10.192.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.21.1, timeout is 2 seconds:
Packet sent with a source address of 10.192.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

А если просто написать без source:

2#ping 192.168.21.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.21.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Т.е. туннель живой, но почему то не пускает через себя часть пакетов, в том числе keepalive.

"Не поднимается GRE после падения канала."
Отправлено fantom , 19-Окт-12 15:58 
>[оверквотинг удален]
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
> А если просто написать без source:
> 2#ping 192.168.21.1
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 192.168.21.1, timeout is 2 seconds:
> .....
> Success rate is 0 percent (0/5)
> Т.е. туннель живой, но почему то не пускает через себя часть пакетов,
> в том числе keepalive.

неа, не живой, он получается может быть живой ТОЛЬКО В ОДНОМ НАПРАВЛЕНИИ, т.к. R1 ответ на 10.192.3.3 отправляет не в тунель, вернее не в этот тунель :)

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 19-Окт-12 16:07 
>[оверквотинг удален]
>> 2#ping 192.168.21.1
>> Type escape sequence to abort.
>> Sending 5, 100-byte ICMP Echos to 192.168.21.1, timeout is 2 seconds:
>> .....
>> Success rate is 0 percent (0/5)
>> Т.е. туннель живой, но почему то не пускает через себя часть пакетов,
>> в том числе keepalive.
> неа, не живой, он получается может быть живой ТОЛЬКО В ОДНОМ НАПРАВЛЕНИИ,
> т.к. R1 ответ на 10.192.3.3 отправляет не в тунель, вернее не
> в этот тунель :)

Router 1
1#
Oct 19 16:05:20.021 MSK: Tunnel0: sending keepalive, 192.168.6.1->192.168.4.2 (len=24 ttl=255), counter=1
Oct 19 16:05:20.021 MSK: Tunnel1: sending keepalive, 192.168.7.1->192.168.3.2 (len=24 ttl=255), counter=18
Oct 19 16:05:20.029 MSK: Tunnel0: keepalive received, 192.168.6.1->192.168.4.2 (len=24 ttl=253), resetting counter
1#
Oct 19 16:05:30.021 MSK: Tunnel0: sending keepalive, 192.168.6.1->192.168.4.2 (len=24 ttl=255), counter=1
Oct 19 16:05:30.021 MSK: Tunnel1: sending keepalive, 192.168.7.1->192.168.3.2 (len=24 ttl=255), counter=19
Oct 19 16:05:30.033 MSK: Tunnel0: keepalive received, 192.168.6.1->192.168.4.2 (len=24 ttl=253), resetting counter
1#
Oct 19 16:05:40.021 MSK: Tunnel0: sending keepalive, 192.168.6.1->192.168.4.2 (len=24 ttl=255), counter=1
Oct 19 16:05:40.021 MSK: Tunnel1: sending keepalive, 192.168.7.1->192.168.3.2 (len=24 ttl=255), counter=20
Oct 19 16:05:40.029 MSK: Tunnel0: keepalive received, 192.168.6.1->192.168.4.2 (len=24 ttl=253), resetting counter
1#
Oct 19 16:05:50.021 MSK: Tunnel0: sending keepalive, 192.168.6.1->192.168.4.2 (len=24 ttl=255), counter=1
Oct 19 16:05:50.021 MSK: Tunnel1: sending keepalive, 192.168.7.1->192.168.3.2 (len=24 ttl=255), counter=21
Oct 19 16:05:50.029 MSK: Tunnel0: keepalive received, 192.168.6.1->192.168.4.2 (len=24 ttl=253), resetting counter
1#
Oct 19 16:06:00.069 MSK: Tunnel0: sending keepalive, 192.168.6.1->192.168.4.2 (len=24 ttl=255), counter=1
Oct 19 16:06:00.069 MSK: Tunnel1: sending keepalive, 192.168.7.1->192.168.3.2 (len=24 ttl=255), counter=22
Oct 19 16:06:00.081 MSK: Tunnel0: keepalive received, 192.168.6.1->192.168.4.2 (len=24 ttl=253), resetting counter
1#
Oct 19 16:06:10.069 MSK: Tunnel0: sending keepalive, 192.168.6.1->192.168.4.2 (len=24 ttl=255), counter=1
Oct 19 16:06:10.069 MSK: Tunnel1: sending keepalive, 192.168.7.1->192.168.3.2 (len=24 ttl=255), counter=23
Oct 19 16:06:10.077 MSK: Tunnel0: keepalive received, 192.168.6.1->192.168.4.2 (len=24 ttl=253), resetting counter

Router 2:
Oct 19 12:03:47.733: Tunnel0: keepalive received, 192.168.4.2->192.168.6.1 (len=24 ttl=253), resetting counter
Oct 19 12:03:57.725: Tunnel0: sending keepalive, 192.168.4.2->192.168.6.1 (len=24 ttl=255), counter=1
Oct 19 12:03:57.725: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255), counter=28
Oct 19 12:03:57.737: Tunnel0: keepalive received, 192.168.4.2->192.168.6.1 (len=24 ttl=253), resetting counter
Oct 19 12:04:07.765: Tunnel0: sending keepalive, 192.168.4.2->192.168.6.1 (len=24 ttl=255), counter=1
Oct 19 12:04:07.765: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255), counter=29
Oct 19 12:04:07.777: Tunnel0: keepalive received, 192.168.4.2->192.168.6.1 (len=24 ttl=253), resetting counter
Oct 19 12:04:17.765: Tunnel0: sending keepalive, 192.168.4.2->192.168.6.1 (len=24 ttl=255), counter=1
Oct 19 12:04:17.765: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255), counter=30
Oct 19 12:04:17.773: Tunnel0: keepalive received, 192.168.4.2->192.168.6.1 (len=24 ttl=253), resetting counter
Oct 19 12:04:27.765: Tunnel0: sending keepalive, 192.168.4.2->192.168.6.1 (len=24 ttl=255), counter=1
Oct 19 12:04:27.765: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255), counter=31
Oct 19 12:04:27.773: Tunnel0: keepalive received, 192.168.4.2->192.168.6.1 (len=24 ttl=253), resetting counter
Oct 19 12:04:37.765: Tunnel0: sending keepalive, 192.168.4.2->192.168.6.1 (len=24 ttl=255), counter=1
Oct 19 12:04:37.765: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255), counter=32
Oct 19 12:04:37.777: Tunnel0: keepalive received, 192.168.4.2->192.168.6.1 (len=24 ttl=253), resetting counter
Oct 19 12:04:47.765: Tunnel0: sending keepalive, 192.168.4.2->192.168.6.1 (len=24 ttl=255), counter=1
Oct 19 12:04:47.765: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255), counter=33

По фильтрации Gre везде все открыл, даже больше чем нужно.
Получается что ни в ту сторону не доходит ни в другую.

"Не поднимается GRE после падения канала."
Отправлено fantom , 19-Окт-12 16:33 
>[оверквотинг удален]
> Oct 19 12:04:37.765: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255),
> counter=32
> Oct 19 12:04:37.777: Tunnel0: keepalive received, 192.168.4.2->192.168.6.1 (len=24 ttl=253),
> resetting counter
> Oct 19 12:04:47.765: Tunnel0: sending keepalive, 192.168.4.2->192.168.6.1 (len=24 ttl=255),
> counter=1
> Oct 19 12:04:47.765: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255),
> counter=33
> По фильтрации Gre везде все открыл, даже больше чем нужно.
> Получается что ни в ту сторону не доходит ни в другую.

Как канал построен между 29-ми кошками? там явно есть L3 железо - на нем что фильтруется?

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 19-Окт-12 16:42 
>[оверквотинг удален]
>> Oct 19 12:04:37.777: Tunnel0: keepalive received, 192.168.4.2->192.168.6.1 (len=24 ttl=253),
>> resetting counter
>> Oct 19 12:04:47.765: Tunnel0: sending keepalive, 192.168.4.2->192.168.6.1 (len=24 ttl=255),
>> counter=1
>> Oct 19 12:04:47.765: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255),
>> counter=33
>> По фильтрации Gre везде все открыл, даже больше чем нужно.
>> Получается что ни в ту сторону не доходит ни в другую.
> Как канал построен между 29-ми кошками? там явно есть L3 железо -
> на нем что фильтруется?

Между роутерами стоят 2 ASA, на которых как раз построены VPN IPSec туннели. Там и в аксес-листы VPN включен протокол GRE и на всех портах я специально открыл доступ GRE any any. Могу выложить конфиг, вдруг я где то лохонулся.

"Не поднимается GRE после падения канала."
Отправлено fantom , 19-Окт-12 16:48 
>[оверквотинг удален]
>>> Oct 19 12:04:47.765: Tunnel1: sending keepalive, 192.168.3.2->192.168.7.1 (len=24 ttl=255),
>>> counter=33
>>> По фильтрации Gre везде все открыл, даже больше чем нужно.
>>> Получается что ни в ту сторону не доходит ни в другую.
>> Как канал построен между 29-ми кошками? там явно есть L3 железо -
>> на нем что фильтруется?
> Между роутерами стоят 2 ASA, на которых как раз построены VPN IPSec
> туннели. Там и в аксес-листы VPN включен протокол GRE и на
> всех портах я специально открыл доступ GRE any any. Могу выложить
> конфиг, вдруг я где то лохонулся.

В ASA-ах я ничо не понимаю :)
явно лочится тунельный траф, как там что открывается/закрывается - незнаю....

Можно еще попробовать явно на тунелях gre указать

tunnel mode gre

ну или попробовать с другой инкарсуляцией поиграться, например ipip...

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 19-Окт-12 17:00 
>[оверквотинг удален]
>>> на нем что фильтруется?
>> Между роутерами стоят 2 ASA, на которых как раз построены VPN IPSec
>> туннели. Там и в аксес-листы VPN включен протокол GRE и на
>> всех портах я специально открыл доступ GRE any any. Могу выложить
>> конфиг, вдруг я где то лохонулся.
> В ASA-ах я ничо не понимаю :)
> явно лочится тунельный траф, как там что открывается/закрывается - незнаю....
> Можно еще попробовать явно на тунелях gre указать
> tunnel mode gre
> ну или попробовать с другой инкарсуляцией поиграться, например ipip...

На туннелях GRE указан явно. Инкапсуляцию поменял на ipip, туннель поднялся. Но после того как уронил канал интернет, туннель опять не поднялся.

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 19-Окт-12 17:15 
>[оверквотинг удален]
>>> туннели. Там и в аксес-листы VPN включен протокол GRE и на
>>> всех портах я специально открыл доступ GRE any any. Могу выложить
>>> конфиг, вдруг я где то лохонулся.
>> В ASA-ах я ничо не понимаю :)
>> явно лочится тунельный траф, как там что открывается/закрывается - незнаю....
>> Можно еще попробовать явно на тунелях gre указать
>> tunnel mode gre
>> ну или попробовать с другой инкарсуляцией поиграться, например ipip...
> На туннелях GRE указан явно. Инкапсуляцию поменял на ipip, туннель поднялся. Но
> после того как уронил канал интернет, туннель опять не поднялся.

Конфиг первой ASA:
interface GigabitEthernet0/3.55
vlan 55
nameif test_vlan
security-level 100
ip address 192.168.4.1 255.255.255.0
!
interface GigabitEthernet0/3.56
vlan 56
nameif vlan_test_2
security-level 100
ip address 192.168.3.1 255.255.255.0
!
interface GigabitEthernet0/3.130
vlan 130
nameif local
security-level 100
ip address 10.36.210.38 255.255.255.252


interface GigabitEthernet0/0
description **LINK-to-ISP**
nameif OUTSIDE
security-level 0
ip address x.x.x.x 255.255.255.248
!
interface GigabitEthernet0/1
description outside2
nameif outside2
security-level 0
ip address y.y.y.y 255.255.255.252


object-group protocol DM_INLINE_PROTOCOL_1
protocol-object ip
protocol-object icmp
object-group protocol DM_INLINE_PROTOCOL_2
protocol-object icmp
protocol-object gre
object-group service tfp_ports
service-object icmp
service-object tcp eq ftp
service-object tcp eq ftp-data
object-group network all_10
description all_10
network-object ALL 255.0.0.0
object-group service DM_INLINE_SERVICE_1
service-object icmp
group-object tfp_ports
object-group protocol DM_INLINE_PROTOCOL_3
protocol-object icmp
protocol-object gre
object-group protocol DM_INLINE_PROTOCOL_4
protocol-object ip
protocol-object icmp
protocol-object gre
object-group protocol DM_INLINE_PROTOCOL_5
protocol-object ip
protocol-object icmp
protocol-object gre
object-group protocol DM_INLINE_PROTOCOL_6
protocol-object ip
protocol-object icmp
protocol-object gre
object-group protocol DM_INLINE_PROTOCOL_7
protocol-object ip
protocol-object gre
object-group protocol DM_INLINE_PROTOCOL_8
protocol-object ip


access-list OUTSIDE_cryptomap extended permit object-group DM_INLINE_PROTOCOL_8 object-group all_10 10.192.4.0 255.255.255.0
access-list OUTSIDE_cryptomap_1 extended permit ip object-group all_10 10.192.6.0 255.255.255.0
access-list OUTSIDE_cryptomap_2 extended permit ip 192.168.4.0 255.255.255.0 192.168.6.0 255.255.255.0
access-list INSIDE_nat0_outbound extended permit ip ALL 255.0.0.0 ALL 255.0.0.0
access-list INSIDE_nat0_outbound extended permit ip 192.168.0.0 255.255.0.0 192.168.0.0 255.255.0.0
access-list OUTSIDE_access_in extended permit object-group DM_INLINE_PROTOCOL_2 any any
access-list OUTSIDE_access_in extended permit object-group DM_INLINE_SERVICE_1 any host 195.239.243.18
access-list OUTSIDE_access_in extended permit ip 192.168.0.0 255.255.0.0 any
access-list mobis standard permit ALL 255.0.0.0
access-list OUTSIDE_access_out extended permit ip any any
access-list DMZ_nat0_outbound extended permit ip 10.36.210.16 255.255.255.252 object-group all_10
access-list outside2_access_in extended permit object-group DM_INLINE_PROTOCOL_3 any any
access-list outside2_access_in extended permit ip 192.168.0.0 255.255.0.0 any
access-list outside2_cryptomap extended permit object-group DM_INLINE_PROTOCOL_7 192.168.3.0 255.255.255.0 192.168.7.0 255.255.255.0
access-list outside2_access_out extended permit object-group DM_INLINE_PROTOCOL_4 any any
access-list vlan_test_2_access_in extended permit object-group DM_INLINE_PROTOCOL_5 any any
access-list test_vlan_access_in extended permit object-group DM_INLINE_PROTOCOL_6 any any


global (OUTSIDE) 1 interface
global (outside2) 1 interface
nat (local) 0 access-list INSIDE_nat0_outbound
nat (local) 1 0.0.0.0 0.0.0.0


access-group OUTSIDE_access_in in interface OUTSIDE
access-group OUTSIDE_access_out out interface OUTSIDE
access-group test_vlan_access_in in interface test_vlan
access-group vlan_test_2_access_in in interface vlan_test_2
access-group outside2_access_in in interface outside2
access-group outside2_access_out out interface outside2


route OUTSIDE 0.0.0.0 0.0.0.0 "DG1" 1
route outside2 0.0.0.0 0.0.0.0 "DG2" 15
route local 10.0.0.0 255.0.0.0 10.36.210.37 1
route outside2 v.v.v.v 62.231.28.201 1
route OUTSIDE 192.168.6.0 255.255.255.0 "DG1" 1
route outside2 192.168.7.0 255.255.255.0 "DG2" 1


crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac


crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set transform-set ESP-DES-SHA ESP-DES-MD5
crypto map OUTSIDE_map 1 match address OUTSIDE_cryptomap_2
crypto map OUTSIDE_map 1 set peer z.z.z.z
crypto map OUTSIDE_map 1 set transform-set ESP-DES-SHA ESP-DES-MD5
crypto map OUTSIDE_map interface OUTSIDE
crypto map outside2_map0 1 match address outside2_cryptomap
crypto map outside2_map0 1 set peer v.v.v.v
crypto map outside2_map0 1 set transform-set ESP-DES-SHA ESP-DES-MD5
crypto map outside2_map0 interface outside2


tunnel-group v.v.v.v type ipsec-l2l
tunnel-group v.v.v.v general-attributes
default-group-policy GroupPolicy4
tunnel-group v.v.v.v ipsec-attributes
pre-shared-key *****
tunnel-group z.z.z.z type ipsec-l2l
tunnel-group z.z.z.z general-attributes
default-group-policy GroupPolicy3
tunnel-group z.z.z.z ipsec-attributes
pre-shared-key *****

Конфиг второй ASA:

interface GigabitEthernet0/0
nameif INTERNET
security-level 0
ip address v.v.v.v 255.255.255.252
!
interface GigabitEthernet0/1
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/1.100
vlan 100
nameif local
security-level 100
ip address 192.168.5.2 255.255.255.252
!
interface GigabitEthernet0/1.101
vlan 101
nameif vlan101
security-level 100
ip address 192.168.6.2 255.255.255.0
!
interface GigabitEthernet0/1.102
vlan 102
nameif vlan102
security-level 100
ip address 192.168.7.2 255.255.255.0
!
interface GigabitEthernet0/2
nameif -=ISP2=-
security-level 0
ip address Z.Z.Z.Z 255.255.255.0


object-group protocol DM_INLINE_PROTOCOL_1
protocol-object ip
protocol-object icmp
object-group protocol DM_INLINE_PROTOCOL_2
protocol-object ip
protocol-object icmp
object-group protocol DM_INLINE_PROTOCOL_3
protocol-object icmp
protocol-object gre
object-group protocol DM_INLINE_PROTOCOL_4
protocol-object ip
protocol-object icmp
object-group protocol DM_INLINE_PROTOCOL_5
protocol-object ip
protocol-object icmp
object-group protocol DM_INLINE_PROTOCOL_6
protocol-object ip
protocol-object icmp
object-group protocol DM_INLINE_PROTOCOL_7
protocol-object ip
protocol-object icmp
object-group protocol DM_INLINE_PROTOCOL_8
protocol-object ip
protocol-object icmp
protocol-object gre
object-group service rdp tcp
port-object eq 3389
object-group protocol TCPUDP
protocol-object udp
protocol-object tcp
object-group service ss tcp-udp
port-object eq 5000
object-group protocol DM_INLINE_PROTOCOL_10
protocol-object ip
protocol-object icmp
protocol-object gre
object-group protocol DM_INLINE_PROTOCOL_9
protocol-object ip
protocol-object icmp
protocol-object gre
object-group protocol DM_INLINE_PROTOCOL_11
protocol-object ip
protocol-object gre
object-group protocol DM_INLINE_PROTOCOL_13
protocol-object ip
protocol-object gre


access-list LOCAL_access_in extended permit object-group DM_INLINE_PROTOCOL_6 any any
access-list LOCAL_access_in extended permit ip 10.192.2.0 255.255.254.0 any
access-list LOCAL_access_out extended permit object-group DM_INLINE_PROTOCOL_7 any any
access-list INTERNET_access_in extended permit object-group DM_INLINE_PROTOCOL_3 any any
access-list INTERNET_access_in extended permit ip host 10.10.17.18 any inactive
access-list INTERNET_access_in extended permit ip 10.0.0.0 255.0.0.0 any
access-list INTERNET_access_in extended permit ip 192.168.0.0 255.255.0.0 any
access-list INTERNET_access_out extended permit object-group DM_INLINE_PROTOCOL_8 any any
access-list local_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0
access-list local_nat0_outbound extended permit ip 192.168.0.0 255.255.0.0 192.168.0.0 255.255.0.0
access-list management_nat0_outbound extended permit ip 10.192.2.0 255.255.254.0 10.0.0.0 255.0.0.0
access-list 11 standard permit 10.0.0.0 255.0.0.0
access-list -=ISP2=-_cryptomap extended permit object-group DM_INLINE_PROTOCOL_13 192.168.6.0 255.255.255.0 192.168.4.0 255.255.255.0
access-list INTERNET_cryptomap extended permit object-group DM_INLINE_PROTOCOL_11 192.168.7.0 255.255.255.0 192.168.3.0 255.255.255.0
access-list vlan101_access_in extended permit object-group DM_INLINE_PROTOCOL_9 any any
access-list vlan102_access_in extended permit object-group DM_INLINE_PROTOCOL_10 any any


global (INTERNET) 1 interface
global (-=ISP2=-) 1 interface
nat (local) 0 access-list local_nat0_outbound
nat (local) 1 0.0.0.0 0.0.0.0

access-group INTERNET_access_in in interface INTERNET
access-group INTERNET_access_out out interface INTERNET
access-group INTERNET_access_in in interface -=ISP2=-
access-group INTERNET_access_out out interface -=ISP2=-
access-group vlan101_access_in in interface vlan101
access-group vlan102_access_in in interface vlan102


route -=ISP2=- 0.0.0.0 0.0.0.0 "DG3" 1 track 1
route INTERNET 0.0.0.0 0.0.0.0 "DG4" 200
route local 10.192.2.0 255.255.254.0 192.168.5.1 1
route INTERNET y.y.y.y 62.181.37.157 1
route INTERNET 192.168.3.0 255.255.255.0 "DG4" 1
route -=ISP2=- 192.168.4.0 255.255.255.0 "DG3" 1


crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto map -=ISP2=-_map0 1 match address -=ISP2=-_cryptomap
crypto map -=ISP2=-_map0 1 set peer x.x.x.x.
crypto map -=ISP2=-_map0 1 set transform-set ESP-DES-SHA ESP-DES-MD5
crypto map -=ISP2=-_map0 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map -=ISP2=-_map0 interface -=ISP2=-
crypto map INTERNET_map1 1 match address INTERNET_cryptomap
crypto map INTERNET_map1 1 set peer y.y.y.y
crypto map INTERNET_map1 1 set transform-set ESP-DES-SHA ESP-DES-MD5
crypto map INTERNET_map1 interface INTERNET


crypto isakmp enable INTERNET
crypto isakmp enable -=ISP2=-


tunnel-group y.y.y.y type ipsec-l2l
tunnel-group y.y.y.y general-attributes
default-group-policy GroupPolicy4
tunnel-group y.y.y.y ipsec-attributes
pre-shared-key *

tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x general-attributes
default-group-policy GroupPolicy2
tunnel-group x.x.x.x ipsec-attributes
pre-shared-key *

"Не поднимается GRE после падения канала."
Отправлено BJ , 20-Окт-12 23:13 
Сталкивался. Дело в ASA, дело в том что она часто успевает создает коннекцию для GRE до поднятия IPSEC. А живая  коннекция отправляет весь трафик по правилам на момент своего создания, тоесть мимо crypto.
Помогает "clear conn addr a.b.c.d"  на обоих асах
"Не поднимается GRE после падения канала."
Отправлено foxdenis , 22-Окт-12 11:40 
> Сталкивался. Дело в ASA, дело в том что она часто успевает создает
> коннекцию для GRE до поднятия IPSEC. А живая  коннекция отправляет
> весь трафик по правилам на момент своего создания, тоесть мимо crypto.
> Помогает "clear conn addr a.b.c.d"  на обоих асах

Хм, т.е. это нужно делать после каждого падения канала? Автоматически не настраивается? Просто у нас с одной стороны 2 радиоканала, т.е. погодозависимые, они могут отрубаться по 10 раз за день, а объект круглосуточный.

"Не поднимается GRE после падения канала."
Отправлено BJ , 22-Окт-12 16:13 
> Хм, т.е. это нужно делать после каждого падения канала? Автоматически не настраивается?
> Просто у нас с одной стороны 2 радиоканала, т.е. погодозависимые, они
> могут отрубаться по 10 раз за день, а объект круглосуточный.

Попробуйте добавить deny GRE траффика в out acl. Вроде ipsec проходит мимо этих правил, а значит без него коннекция создаватся не будет.

Я эту идею не проверял, решил довести crypto до маршрутизаторов.

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 23-Окт-12 13:55 
>> Хм, т.е. это нужно делать после каждого падения канала? Автоматически не настраивается?
>> Просто у нас с одной стороны 2 радиоканала, т.е. погодозависимые, они
>> могут отрубаться по 10 раз за день, а объект круглосуточный.
> Попробуйте добавить deny GRE траффика в out acl. Вроде ipsec проходит мимо
> этих правил, а значит без него коннекция создаватся не будет.
> Я эту идею не проверял, решил довести crypto до маршрутизаторов.

Попробовал поставить, в итоге совсем GRE не строит, убираешь - строит до первого падения. Может еще есть идеи? Спасибо.

PS clear conn addr помогает, после исполнения, туннели опять поднимаются.

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 24-Окт-12 09:26 
>>> Хм, т.е. это нужно делать после каждого падения канала? Автоматически не настраивается?
>>> Просто у нас с одной стороны 2 радиоканала, т.е. погодозависимые, они
>>> могут отрубаться по 10 раз за день, а объект круглосуточный.
>> Попробуйте добавить deny GRE траффика в out acl. Вроде ipsec проходит мимо
>> этих правил, а значит без него коннекция создаватся не будет.
>> Я эту идею не проверял, решил довести crypto до маршрутизаторов.
> Попробовал поставить, в итоге совсем GRE не строит, убираешь - строит до
> первого падения. Может еще есть идеи? Спасибо.
> PS clear conn addr помогает, после исполнения, туннели опять поднимаются.

С ASA реализовать особо не получается, но и убирать ее нельзя. Через static nat можно протащить на роутер внешний IP и с него строить gre, но уже шифрованный?

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 24-Окт-12 12:25 
>[оверквотинг удален]
>>>> могут отрубаться по 10 раз за день, а объект круглосуточный.
>>> Попробуйте добавить deny GRE траффика в out acl. Вроде ipsec проходит мимо
>>> этих правил, а значит без него коннекция создаватся не будет.
>>> Я эту идею не проверял, решил довести crypto до маршрутизаторов.
>> Попробовал поставить, в итоге совсем GRE не строит, убираешь - строит до
>> первого падения. Может еще есть идеи? Спасибо.
>> PS clear conn addr помогает, после исполнения, туннели опять поднимаются.
> С ASA реализовать особо не получается, но и убирать ее нельзя. Через
> static nat можно протащить на роутер внешний IP и с него
> строить gre, но уже шифрованный?

Тоже не получится, лицензия BASE на роутерах. Есть еще варианты?

"Не поднимается GRE после падения канала."
Отправлено fantom , 24-Окт-12 16:50 
>[оверквотинг удален]
>>>> Попробуйте добавить deny GRE траффика в out acl. Вроде ipsec проходит мимо
>>>> этих правил, а значит без него коннекция создаватся не будет.
>>>> Я эту идею не проверял, решил довести crypto до маршрутизаторов.
>>> Попробовал поставить, в итоге совсем GRE не строит, убираешь - строит до
>>> первого падения. Может еще есть идеи? Спасибо.
>>> PS clear conn addr помогает, после исполнения, туннели опять поднимаются.
>> С ASA реализовать особо не получается, но и убирать ее нельзя. Через
>> static nat можно протащить на роутер внешний IP и с него
>> строить gre, но уже шифрованный?
> Тоже не получится, лицензия BASE на роутерах. Есть еще варианты?

Есть, если не сильно волнует правомерность лицензии - включить вечный триал :)

"Не поднимается GRE после падения канала."
Отправлено fantom , 24-Окт-12 17:10 
>[оверквотинг удален]
>>>>> этих правил, а значит без него коннекция создаватся не будет.
>>>>> Я эту идею не проверял, решил довести crypto до маршрутизаторов.
>>>> Попробовал поставить, в итоге совсем GRE не строит, убираешь - строит до
>>>> первого падения. Может еще есть идеи? Спасибо.
>>>> PS clear conn addr помогает, после исполнения, туннели опять поднимаются.
>>> С ASA реализовать особо не получается, но и убирать ее нельзя. Через
>>> static nat можно протащить на роутер внешний IP и с него
>>> строить gre, но уже шифрованный?
>> Тоже не получится, лицензия BASE на роутерах. Есть еще варианты?
> Есть, если не сильно волнует правомерность лицензии - включить вечный триал :)

или воспользоваться какой-либо клиент/сервер архитектурой

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 24-Окт-12 18:06 
>[оверквотинг удален]
>>>>>> Я эту идею не проверял, решил довести crypto до маршрутизаторов.
>>>>> Попробовал поставить, в итоге совсем GRE не строит, убираешь - строит до
>>>>> первого падения. Может еще есть идеи? Спасибо.
>>>>> PS clear conn addr помогает, после исполнения, туннели опять поднимаются.
>>>> С ASA реализовать особо не получается, но и убирать ее нельзя. Через
>>>> static nat можно протащить на роутер внешний IP и с него
>>>> строить gre, но уже шифрованный?
>>> Тоже не получится, лицензия BASE на роутерах. Есть еще варианты?
>> Есть, если не сильно волнует правомерность лицензии - включить вечный триал :)
> или воспользоваться какой-либо клиент/сервер архитектурой

Ну тут не вариант.
Ещё подсказали вот это: http://www.booches.nl/2008/12/gre-over-ipsec-with-cisco-asa/
Т.е. sysopt connection reclassify-vpn
Но не помогло тоже.

"Не поднимается GRE после падения канала."
Отправлено fantom , 25-Окт-12 10:18 
>[оверквотинг удален]
>>>>> С ASA реализовать особо не получается, но и убирать ее нельзя. Через
>>>>> static nat можно протащить на роутер внешний IP и с него
>>>>> строить gre, но уже шифрованный?
>>>> Тоже не получится, лицензия BASE на роутерах. Есть еще варианты?
>>> Есть, если не сильно волнует правомерность лицензии - включить вечный триал :)
>> или воспользоваться какой-либо клиент/сервер архитектурой
> Ну тут не вариант.
> Ещё подсказали вот это: http://www.booches.nl/2008/12/gre-over-ipsec-with-cisco-asa/
> Т.е. sysopt connection reclassify-vpn
> Но не помогло тоже.

Судя по дате сего документа (December 3rd, 2008) надо думать замена прошивки на ASA может и помочь...

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 25-Окт-12 11:05 
>[оверквотинг удален]
>>>>>> строить gre, но уже шифрованный?
>>>>> Тоже не получится, лицензия BASE на роутерах. Есть еще варианты?
>>>> Есть, если не сильно волнует правомерность лицензии - включить вечный триал :)
>>> или воспользоваться какой-либо клиент/сервер архитектурой
>> Ну тут не вариант.
>> Ещё подсказали вот это: http://www.booches.nl/2008/12/gre-over-ipsec-with-cisco-asa/
>> Т.е. sysopt connection reclassify-vpn
>> Но не помогло тоже.
> Судя по дате сего документа (December 3rd, 2008) надо думать замена прошивки
> на ASA может и помочь...

Прошивка 8.25 стоит, но проблема и на ней вроде актуальна, у более старших прошивок надо NAT переделывать, не очень хочется.

"Не поднимается GRE после падения канала."
Отправлено fantom , 25-Окт-12 11:44 
>[оверквотинг удален]
>>>>> Есть, если не сильно волнует правомерность лицензии - включить вечный триал :)
>>>> или воспользоваться какой-либо клиент/сервер архитектурой
>>> Ну тут не вариант.
>>> Ещё подсказали вот это: http://www.booches.nl/2008/12/gre-over-ipsec-with-cisco-asa/
>>> Т.е. sysopt connection reclassify-vpn
>>> Но не помогло тоже.
>> Судя по дате сего документа (December 3rd, 2008) надо думать замена прошивки
>> на ASA может и помочь...
> Прошивка 8.25 стоит, но проблема и на ней вроде актуальна, у более
> старших прошивок надо NAT переделывать, не очень хочется.

http://www.cisco.com/en/US/products/ps6120/products_configur...

Не поможет?

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 25-Окт-12 16:09 
>[оверквотинг удален]
>>>> Ну тут не вариант.
>>>> Ещё подсказали вот это: http://www.booches.nl/2008/12/gre-over-ipsec-with-cisco-asa/
>>>> Т.е. sysopt connection reclassify-vpn
>>>> Но не помогло тоже.
>>> Судя по дате сего документа (December 3rd, 2008) надо думать замена прошивки
>>> на ASA может и помочь...
>> Прошивка 8.25 стоит, но проблема и на ней вроде актуальна, у более
>> старших прошивок надо NAT переделывать, не очень хочется.
> http://www.cisco.com/en/US/products/ps6120/products_configur...
> Не поможет?

Поставил.

Ситуация несколько изменилась.
Соответственно есть 2 провайдера на каждой асе и маршруты:

route OUTSIDE 0.0.0.0 0.0.0.0 DG1 1
route outside2 0.0.0.0 0.0.0.0 DG2 15
route outside2 ASA2(ISP2) DG2 1
route OUTSIDE 192.168.6.0 255.255.255.0(gre1 point) DG1 1
route outside2 192.168.7.0 255.255.255.0 (gre2 point) DG2 1

Если я выключаю/включаю интерфейс к основному провайдеру, то GRE1 поднимается после падения.
Если я роняю интерфейс к резервному провайдеру(DG2), то после включения интерфейса, GRE2 не поднимается. Если после этого уронить интерфейс к основному провайдеру, поднимается GRE2. Далее после включения основного провайдера поднимается и GRE1.

Т.е. в общем то резервирование работает, но все же хотелось бы чтобы GRE2 поднимался сам, без падения основного провайдера.


"Не поднимается GRE после падения канала."
Отправлено fantom , 25-Окт-12 17:00 
>[оверквотинг удален]
> route outside2 0.0.0.0 0.0.0.0 DG2 15
> route outside2 ASA2(ISP2) DG2 1
> route OUTSIDE 192.168.6.0 255.255.255.0(gre1 point) DG1 1
> route outside2 192.168.7.0 255.255.255.0 (gre2 point) DG2 1
> Если я выключаю/включаю интерфейс к основному провайдеру, то GRE1 поднимается после падения.
> Если я роняю интерфейс к резервному провайдеру(DG2), то после включения интерфейса, GRE2
> не поднимается. Если после этого уронить интерфейс к основному провайдеру, поднимается
> GRE2. Далее после включения основного провайдера поднимается и GRE1.
> Т.е. в общем то резервирование работает, но все же хотелось бы чтобы
> GRE2 поднимался сам, без падения основного провайдера.

Пишите в саппорт циски, может это баг... а задокументирванный баг -- это уже фича ;)

"Не поднимается GRE после падения канала."
Отправлено foxdenis , 25-Окт-12 17:05 
>[оверквотинг удален]
>> route OUTSIDE 192.168.6.0 255.255.255.0(gre1 point) DG1 1
>> route outside2 192.168.7.0 255.255.255.0 (gre2 point) DG2 1
>> Если я выключаю/включаю интерфейс к основному провайдеру, то GRE1 поднимается после падения.
>> Если я роняю интерфейс к резервному провайдеру(DG2), то после включения интерфейса, GRE2
>> не поднимается. Если после этого уронить интерфейс к основному провайдеру, поднимается
>> GRE2. Далее после включения основного провайдера поднимается и GRE1.
>> Т.е. в общем то резервирование работает, но все же хотелось бы чтобы
>> GRE2 поднимался сам, без падения основного провайдера.
> Пишите в саппорт циски, может это баг... а задокументирванный баг -- это
> уже фича ;)

Создал тему, пока молчат.

"Не поднимается GRE после падения канала."
Отправлено Сергей , 01-Мрт-15 20:59 
Все добрый день!

Не стал открывать новую тему, но проблема точно такая же ..
Есть два белых IP и циски.. все маршрутизаторы отвечают .. туннель в какой то момент падает и не поднимается.
При этом не сказал бы что это связанно с падением основного канала (он на мониторинге, и с ним все ок)
Исключение составляет, что нет ASA, как в изложенной выше проблеме.

R1
Tunnel14 is up, line protocol is down
  Hardware is Tunnel
  Description: to_nabcheln_r01
  Internet address is 192.168.212.1/24

R2
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 192.168.212.2/24


Пытался включать и выключать туннели с одной и другой сторон - не помогло
clean int tunnel на R1 и R2 - не помогло

Помогает только перезагрузка R2 .. и жду день, другой нового падения новый канал и все по новой :(

"Не поднимается GRE после падения канала."
Отправлено Михаил , 10-Янв-17 11:03 
>[оверквотинг удален]
>   Internet address is 192.168.212.1/24
> R2
> Tunnel1 is up, line protocol is up
>   Hardware is Tunnel
>   Internet address is 192.168.212.2/24
> Пытался включать и выключать туннели с одной и другой сторон - не
> помогло
> clean int tunnel на R1 и R2 - не помогло
> Помогает только перезагрузка R2 .. и жду день, другой нового падения новый
> канал и все по новой :(

Добрый день!

Столкнулся с такой же проблемой, не нашли решения?