Hi, we experienced a werid problem that SRX-5400 (cluster) would miss static NAT translation, we have a SBC in trust zone with RFC1918 address, SRX-5400 statically translate this SBC's IP to publically routable IP address, customer sets the SIP trunking pointing to this public IP address, standary stuff and it has been working fine.
We recently had an incident that SIP INVITES sent from our side to customer were silently dropped on customer side, upon troubleshooting, customer confirmed that the INVITES were coming from our side SBC's RFC1918 address therefore dropped by their side firewall. We don't have a way to consistently reproduce this problem, I opened a case with JTAC, JTAC engineer was also puzzled as NAT configuration as well as security policies all look correct, I am wondering can this happen on SRX? I mean, static NAT would either work or not, how could it be that certain translations would be missed?
What Junos version are you running?
I'm aware of at least two static nat bugs (call PR in Junos for problem reports).
Thanks, I am running 15.1X49-D100, the scenario described in neither PR applies to the incident we had, the cluster is strict active-standby, there is no Z-mode flow, plus the problem happened when the session was initiated from private/trust side of the security zone.
I would encourage your jTAC engineer to look for matching bugs in the PR database. Hopefully someone else has already reported this. Since your configuration is correct and the problem is intermitent this pretty much has to be a bug.
If you are the first report, then JTAC needs to gather all the data needed to reproduce it in their lab and create the new PR for the Junos software team to fix. This can be hard with an intermitent problem so push JTAC hard too.
Thanks, Steve, JTAC was able to identify the problem, basically "traffic from external and internal matching the nat rule the same time and then it may have a little chance to fail the nat translation", the fix will be in D130
Is it new PR? If new PR can u share the PR no.