Нормально не работает gre tunnel.
Имеем 2 шлюза: 1 офис 192.168.4.0/24, 2 филиал 192.168.17.0/24.
Соединяем через gre-tunnel через серые ip провайдера.
1 шлюз(офис)
$IP     -A FORWARD  -i eth0 -s 192.168.14.0/24 -o net_g -d 192.168.17.0/24 -p ALL -j ACCEPT
$IP     -A FORWARD  -i net_g -s 192.168.17.0/24 -o eth0 -d 192.168.14.0/24 -p ALL -j ACCEPT
$IP     -t nat -A POSTROUTING -s 192.168.0.0/16 -d ! 192.168.0.0/16 --out-interface $LAN_INET  -j SNAT --to-source $IP_INET
route -n
192.168.17.0     0.0.0.0         255.255.255.0   U     0      0        0 net_g
192.168.14.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
cat /proc/sys/net/ipv4/ip_forward
1
net_g     Link encap:UNSPEC  HWaddr AC-11-13-06-00-00-65-74-00-00-00-00-00-00-00-00
          inet addr:192.168.14.254  P-t-P:192.168.4.254  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1300  Metric:1
          RX packets:6803 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8044 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

2 шлюз (филиал)

$IP     -A FORWARD  -i eth0 -s 192.168.17.0/24 -o net_g -d 192.168.14.0/24 -p ALL -j ACCEPT
$IP     -A FORWARD  -i net_g -s 192.168.14.0/24 -o eth0 -d 192.168.17.0/24 -p ALL -j ACCEPT
route -n
192.168.17.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.14.0     0.0.0.0         255.255.255.0   U     0      0        0 net_g

cat /proc/sys/net/ipv4/ip_forward
1

          RX bytes:1310960 (1.2 MiB)  TX bytes:2593038 (2.4 MiB)
net_g     Link encap:UNSPEC  HWaddr AC-11-13-0A-00-00-65-74-00-00-00-00-00-00-00-00
          inet addr:192.168.17.254  P-t-P:192.168.7.254  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1476  Metric:1
          RX packets:7735 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6972 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2264413 (2.1 MiB)  TX bytes:1545588 (1.4 MiB)
ОС debian lenny 5.03, модуль ip_gre подгружается по умолчанию

Что работает:
Пинг и трассировка в обе стороны ходит нормально, ping x.x.x.x -l 1500 тоже, если не применять ping -f.
Из филиала в офис работает rdp, radmin, передача файлов через radmin, подключение обычного сетевого диска не проходит. Все сессии рвутся через некоторое время.
Из офиса в филиал кроме пинга и трассировки не один протокол не ходит.
######################
tcpdump филиала
tcpdump -i net_g dst port 3389 -vvv
tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket
tcpdump: listening on net_g, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
12:54:52.169319 IP (tos 0x0, ttl 127, id 10350, offset 0, flags [DF], proto TCP (6), length 48) 192.168.14.98.1169 > 192.168.17.100.3389: S, cksum 0xc1e2 (incorrect (-> 0xf9e2), 3933747407:3933747407(0) win 51199 <mss 1220,nop,nop,sackOK>
12:54:55.178484 IP (tos 0x0, ttl 127, id 10354, offset 0, flags [DF], proto TCP (6), length 48) 192.168.14.98.1169 > 192.168.17.100.3389: S, cksum 0xc1e2 (incorrect (-> 0x39e3), 3933747407:3933747407(0) win 34815 <mss 1220,nop,nop,sackOK>
12:55:01.183686 IP (tos 0x0, ttl 127, id 10356, offset 0, flags [DF], proto TCP (6), length 48) 192.168.14.98.1169 > 192.168.17.100.3389: S, cksum 0xc1e2 (incorrect (-> 0xf9e2), 3933747407:3933747407(0) win 51199 <mss 1220,nop,nop,sackOK>
в итоге
tcpdump -i eth0 dst port 3389 -vvv
пусто в логах

По крайней мере пакеты до net_g интерфейса доходят до филиала из офиса.
#########
tcpdump офиса. на eth0 пакеты ходят
tcpdump -i eth0 dst port 3389 -vvv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:05:35.454617 IP (tos 0x0, ttl 128, id 24654, offset 0, flags [DF], proto TCP (6), length 48) 192.168.17.100.1689 > 192.168.14.98.3389: S, cksum 0x82ad (correct), 3450573373:3450573373(0) win 65535 <mss 1360,nop,nop,sackOK>
13:05:35.572397 IP (tos 0x0, ttl 128, id 24660, offset 0, flags [DF], proto TCP (6), length 40) 192.168.17.100.1689 > 192.168.14.98.3389: ., cksum 0x830d (correct), 3450573374:3450573374(0) ack 2547029023 win 65535
13:05:35.572636 IP (tos 0x0, ttl 128, id 24661, offset 0, flags [DF], proto TCP (6), length 87) 192.168.17.100.1689 > 192.168.14.98.3389: P 0:47(47) ack 1 win 65535
13:05:35.721407 IP (tos 0x0, ttl 128, id 24675, offset 0, flags [DF], proto TCP (6), length 456) 192.168.17.100.1689 > 192.168.14.98.3389: P 47:463(416) ack 20 win 65516
13:05:35.893663 IP (tos 0x0, ttl 128, id 24690, offset 0, flags [DF], proto TCP (6), length 52) 192.168.17.100.1689 > 192.168.14.98.3389: ., cksum 0xe8b5 (correct), 463:463(0) ack 20 win 65516 <nop,nop,sack 1 {1240:1467}>
Соединение работает по +(-)5 минут и рвется.

Пробывал различно
$IP -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
#$IP -A FORWARD -o net_gorkogo -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1060
#$IP -A FORWARD -i net_gorkogo -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1060
#$IP -A FORWARD -o net_g -j TCPMSS --clamp-mss-to-pmtu
#$IP -A FORWARD -i net_g -j TCPMSS --clamp-mss-to-pmtu
#$IP -A FORWARD -i net_g -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
#$IP -A FORWARD -o net_g -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
различные значения mtu в iptables и менять mtu на интерфейсах gre_g, на интерфейсах клиентов. Как видим даже при различных mtu на интерфейсах пакеты в одну сторону ходят нормально.

Из офиса по серому ip провайдера есть еще один gre-tunnel до второго филиала и все отлично работает, но скорость около 48-90 кбит\с.
Файрволы и настройки максимально синхронизированы, рабочий gre tunnel на время тестов в том числе отключал.
Скорость на нужном филиале скорее всего тоже не превышает 48-90 кбит\с.
Файрволы на клиентах Win 2003, XP отключены.
Во флагах пакетов пока разбираюсь, вижу что косяк, но непонятно почему.
Есть варианты как отследить косяк? Почему не идут пакеты из-за форвардинга или mtu?