In most cases it should figure out that the firewall is there, and ""just work"".
To get into the details on this a bit: I like to broadly categorize a 128T router's orientation to a NAT/FW into 2 scenarios:
- A coincidental NAT/FW
- A deliberate NAT/FW
A deliberate NAT/FW scenario is one you control and predict the NAT/FW. This is common when a NAT/FW is placed in front of a 128T router as a participant in the topology. An example of this might be a 128T router in AWS, where the VM has a private address and the EC2 NAT/FW is provisioned to work in conjunction with the 128T router.
A deliberate NAT/FW assumes you know and predict the IP address of the NAT/FW that will work in conjunction with a 128T waypoint. In this case, we assume that sessions arriving to the external NAT/FW address, on any UDP and TCP port, will be allowed and forwarded inbound to the 128T address. Also, sessions originated from the 128T waypoint address to router peers outside the deliberate NAT/FW are expected to be allowed, and NAT'ed to the same external NAT/FW address. We provision the external NAT address of a deliberate NAT/FW in the `external-nat-address` of a network-interface neighborhood (which causes it to propagate to all the corresponding adjacency configurations on that particular waypoint).
A coincidental NAT/FW scenario is one that you typically don't control or predict the NAT/FW. It just happens to be in the path between 128T waypoints as a consequence of where one is deployed. An example of this might be a 128T router deployed within someone else's enterprise, where the router communicates with other peers out through the NAT/FW.
A coincidental NAT/FW typically uses addresses and ports that cannot be predicted, and traffic originating from a 128T waypoint will get translated to them. Also, these typically do not allow an inbound session arriving at its public address to forward to the 128T waypoint address deployed behind it. For 128T to operate in this scenario, it assumes that outbound sessions will be allowed on any port, and have addresses and/or ports translated to addresses or ports on the NAT/FW. For coincidental NAT/FWs, no special provisioning is required. When the 128T device behind the NAT/FW first starts up, it will start sending BFD packets to it's peers on UDP port 1280, and it will be used by peers to detect the presence of the NAT/FW and adjust accordingly.
A few other things to consider: if your 128T router which is behind a conincidental NAT/FW scenario, is going to be the recipient of sessions (i.e. services will be routed to it), you can set `peer-connecitvity outbound-only` on the neighborhood configuration of the network-interface which is behind the NAT/FW. This will cause routers peered with it to understand that they must use NAT/FW traversal mechanisms if they need to send a session to the router.
Also if your 128T router in a deliberate NAT/FW scenario cannot have all TCP and UDP ports on the external address forwarded inbound to it, you can restrict this to a smaller range of ports. Just provision the NAT/FW ports that you know will be forwarded as a `port-range` in the neighborhood of the router which is behind the deliberate NAT/FW.
Hope this helps!