Выполнение NAT через виртуальный сетевой интерфейс

Краткая версия: существуют ли какие-либо специальные настройки для правильной работы NAT на виртуальных сетевых интерфейсах Linux?

Я использую Linux (2.6.39-2-486 сборка Debian) в качестве сервера NAT. У него есть реальный сетевой интерфейс eth0, который подключается к внешней сети, и виртуальный eth0: 0 с адресом 192.168.42.2 и сетевая маска / 24 для внутренней сети. Несколько компьютеров внутри подключаются к Интернету через это окно (для шлюза по умолчанию установлено значение 192.168.42.2), брандмауэр которого настроен как (политика пересылки по умолчанию, установленная для целей отладки):

iptables -F
iptables -A INPUT -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -P FORWARD DROP
iptables -A FORWARD -s 192.168.42.0/24 -j ACCEPT
iptables -A FORWARD -d 192.168.42.0/24 -j ACCEPT
iptables -t nat -F
iptables -t nat -A POSTROUTING -s 192.168.42.0/24 '!' -d 192.168.42.0/24 -j MASQUERADE

В большинстве случаев эта настройка работает нормально. SSH, HTTP, другой трафик работает. Однако соединения с некоторыми сайтами, защищенными SSL, будут блокироваться на неопределенное время после подключения, даже если соединение работает при попытке запустить wget напрямую с сервера. Однако другие SSL-сайты работают нормально. Пример:

client:~> wget -dv https://use.typekit.com/qqh6jah.js
Setting --verbose (verbose) to 1
DEBUG output created by Wget 1.12 on linux-gnu.

--2011-07-24 15:59:14--  https://use.typekit.com/qqh6jah.js
Resolving use.typekit.com... 68.232.35.119
Caching use.typekit.com => 68.232.35.119
Connecting to use.typekit.com|68.232.35.119|:443... connected.
Created socket 3.
Releasing 0x08ccd160 (new refcount 1).
Initiating SSL handshake.

Есть идеи, что здесь происходит? Я играл с различными настройками -j LOG, но мне не хватало знаний, чтобы выбрать правильное ведение журнала, чтобы увидеть, что идет не так.