Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
Configuring SRX240H w/ 9.6R1.13
If I have a static nat entry configured from zone internet to zone private that translates destination 184.108.40.206 to private zone 10.0.0.8, will that automatically also set the source IP of traffic from 10.0.0.8 to 220.127.116.11 when passing in the opposite direction? I don't mean the return traffic on established inbound flows/sessions, I mean new outbound sessions/flows destined to anything in the internet zone.
If not, is there an easy way to make that happen, instead of configuring duplicate reverse-direction static nat entries?
Static NAT is bi-directional. That means that it will source-nat for 10.0.0.8 to 18.104.22.168 as well regardless of which direction initiates the session.
Do you happen to know if the DNS ALG will also translate DNS replies against static nat entries as well?
ex: 10.0.0.7 does a query against an internet dns server, and the reply is 22.214.171.124, will the ALG automatically change that to 10.0.0.8 when it forwards the reply on to 10.0.0.7
IOS static nat does this...
No, there is no nat translation for DNS payload. So if the response says 126.96.36.199, this is what the client will receive.
What about using Destination nat.... is there a way to do reverse NAT with destination NAT ??
I have 2 ISP and i configure destination NAT like this:
188.8.131.52 port 80 to 10.10.10.10 port 80
184.108.40.206 port 80 to 10.10.10.10 port 80
I want that the traffic incoming from the 220.127.116.11 port 80 goes out to this IP interface, the same for the traffic incoming from 18.104.22.168 port 80
Reply for traffic coming in from one ISP should match existing session and not need to perform another route lookup. So this should work. If this is not working as expected, then I would suggest enabling flow traceoptions to see how the SRX is handling the traffic.
Even if i configured Destination NAT ?? it isn't working this way in my case.
I solve my problem already... , the problem was that the interfases were configured in different zones and when it was trying to return the package back i received a "zone missmatch error(i saw it in the a flowtrace file". This is something that doesn't happen on the SSG (almost sure).
my flowtrace file:
Dec 15 18:46:13 18:46:12.987602:CID-1:RT: route lookup: dest-ip orig ifp reth2.0 output_ifp reth1.0 orig-zone 10 out-zone 9 vsd 2Dec 15 18:46:13 18:46:12.987602:CID-1:RT: