Solved: Object NAT not translating

James Davies · ‎11-29-2015

So, I have a range of public address's .104 /29

my outside interface is 106 on the ASA with the next hop as 105.

i have a SIP gateway server and have created object NAT for it, I did this in the ADSM, so the source address is 192.168.0.100 and the NAT translates this to .107 on the public address as the source.

unfortunately it's not working, the return traffic is going to 106 (the outside interface address) I cannot for the life of me work out why? Is there anything else I need to do? This is the last piece of work I need to do for a job and it's driving me nuts! Everything else works perfectly.

many thanks

Akshay Rastogi · ‎11-29-2015

Hi James,

Do you have some Manual NATs configured as well? I believe there might be some overlapping nat statements which might be causing this not to work.

Could you please share the nat statements which are present ?

Also for testing purpose you could try something like this :

nat (inside,outside) 1 source static <source-address of server behind inside interface> <mapped ip or 107>

Please let us know if after this it works?

also try with packet-tracer to check correct flow:

"packet-tracer input inside tcp(udp if sip signalling is udp based) <real-server ip> 5060 <destination ip> 5060(whatever destination using) detail"

with above statement see if packet hitting a correct nat statement.

Also check if SIP inspection is enabled? if now try enabling that and test "conf t)#fixup protocol sip 5060" and "fixup protocol sip udp 5060"

Hope it helps

Regards,

Akshay Rastogi

View solution in original post

Akshay Rastogi · ‎11-29-2015

Hi James,

Do you have some Manual NATs configured as well? I believe there might be some overlapping nat statements which might be causing this not to work.

Could you please share the nat statements which are present ?

Also for testing purpose you could try something like this :

nat (inside,outside) 1 source static <source-address of server behind inside interface> <mapped ip or 107>

Please let us know if after this it works?

also try with packet-tracer to check correct flow:

"packet-tracer input inside tcp(udp if sip signalling is udp based) <real-server ip> 5060 <destination ip> 5060(whatever destination using) detail"

with above statement see if packet hitting a correct nat statement.

Also check if SIP inspection is enabled? if now try enabling that and test "conf t)#fixup protocol sip 5060" and "fixup protocol sip udp 5060"

Hope it helps

Regards,

Akshay Rastogi

James Davies · ‎11-29-2015

I do have other NAT statements for my site to site vpns, and a global PAT for all Internet traffic, I was under the assumption object NAT would be performed first before any other natting.
sip is being inspected.
i don't know why my reply is being numbered lol

thanks for the reply, do I need another NAT statement as well as the object NAT?

Akshay Rastogi · ‎11-29-2015

Hi James,

Manual NATs are processed first before Object or After auto nat. if there is any Manual NAT which is overlapping to your required one then your traffic might not work as expected.

Is your dynamic nat for internet is configured as manual nat? if yes, then move it to object instead of manual nat. You do not need extra nat statement apart from object nat.

Try to check the flow through packet-tracer as i had mentioned in my last reply to see what nat statement it might be hitting.

Regards,

Akshay Rastogi

James Davies · ‎11-30-2015

Thank you Akshay,

did a few packet traces and fixed it, I had a manual any any NAT which I don't remember being there! It must of been hitting that rule first.

I deleted it and created it under object NAT, and placed it after my sip NAT.

seems to be working perfectly!

many thanks for helping.

Akshay Rastogi · ‎11-30-2015

Hi James,

I am glad that it worked.

You're welcome.

Regards,

Akshay Rastogi

Andre Neethling · ‎11-29-2015

HI. Can you provide the output of "show nat" or a screenshot of your nat rules from ASDM? We need to check how the nat is applied and the hits you are getting per rule.