TmpUser13

Ты сделал что-то не то или использовал не ту инструкцию. При настройке головной-филиал не нужно:
- GRE
- Динамических адресов

Мастер-филиал - это стандартная настройка через политики. Скринов делать не буду, набросаю командами:

# 10.4.1.0/24 - филиал
# 10.4.2.0/24 - мастер
# 1.1.1.1 - белый IP филиала
# 2.2.2.2 - белый IP мастера
# в данном случае аутентификация по сертификатам, но она легко меняется на PSK
# На другом микротике перевернуть все зеркально
# Политики
/ip ipsec policy
add comment="To main VPN" dst-address=10.4.2.0/24 peer="Server room VPN" proposal=\
    proposal1 src-address=10.4.1.0/24 tunnel=yes
# Напарники (peers)
/ip ipsec peer
add address=2.2.2.2/32 comment="To main VPN" exchange-mode=ike2 name=\
    "Server room VPN" profile=profile_5
# Предложения (proposals)
/ip ipsec proposal
add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=proposal1
(выглядит немного странно, но Galua Counter Mode самоаутентифицирующися режим)
# Профили (profiles)
/ip ipsec profile
add dh-group=ecp256,modp2048,modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256,aes-192 \
    hash-algorithm=sha256 lifetime=2h name=profile_5 proposal-check=strict
# Идентификация (identity)
add auth-method=digital-signature certificate="IPSec cert with key" comment=\
    "Identity for 10.4.2.0/24 network" match-by=\
    certificate peer="Server room VPN" remote-certificate="RB2011 IPSec cert"

That's all, folks! Больше ничего не надо. Ни GRE, ни маршрутов, никакого прочего огорода. Как система разберется куда слать пакеты? А она посмотрит в таблицу политик :)

А, ну правила конечно же нужны:

/ip firewall nat
add action=accept chain=srcnat comment=\
    "Does not touch IPSec ESP packets to avoid break packets checksum" ipsec-policy=out,ipsec \
    log-prefix="NAT avoid" out-interface=pppoe-out1
# Никогда не забываем это правило! Иначе швах, NAT ломает пакет, та сторона его не принимает
# out-interface конечно же свой
/ip firewall filter
add action=accept chain=input comment=IKE log-prefix=IKE/NAT-T port=500,4500 protocol=udp
add action=accept chain=input comment=ESP log-prefix=ESP protocol=ipsec-esp
add action=accept chain=output comment=IKE log-prefix=IKE/NAT-T port=500,4500 protocol=udp
add action=accept chain=output comment=ESP log-prefix=ESP protocol=ipsec-esp
add action=accept chain=forward dst-address=10.4.2.0/24 src-address=10.4.1.0/24
add action=accept chain=forward dst-address=10.4.1.0/24 src-address=10.4.2.0/24

Я слабо разбираюсь в Windows, поэтому не считайте моё мнение экспертным, могу быть не прав.

Если не ошибаюсь, при входящих TCP-соединениях Windows автоматически сохраняет IP-адрес назначения, на который это соединение пришло, во внутренних структурах сокета, поэтому в рамках одного TCP-соединения пакеты будут уходить с одного IP-адреса (они автоматически bind'ятся на этот source ip address).

Далее маршрутизация: в Windows, начиная с Vista, используется strong host model (см. RFC1122), которая предписывает отправлять пакеты с того сетевого интерфейса, IP-адрес которого указан в структурах сокета.
Старая статья на technet имеет следующую приписку:

If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface.

И далее описываются похожие принципы, связанные с RFC3484.

«Автоматически» всё работает только для протоколов с концепцией соединения, т.е. с TCP. Для UDP, если программа не написана с учётом поддержки multihoming, пакеты могут уходить согласно метрике, т.е. с неправильного адреса (не с того, на какой пришел входящий пакет), и ничего не заработает.