06-25-2009 01:11 AM - edited 03-09-2019 10:23 PM
Hi all,
I need to help with interesting issue we have.
We have created NAT from one interface of PIX to other with access-list permiting something interesting for NAT and everything works but UDP traffic from specific pool and from Cisco VPN client no. We dont see traffic on the other side of firewall. But when we ping to the same destination (from the same pool) like for VPN traffic, traffic flows perfectly and we see xlate in PIX. Only for UDP traffic and from specific pool (192.168.3.0)from Cisco VPN, PIX doesnt create NAT xlate.
nat (_inside_) 12 access-list NAT_to_VPN
global (outside) 12 x.x.x.x netmask 255.255.255.255
access-list NAT_to_VPN extended permit ip 192.168.2.0 255.255.254.0 10.123.0.0 255.255.0.0
192.168.3.0 is included in pool 192.168.2.0/23
Any idea
gg
07-01-2009 03:02 PM
All sessions that connect through the security appliance must undergo some form of network address translation, or NAT. Each NAT or NAT Overload (PAT) session is assigned a translation slot known as an xlate. These xlates can persist even after you make changes to the NAT rules that affect them. This can lead to a depletion of translation slots or unexpected behavior or both by traffic that undergoes translation.
Always clear xlates after you add, change, or remove the aaa-server, access-list, alias, global, nat, route, or static commands in your configuration.
07-02-2009 12:58 AM
Problem is only with pool of addresses from 192.168.2.0/23 namely 192.168.3.0 and UDP. I cleared xlates every time I did changes in PIX related to NAT, routes and so on but without results.
Any idea?
BR
gg
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide