cogit
asked on
would i need to nat the perm router because of the following
I have a cisco perm -> pix->cisco 3600->lan toplogy, which the perm router, outside pix and 3000( Public int) concentrator are using realips 64.x.x.x and are connected in a switch in a vlan. Would I need to NAT the perm router to resolve the following?
IF so, what about the 3000. Here is the issue. taken from cisco
I have a web server on the inside interface of the Cisco Secure PIX Firewall. It is mapped to an outside public address. I want my inside users to be able to access this server by its DNS name or outside address. How can this be done?
A. The rules of TCP do not allow you to do this, but there are good workarounds. For example, imagine that your web server's real IP address is 10.10.10.10 and public address is 99.99.99.99. DNS resolves 99.99.99.99 to www.mydomain.com. If your inside host (for example, 10.10.10.25) attempts to go to www.mydomain.com, the browser resolves that to 99.99.99.99. Then the browser sends that packet off to the PIX, which in turn sends it off to the Internet router. The Internet router already has a directly connected subnet of 99.99.99.x, so it assumes that packet is not intended for it but instead a directly connected host and drops this packet. To get around this issue your inside host either must resolve www.mydomain.com to its real 10.10.10.10 address or you must take the outside segment off the 99.99.99.x network so the router can be configured to route this packet back to the PIX.
If your DNS resides outside the PIX (or across one of its DMZs) you may use the alias command on the Cisco Secure PIX Firewall to fix the DNS packet to make it resolve to the 10.10.10.10 address. Make sure you reboot your PCs to flush the DNS cache after making this change. (Test by pinging www.mydomain.com before and after the alias command is applied to make sure the resolution changes from the 99.99.99.99 to 10.10.10.10 address.)
If you have your own DNS server inside your network, this does not work because the DNS lookup never transverses the PIX, so there is nothing to fix. In this case, configure you local DNS accordingly or use local 'hosts' files on your PCs to resolve this name. The other option is better because it is more reliable. Take the 99.99.99.x subnet off the PIX and router. Choose an RFC 1918 numbering scheme not being used internally (or on any perimeter PIX interface). Then put a route statement back to the PIX for this network and remember to change your PIX default route outside to the new IP address on the router. The outside router will receive this packet and route it back to the PIX based on its routing table. The router will no longer ignore this packet, because it has no interfaces configured on that network.
PIX 6.2 introduced a new feature called Bidirectional NAT, which offers the functionality of the alias command and more.
For more information on the alias command, see Understanding the alias Command for the Cisco Secure PIX Firewall
IF so, what about the 3000. Here is the issue. taken from cisco
I have a web server on the inside interface of the Cisco Secure PIX Firewall. It is mapped to an outside public address. I want my inside users to be able to access this server by its DNS name or outside address. How can this be done?
A. The rules of TCP do not allow you to do this, but there are good workarounds. For example, imagine that your web server's real IP address is 10.10.10.10 and public address is 99.99.99.99. DNS resolves 99.99.99.99 to www.mydomain.com. If your inside host (for example, 10.10.10.25) attempts to go to www.mydomain.com, the browser resolves that to 99.99.99.99. Then the browser sends that packet off to the PIX, which in turn sends it off to the Internet router. The Internet router already has a directly connected subnet of 99.99.99.x, so it assumes that packet is not intended for it but instead a directly connected host and drops this packet. To get around this issue your inside host either must resolve www.mydomain.com to its real 10.10.10.10 address or you must take the outside segment off the 99.99.99.x network so the router can be configured to route this packet back to the PIX.
If your DNS resides outside the PIX (or across one of its DMZs) you may use the alias command on the Cisco Secure PIX Firewall to fix the DNS packet to make it resolve to the 10.10.10.10 address. Make sure you reboot your PCs to flush the DNS cache after making this change. (Test by pinging www.mydomain.com before and after the alias command is applied to make sure the resolution changes from the 99.99.99.99 to 10.10.10.10 address.)
If you have your own DNS server inside your network, this does not work because the DNS lookup never transverses the PIX, so there is nothing to fix. In this case, configure you local DNS accordingly or use local 'hosts' files on your PCs to resolve this name. The other option is better because it is more reliable. Take the 99.99.99.x subnet off the PIX and router. Choose an RFC 1918 numbering scheme not being used internally (or on any perimeter PIX interface). Then put a route statement back to the PIX for this network and remember to change your PIX default route outside to the new IP address on the router. The outside router will receive this packet and route it back to the PIX based on its routing table. The router will no longer ignore this packet, because it has no interfaces configured on that network.
PIX 6.2 introduced a new feature called Bidirectional NAT, which offers the functionality of the alias command and more.
For more information on the alias command, see Understanding the alias Command for the Cisco Secure PIX Firewall
ASKER
Yes i see that but what If I want to test my test webservrs by outside address ( I am not assigning these test servers with DNS names) I would need to change my PIX outside int because of the following:
If your inside host (for example, 10.10.10.25) attempts to go to www.mydomain.com, the browser resolves that to 99.99.99.99. Then the browser sends that packet off to the PIX, which in turn sends it off to the Internet router. The Internet router already has a directly connected subnet of 99.99.99.x, so it assumes that packet is not intended for it but instead a directly connected host and drops this packet. To get around this issue your inside host either must resolve www.mydomain.com to its real 10.10.10.10 address or you must take the outside segment off the 99.99.99.x network so the router can be configured to route this packet back to the PIX.
If your inside host (for example, 10.10.10.25) attempts to go to www.mydomain.com, the browser resolves that to 99.99.99.99. Then the browser sends that packet off to the PIX, which in turn sends it off to the Internet router. The Internet router already has a directly connected subnet of 99.99.99.x, so it assumes that packet is not intended for it but instead a directly connected host and drops this packet. To get around this issue your inside host either must resolve www.mydomain.com to its real 10.10.10.10 address or you must take the outside segment off the 99.99.99.x network so the router can be configured to route this packet back to the PIX.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
When I go to a browser and input 64.X.X.X , the website does not come up
Can you post your PIX config? I would need to see the alias line, and the corresponding static entry
The simple answer is in the "alias" command for the pix:
http://www.cisco.com/warp/public/110/alias.html