Зачем мне нужен внешний адрес для создания внутреннего соединения между экземплярами GCE?

У меня есть VPC (10.11.0.0/20) с 3 виртуальными машинами. VM2 и VM3 одинаковы, за исключением того, что VM2 имеет внешний IP-адрес (эфемерный), а VM3 - нет. Они оба запускают образ Docker с веб-сервером, выставляющим порт 80.

У меня есть "разрешить все внутренние" правила брандмауэра:

NAME            NETWORK   DIRECTION  PRIORITY  SRC_RANGES    ALLOW
dev-internal    dev       INGRESS    1000      10.11.0.0/20  icmp,tcp:0-65535,udp:0-65535

Я могу подключиться к VM1, и с него я могу пропинговать как VM2, так и VM3.

Когда я nmap VM2, я вижу 998 закрытых портов и оба ssh а также http открыть - как и ожидалось.

Когда я nmap VM3, у меня отфильтровано 999 портов - значит, брандмауэр их маскирует? - и только ssh порт выставлен.

Я могу curl от VM2, но VM3 время ожидания.

Я ожидаю, что смогу общаться через внутреннюю сеть без назначения внешних IP-адресов. Что я делаю неправильно?

(Единственное небольшое осложнение заключается в том, что VPC определен в одном проекте, а VPC-Shared - во втором проекте. Правила и маршруты межсетевого экрана определены в хост-проекте VPC. Виртуальные машины живут во втором проекте, но в общем VPC.)

Изменить: результат netstat -antp от VM2:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1207/nginx: master  
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      311/sshd            
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      299/systemd-resolve 
tcp        0      0 10.11.0.6:46458         169.254.169.254:80      ESTABLISHED 381/python2.7       
tcp        0    272 10.11.0.6:22            173.194.90.33:64360     ESTABLISHED 43364/sshd: jamie_h 
tcp        0      0 10.11.0.6:53880         169.254.169.254:80      ESTABLISHED 401/device_policy_m 
tcp        0      0 10.11.0.6:46454         169.254.169.254:80      CLOSE_WAIT  385/python2.7       
tcp        0      0 10.11.0.6:46460         169.254.169.254:80      ESTABLISHED 385/python2.7       
tcp        0      0 10.11.0.6:46456         169.254.169.254:80      ESTABLISHED 384/python2.7       
tcp6       0      0 :::5355                 :::*                    LISTEN      299/systemd-resolve 

VM3 идентична - обе контейнерные ОС, обе работают с одним и тем же образом Docker - и поскольку у меня нет внешнего IP-адреса, я не могу подключиться к нему (не выполняя сложный танец...).

РЕДАКТИРОВАТЬ: шаги для воспроизведения:

1. Создать VPC
2. Создать правила брандмауэра для внешнего доступа SSH и HTTP к подсети (я использую ssh а также http теги соответственно)
3. Создать правило брандмауэра для внутреннего трафика на VPC (источник = подсеть, цель = все экземпляры в подсети)
4. Создать ВМ под названием source на VPC используя Debian с ssh сетевой тег и внешний IP (для поддержки SSH-соединения)
5. Создать ВМ под названием target1 на VPC с использованием COS и nginxdemos/hello образ докера ("hello world", выставленный на порту 80) с http сетевой тег и внешний IP
6. Создать ВМ под названием target2 на VPC с использованием COS и nginxdemos/hello изображение докера с http сетевой тег и без внешнего IP
7. SSH к source ВМ и пинг как target1 а также target2 - они отвечают
8. curl target1 и он отвечает с привет страницы мира
9. curl target2 и это время истекло
10. nmap -Pn target1 показывает ssh + http открыто, все остальные закрыты
11. nmap -Pn target2 показывает ssh открытый и все остальные отфильтрованные