Observations:
When a packet from the Internet is destined to a PAT global address and is blocked by an ACL, a syslog error message of PIX-3-106011 is generated. This is because the packet originated from the host on the outside and is directed to a host on the outside subnet of the PIX, IP redirect, which the PIX does not allow.
When a packet from the Internet is destined to a NAT global address and is blocked by an ACL, a syslog warning message of PIX-4-106023 is generated. This is because the packet originated from the host on the outside and is destined to a global NAT address which is interpreted by the PIX as the global address being on the inside interface. So a normal warning instead of an error is generated because the packet is seen to be travelling from the outside interface to the inside interface.
1. Is this normal behavior?
2. Why is the NAT global address seen as being on the inside instead of the outside interface like the PAT address?
3. I thought if the IP address of a host was in the same subnet as a particular PIX interface, then syslog would always see that host as on that interface. I have noticed this not to be the case on IPSEC site to site hub and spoke topologies.
Example PIX setup:
inside - 192.168.1.1/24
DMZ - 172.16.1.1/24
outside -10.10.10.1/24
route inside 172.17.1.0 255.255.255.0 192.168.1.3
When a packet is travelling from 172.17.1.10 (remote subnet via a VPN tunnel) to 10.10.10.10, sometimes it will be denied because the PIX sees the 10.10.10.10 host as on the inside as well. This causes a no xlate 106011 error message and denies the packet. I have seen this when doing traceroutes in VPN setups. Do I need to involve addtional routes to another internal router to overcome this problem?
Can someone help with this scenario?
Thanks,
RJ
