Сбой рукопожатия OpenVPN TLS - что еще это могло быть?

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

Aug  8 20:37:15 myserver ovpn-server[3797]: 12.34.56.78:48573 TLS: Initial packet from [AF_INET]12.34.56.78:48573, sid=80063aef 9e45c93a
Aug  8 20:38:15 myserver ovpn-server[3797]: 12.34.56.78:48573 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug  8 20:38:15 myserver ovpn-server[3797]: 12.34.56.78:48573 TLS Error: TLS handshake failed
Aug  8 20:38:15 myserver ovpn-server[3797]: 12.34.56.78:48573 SIGUSR1[soft,tls-error] received, client-instance restarting

Клиентами являются OpenVPN на портативном компьютере * buntu, подключенном к маршрутизатору NAT ADSL, и маршрутизатор 3G / 4G WWAN со встроенным клиентом OpenVPN.

Вот что я пока что проверил:

• Брандмауэр открыт (ну да, как еще могло бы начаться рукопожатие TLS)
• Время / дата правильно установлены на обоих концах
• Клиент OpenVPN обновлен (по крайней мере, на ноутбуке, сложнее проверить на маршрутизаторе 3G / 4G)
• Номера портов UDP не меняются в течение всего времени согласования (см. Журнал выше)

Что еще может быть причиной этого?

Редактировать: Итак, сюжет сгущается ... В отчаянии я попытался изменить всю цепочку конфигов на использование TCP, а в противном случае оставить все как было. Взрыв! Клиент OpenVPN на моем ноутбуке * buntu смог подключиться сразу. Но что делать, если клиент OpenVPN маршрутизатора 3G / 4G даже не поддерживает транспорт TCP? Я еще не закончил!

Редактировать: Просто чтобы прояснить здесь; Я точно изменил четыре вещи, чтобы заставить это работать:

1. Отредактировал конфигурацию OpenVPN, чтобы сказать proto tcp вместо того proto udp и перезапустили OpenVPN
2. В брандмауэр iptables сервера добавлено новое правило, разрешающее TCP 1194 - в остальном идентично уже существующему правилу, разрешающему UDP 1194.
3. Отредактировал протокол в определении службы в правиле брандмауэра в маршрутизаторе, к которому подключен мой ноутбук, чтобы разрешить исходящий TCP 1194 вместо исходящего UDP 1194 (на самом деле просто раскрывающийся список)
4. Отредактировал информацию о подключении OpenVPN на моем ноутбуке через Network Manager и проверил Use a TCP connection флажок

Каждые остальные настройки и конфигурация остаются идентичный как это было раньше.

Редактировать: У меня есть скрытое подозрение, что что-то странное происходит с маршрутизацией UDP-трафика на моем VPN-сервере; IP-адрес, к которому настроен OpenVPN для привязки, не является основным IP-адресом сервера, фактически он даже не находится в той же подсети. Вот как выглядит таблица маршрутизации:

$ route
Kernel IP routing table
Destination     Gateway          Genmask         Flags Metric Ref    Use Iface
default         11-22-33-1.thing 0.0.0.0         UG    0      0        0 eth0
22.33.44.0      *                255.255.255.0   U     0      0        0 eth0
10.8.0.0        *                255.255.255.0   U     0      0        0 tun0
11.22.33.0      *                255.255.255.0   U     0      0        0 eth0

$ ip route
default via 11.22.33.1 dev eth0 onlink 
22.33.44.0/24 dev eth0  proto kernel  scope link  src 22.33.44.55 
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.1 
11.22.33.0/24 dev eth0  proto kernel  scope link  src 11.22.33.44 

IP-адрес 22.33.44.55 был назначен позже, и именно к нему привязывается OpenVPN. Теперь я первый, кто признает, что знаю рядом с ничего насчет IP-маршрутизации, но может ли UDP-трафик на «новом» IP-адресе каким-то образом теряться из-за того, что у него нет собственного маршрута по умолчанию - или что-то в этом роде?