Cannot connect to CMA behind s2s, firewall routed return traffic to inf by route not into s2s tunnel

[Michal_Gans]

We have s2s (terminated on FWext) to mng network in customer environment and we can connect to all assets (include both MDSs and CMAs not related to FWext) except both CMAs (from domain where FWext is used in policy).

I tried to debug the issue and I found that the return packet from CMA goes to FWext, but FWext used routing table and send it to some interface not into s2s tunnel.

Because it is not a critical problem for us, I do not want to open SR on it and rather try to find a solution by digging deeper.

So mine question, do you have any idea where to start (I think it will be matther of kernel debug commands but I'm not sure).

[Maarten_Sjouw]

this is normal behaviour, CP control ports to and from the management of the FWext will not be encrypted.
The reason for this is quite simple as well, what happens when you make a mistake in the VPN config and push policy, you lock yourself out. You need to setup a NAT for the CMA managing FWext, I know I know it's more or less the same danger, however the chance a Tunnel fails is about 20 times bigger than a NAT failing.

[Tommy_Forrest]

I'd echo @Maarten_Sjouw 's recommendation to establish a NAT for your remote gateway to connect too.  We do that for a number of gateways that are out in the field and it works well.

Make sure your NAT device also NAT's your CMA's outbound traffic to the correct IP as well.  That'll help for writing firewall rules on both sides to limit communications from undesired sources.

And if you have a separate MLM then you'll need to setup a NAT for that too.

[Michal_Gans]

Thanks @Tommy_Forrest and @Maarten_Sjouw.

We use access through NAT for many customers too, but in this case I would prefer s2s. But it looks like, I will be disappointed. 🙂

[G_W_Albrecht]

You could just involve TAC for a resolution...

[Wolfgang]

Michal,

at first I really recommend to follow the suggestion of @Tommy_Forrest and @Maarten_Sjouw. Using NAT is the best way, connection is secured and encrypted  and simple to debug in case of troubleshooting....

To your configuration:

Because the ports for management traffic are default excluded from VPN you have to change this behaviour.

Follow Management traffic sent as clear text even when configured to be sent via VPN tunnel 

to send management traffic over VPN.

Wolfgang