topic Re: xlate table in Network Security

xlate table

Bruce Summers — Mon, 11 Mar 2019 15:19:55 GMT

Can anybody point me in the right direction. I'm running a PIX 535 v8.0.3..

I'm attempting to connect from a specific VLAN (100) to a destination IP outside of our enclave (160.130.x.x). from this VLAN, i'm performing telnet, trace, ping, etc ALL of which fail. I perform the same (ping, telnet, etc..) to a different destination IP (159.160.x.x), from the same VLAN, taking the same route, and all attempts are successful.

I've looked at the ACL's and routes.

The only thing I do note is that when

accessing the 159.130.x.x, a translation table entry is being created. HOWEVER, when attempting connections to the 160.130.x.x, NO XLATE table is created.

I'm not entirely sure why that would be...I'm sure I havent explained this very well, or enough detail, but if you could give me some potential reasons I can research them further...

thanks

bruce

Re: xlate table

lm20ele — Thu, 16 Apr 2009 22:08:25 GMT

Can you post access list and routes??

Re: xlate table

Bruce Summers — Thu, 16 Apr 2009 23:13:26 GMT

this is going to be sanitized, but it gives you the jist...

access-list inbound extended permit ip any any

route outside 0.0.0.0 0.0.0.0 X.X.X.1

routing to outside interface via interface VLAN 100 (x.x.x.1)

I entered a static translation for the 160.130.x.x advertising from the outside to VLAN100 and it began working...but, i'm not sure why...I dont think I should have to have that translation...

Re: xlate table

roshan.maskey — Fri, 17 Apr 2009 02:41:13 GMT

Hi Bruce,

Lets try to debug this way:

First Try to ping, telnet, trace from your PIX to 160.130.x.x, if it works then you have to check ACL and NAT in PIX.

But, if it doesn't work from the PIX itself then check the routes to that network or might ping/tracert is not allowed on that subnet.

Re: xlate table

Bruce Summers — Fri, 17 Apr 2009 10:12:18 GMT

yes, I've been able to ping, trace etc from the firewall (FWSM) and/or the switch...its only when you are isolated to this particular VLAN..

It has to do with the translation of the 160.130.x.x address...but, i'm not sure why..here's my thinking.

I'm able to gain access to the 160.130.x.x when i put a static translation in, translating outside interface to inside (vlan) interface.

However, this is the only interface (that I've discovered) that this is necessary for...There is another VLAN that accesses the same destination subnet, that doesnt require the translation statement...

I know this is difficult to do without being able to post config information, but unfortunately, i'm not in a position to do so...

I was hoping to just get some "thoughts" about potential reasons this translation statement would be necessary...

thanks