as far as I'm concearned this means that any hosts on the inside will not be natt'd when sending traffic to 192.168.10.0 network, this is what I want.
I have another PIX that accepts VPN clients from the internet. The VPN clients get an address of 10.200.0.0 / 28. When the VPN clients try to ping 192.168.0.0 network it works with most servers and pcs. But on certain servers it doesn't work. I get timed out. So I checked the config of the servers, they seem fine. **I then ping from the servers to the vpn clients and it works**, now when I ping from the vpn clients to the servers it also works. This shows me that there is something not right with the NAT statement. so I add this...
access-list nat0 permit ip any 10.200.0.0 255.255.255.240 nat (inside) 0 access-list nat0
now I can ping all servers and all pcs in the inside network (192.168.0.0).
What I don't understand is why did the first statement not work for all servers? Why do I need 2 statements which reflect the same outcome (nat nothing from the inside network)? any help would be great to clear this up.
1, configure NAT (dynamic or static)
2, permit the traffic with ACL (permited by default, unless you add any deny entry)
For PIX/ASA to allow INBOUND traffic, you must:
1, permit the traffic with ACL (denied by default, unless you add any permit entry)
2, configure NAT (static or NAT exemption)
Your problem is caused by the NAT configuration.
On PIX/ASA, dynamic NAT does not apply to traffic initialized from outside, with two exceptions:
1, nat (outside) 1 ... outside ->you configure NAT for outside interface, AND add "outside" at the end
2, nat (inside) 0 access-list ... ->which is called NAT exemption accroding to Cisco, and it does enable NAT for traffic initialized from outside
"nat (inside) 0 0 0" does not allow any traffic initialized from outside to use or create xlate entry, so the traffic just gets dropped.
To solve your problem, you should replace "nat (inside) 0 0 0" with "nat (inside) 0 access-list permit_all" and create an ACL with "permit ip any any".
Not exactly, and your material about dynamic NAT is subtly wrong as well in the same way.
When traffic is initiated from inside to outside through identity nat or regular NAT, then a temporary translation is entered in the tables, and the traffic is monitored according to the rules for the appropriate fixup. If the fixup detects that there will be a need for an outside system to initiate traffic inwards (FTP is the classic example) then the appropriate translation entry is created, and the traffic initiated from outside can use that translation entry.
This differs from your explanation in that your explanation does not take into account the possibility of a fixup opening inward access.
That won't solve his problem. His problem is with an overly generous nat identity. He should restrict the identity to only what is needed, add nat exemption for a few cases, but everything else should go through a regular policy NAT.
Bascially what your saying is that the statement...
Statement1 # nat (inside) 0 0.0.0.0 0.0.0.0 0 0
will not let any inbound traffic from the outside interface. It will however nat nothing from the inside interface outbound.
Statement2 # access-list nat0 permit ip 192.168.10.0 255.255.255.0 192.168.0.0
255.255.255.0 # nat (inside) 0 access-list nat0
and the above statement will permit traffic inbound from the outside interface as long as that traffic has a source of 192.168.10.0 and a destination of 192.168.0.0.
Thanks for your comments. But I do not agree with you.
What I said about "nat (inside) 0 0 0" is exactly right. I didn't mention the reason why return traffic is allowed when you are using common dynamic NAT. Unfortunately, your explaination on this is not correct. You misunderstand what fixup is.
Return traffic is allowed if there is an entry in the conn table and xlate table. It does not relate to Fixup. Fixup is generally a function working with NAT to help identify the location of embedded addressing information. It allows NAT to translate these embedded addresses and to update any checksum or other fields that are affected by the translation.
We all know PIX and ASA use The Adaptive Security Algorithm (ASA) for stateful application inspection. ASA = NAT(conn + xlate) + Fixup + ACL. NAT controls address translation, which is necessary for PIX/ASA; ACL filters out initial traffic which is not allowed, and it has no meaning to non-initial traffic. Fixup makes some necessary modification to the traffic which could not work with NAT without this modification.
And my solution SHOULD work. I do not think you have ever tried it, so I kindly suggest you to say "I think..." but not "it won't...".
Anyway, nice to discuss with you, and I am glad to discuss > >
For outbound traffic, PIX tries to create an xlate entry in its xlate table by looking for a matched NAT rule. If successed, it creates another entry in the conn table, which records connection states, and forwards the traffic.
For inbound traffic, PIX tries to find an matched existing entry in the conn table. If successed, then this traffic is the return traffic for a existing connection, the PIX simply allows it. If failed, the traffic must be a new connection initialized from outside. So it must be permitted by ACL; AND the PIX must find a matched NAT rule for it (static, NAT exemption or outside NAT); otherwise, it just gets dropped.
That is why you have to use NAT exemption (nat (inside) 0 access-list) or static NAT or outside NAT (nat (outside) x x x outside) in order to allow inbound traffic which is initialized from outside. Common dynamic NAT or Identity NAT (nat (inside) 0 0 0) does not apply to inbound initial traffic, so even the traffic is permitted by ACL, it still gets dropped because the PIX cannot find a matched NAT rule for it.
Your descriptions are contrary to the documented behaviour of fixup. My description was in accordance with the documented behaviour of fixup.
That is not -all- that fixup does.
formatting link
Look down to 'fixup protocol ftp'
Use the fixup protocol ftp command to specify the listening port or ports for the File Transfer Protocol (FTP). The following list describes the features and usage of this command:
*The PIX Firewall listens to port 21 for FTP by default.
*Mutliple ports can be specified.
*Only specify the port for the FTP control connection and not the data connection. The PIX Firewall stateful inspection will dynamically prepare the data connection as necessary.
Will the PIX Firewall stateful inspection dynamically prepare the data connection if the ftp fixup is turned off? No.
Does your ASA = NAT(conn + xlate) + Fixup + ACL equation have any room in it for this automatic opening of the data connection? No.
For further evidence that the fixup is responsible for opening the connection, scan down to the documentation of the 'strict' option of the ftp fixup.
Now look down to 'fixup protocol pptp':
The fixup protocol pptp 1723 command inspects PPTP protocol packets and dynamically creates the GRE connections and xlates necessary to permit PPTP traffic.
Could this be any clearer? The fixup protocol pptp "dynamically creates GRE connections". This is *not* just a "necessary modification to traffic" to permit PPTP to work with NAT: it actually creates new xlates and associated state.
What I said is that your solution will not solve his problem. His problem was not that he cannot ping from particular outside systems to particular inside systems: his problem was that he didn't understand the proper role of nat and translations in maintaining proper selective security.
The OP's setup is:
[random users] -- [public internet] -- [PIX #1] -- [PIX #2] -- limited or no access to internal servers
[authorized users] === [public internet] === [PIX #1] -- [PIX #2] -- wider access to internal servers
where -- indicates cleartext and == indicates VPN packets
The OP wishes to enforce the wider access policy *at PIX #2*. Your solution does not do that: your solution leaves open that wider access to random users who can get their unauthenticated packets past PIX #1. That makes PIX #1 responsible for enforcing the access policies that properly belong at PIX #2.
What is the First Rule of Security?
Okay, so that's "It won't be perfect no matter what you do!".
But soon after that in the list is, "Only allow what you *must* except where the cost of doing so is unacceptably high compared to the cost-weighted risk."
Like the way that you said, "You misunderstand what fixup is.", rather than "I think you misunderstand what fixup is." ?
If you can *initialize* a connection from outside, then there must be an entry for it in the xlate table and conn table. You can see the entries by issuing "show xlate" and "show conn". So you should check your configuration that if you:
1, set an improper NAT rule accidentally;
2, for stateless protocols, like UDP or ICMP, an entry created by traffic initialized from inside is not removed immediately after the connection terminates. It stays in the table until the idle timer expires. During this period, if traffic with the same protocol and port numbers reaches the PIX, it will be treated as return traffic and the PIX will allow it.
For (1), you should find the improper nat rule and modify it. For (2), you should shorten the idle timers.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.