Zrada bude asi tím NATem na straně IPsec serveru. Dáno tím, že ROS chybně generuje dynamické policy pravidla v takové konfiguraci (když je NAT na straně IPsec serveru), takže výsledkem je, že data ti dojdou a správně se dešifrují, ale už nedokáže odpovědět.
Dá se ot odrbat určitou konfigurací. Sice mám použito pro L2TP/IPsec režim, ale pro XAUTH by o mohlo být snadno upravitelné. Předpokládám, že ta veřejka, z které děláš NAT je 88.88.88.88, IPčko na tom RB je 192.168.1.254, pak na tom RB tento ojeb:
/interface bridge
add admin-mac=02:00:00:00:00:01 auto-mac=no name=bridge-lan protocol-mode=none
add admin-mac=02:00:00:00:00:01 auto-mac=no name=bridge-pubip protocol-mode=none
/ip address
add address=192.168.1.254/24 interface=bridge-lan network=192.168.1.0
add address=88.88.88.88 interface=bridge-pubip network=88.88.88.88
/ip firewall nat
add action=masquerade chain=srcnat out-interface=bridge-lan
add action=dst-nat chain=dstnat dst-address=192.168.1.254 dst-port=500,4500 protocol=udp to-addresses=88.88.88.88
add action=dst-nat chain=dstnat dst-address=192.168.1.254 protocol=ipsec-esp to-addresses=88.88.88.88
/ip ipsec peer
add enc-algorithm=3des,aes-128,aes-192,aes-256 exchange-mode=main-l2tp generate-policy=port-strict local-address=88.88.88.88 passive=yes secret=TajneSdileneHeslo send-initial-contact=no
Pro ten tvůj případ by asi mělo stačit definici peers změnit o "auth-method=pre-shared-key-xauth exchange-mode=aggressive generate-policy=port-override mode-config=XXX".
Funguje to tak, že si to fixluje přímou přítomnost veřejné IP adresy na tom routeru a příchozí IPsec spojení srcnatem přehodí na tu veřejnou IP. A ta maškaráda zase odchozí odpověď IPsecu s veřejnou IP to přehodí na tu neveřejku a z venčí to spokojeně funguje, protože ty dynamicky vygenerovaná policy si s tou veřejkou sednou. Jinak, pokud z venku forwarduješ jen porty UDP/500 a UDP/4500, tak je v tomto případě vhodné forwardovat i ESP protokol, jinak může být problém, pokud by měl klient měl náhodou přímo veřejnou IP adresu.
