Коротко — причина в том, что последнее правило белого списка (на самом деле «catch‑all» deny) слишком широкое и блокирует пакеты, нужные для согласования IP в PPP (IPCP) при установке VPN‑сессии. В результате клиенту либо не могут назначить IP, либо отбрасываются ответы/broadcast‑пакеты, и IPCP завершается с ERR_OPTION_REJECTED (Android) или PPP‑ошибкой 720 (Windows).
Почему именно так:
- На этапе IPCP происходит обмен опциями назначения IP (иногда используются адреса 0.0.0.0/широковещательные пакеты 255.255.255.255 и др.). Если packet‑filter/ACL на виртуальном хабе блокирует эти пакеты, переговоры о IP‑адресе не проходят.
- Порядок правил важен: если deny‑правило стоит ниже/выше и маски слишком общие, они перехватывают нужный трафик. Поэтому «удалил последнее правило — заработало» — типичная симптоматика.
Как исправить (пошагово):
1. Уберите полностью‑широкое deny‑правило в качестве временной меры, чтобы восстановить подключение.
2. Сформируйте whitelist по принципу «сначала разрешить всё, что нужно для работы VPN и клиентов, затем запретить остальное». То есть:
- Разрешите трафик между сервером и клиентами виртуального адаптера/подсети (например, если клиенты получают 192.168.30.0/24 — разрешите IP 192.168.30.0/24 ↔ 0.0.0.0/0).
- Разрешите broadcast/zero‑address, которые используются при назначении адреса: разрешите пакеты с/на 255.255.255.255 и 0.0.0.0 (или просто разрешите всю IP‑связь в пределах VPN‑подсети).
- При использовании L2TP/IPsec дополнительно убедитесь, что разрешены UDP 500, UDP 4500 и UDP 1701 (если применимо) — но это для внешнего FW, не обязательно для внутреннего ACL виртуального хаба.
3. Пример простых правил (адаптируйте под вашу подсеть):
- Accept: Source = any (0.0.0.0/0), Destination = 192.168.30.0/24, Protocol = IP, Action = Accept
- Accept: Source = 192.168.30.0/24, Destination = any (0.0.0.0/0), Protocol = IP, Action = Accept
- Accept: Source = any, Destination = 255.255.255.255, Protocol = any, Action = Accept (для broadcast)
- Deny: Source = any, Destination = any, Protocol = any, Action = Deny (catch‑all — в конце)
Разместите accept‑правила выше deny‑правила.
4. Если вы используете SecureNAT/DHCP виртуального хаба, убедитесь, что разрешены UDP 67/68 (DHCP), либо просто разрешаете трафик внутри VPN‑подсети — это нужен при работе DHCP (если используется).
5. Проверяйте логи: в менеджере SoftEther включите логирование Virtual Hub и смотрите, какие пакеты отбрасываются/какое правило срабатывает при попытке подключения. Это поможет точнее настроить exception‑правила.
6. Тестируйте после каждого изменения — сначала подключение, затем проверка доступа к нужным ресурсам.
Если хотите, пришлите (скрин или текст) текущие правила whitelist (очень важно — в каком порядке и что именно запрещается). Тогда я смогу подсказать точную корректировку под вашу конфигурацию и приведу готовые правила под вашу подсеть.