I'm using a PIX 515 v8.0(4)32

I don't have anti spoofing enabled, if I enable it I get Deny UDP reverse path check from 10.x.x.2 to Server-X on interface inside

Yes, I miss it from your original post sorry.

I'm not sure if the ASA perform anti-spoofing by default on its interfaces.

If you do enable anti-spoofing the ASA is going to verify that there's a route to the packet towards the interface in which it receive it. If there's not, it will give you that error.

Are those spoofed packets that you want to allow through the PIX exist in your network somewhere?

The ASA knows how to reach those packets throughout another interface?

Federico.

Yes, the spoof packets network exist and there is a route

I understand that purposely the range exist on another interface and you're receiving them on the inside (that's why they are spoofed packets).

However, I believe that if the PIX has a route to those packets via one interface and it receive them via another interface, the PIX will not allow those packets through (and I think there's no way to do it)... unless you don't need the route to the actual packets and put the route to the inside (but then, there are no spoofed packets anymore)

Honestly I don't see a way to allow the packets through without letting the PIX know they should come from that interface (inside in this case).

However I might be missing something...

Federico.

Deny IP spoof from (10.x.x.2) to Server-X on interface inside

Is the 10.x.x2 your ASA's inside interface?

Do you have a static route that direct traffic to Sever-X to your core switch? And then have a default route on the core switch to ASA?

If so, all traffic initially from ASA will go to the core switch and then be directed back to ASA with the source address as ASA's address. ASA deems this as a snooped addresss. This happens when the Server-X route isn't on the core switch. (For example, Server-X is in remote site and the remote site is down).

Do not know how to disable this warning msg. I have the same issue in my environment.

I turned out to configure static route on the switch for all hosts the ASA needs to talk to with a bigger admin distance.