1) "Почему так получилось" -- вероятнее всего, ваш провайдер использует схему блокировки с анализом запроса от клиента, и если ресурс из списка блокируемых, то клиенту отправляется TCP RST пакет, после чего клиентское приложение закрывает соединение. Потом приходит реальный ответ от сайта, но т. к. сайт находится дальше, чем оборудованием провайдера, то к этомум моменту ситуация следующая: клиент получил от системы DPI фальшивый TCP RST пакет, якобы от того сайта, к которому он обращался; клиент сбросил соединение; пришедший ответ от сайта системой клиента просто отбраывается, т. к. с точки зрения системы, он не относится ни к одному из установленных соединений.
После включения локального VPN-соединения для перехвата всего трафика для анализа, вероятнее всего, фальшивый TCP RST от DPI к клиенту приложением дропается. Я бегло посмотрел описание PacketCapture, там вроде как даже изменения в транзитные пакеты можно вносить по шаблону, так что вполне может быть, что либо предусмотрен мехнизм игнорирования предположительно фейковых TCP RST, либо это побочный эффект от какого-то другого функционала PacketCapture.
2) Что делать, чтобы всё работало -- тут вам уже объяснили. VPS за пределами контролируемого периметра с последующей настройкой выхода в интернет через этот VPS. Вариантов реализации -- тьма. Это и VPN, и поднятые SSH-туннели, проксирующие порт какого-нибудь Squid на клиента, и sshuttle, и ещё много-много всякого.
