xlate table

Unanswered Question
Apr 16th, 2009
User Badges:

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...



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Bruce Summers Thu, 04/16/2009 - 16:13
User Badges:

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

access-list inbound extended permit ip any any

route outside 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...

roshan.maskey Thu, 04/16/2009 - 19:41
User Badges:

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.

Bruce Summers Fri, 04/17/2009 - 03:12
User Badges:

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...



This Discussion