FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP

Greetings all

I was just woundering one thing while configuring a new PAT setup in our FWSM. You have the option of using an IP range, a single IP or the IP of the "external" interface as GLOBAL address for the PAT. I've searched some of the guides regarding this subject but haven't really seen any recommendation when to use the different methods other than the possible shortage of ports when using single IP and large number of computers.

Does anyone have any experience in using the different methods and have any recommendations? Is there a disadvantage when using GLOBAL interface instead of GLOBAL IP for example?

Regards Fredrik Hofreb

Reply to
Hoffa
Loading thread data ...

Greetings all

I was just woundering one thing while configuring a new PAT setup in our FWSM. You have the option of using an IP range, a single IP or the IP of the "external" interface as GLOBAL address for the PAT. I've searched some of the guides regarding this subject but haven't really seen any recommendation when to use the different methods other than the possible shortage of ports when using single IP and large number of computers.

Does anyone have any experience in using the different methods and have any recommendations? Is there a disadvantage when using GLOBAL interface instead of GLOBAL IP for example?

Regards Fredrik Hofren

Reply to
Hoffa

I believe earlier versions of the software would use the keyword "interface" instead of the interface external IP itself.

If you use a public IP then -somehow- traffic for that IP needs to get to the FWSM (or PIX or ASA). The best way to do that is to have the router route traffic for the public IP over to the interface IP. In the case of PIX and ASA, "the router" might turn out to be the ISP's router off-site and making the appropriate arrangements is sometimes cumbersome (or expensive.) The PIX and ASA will proxy-arp for IPs named in a 'global' statement, provided that proxy-arp has not been disabled and provided that the IP has not been marked for NAT exemption (nat 0 access-list in PIX 5/6; I thought I saw additional mechanisms in PIX/ASA 7); but proxy-arp is often not entirely reliable.

PIX 5 did not have "static PAT" (port forwarding); PIX 6 port forwarding for the interface IP has the restriction that telnet and one other port (needed by PDM) may not be forwarded. There are unresolved questions about what port forwarding for the interface IP would mean if the port is one used for PPTP or LT2P or IPSec and those VPN protocols are configured for termination on the outside interface. There is no restrictions on the forwarding of ports for public IPs that are not the interface IP.

If you are PAT'ing to an IP that has static PAT to allow inward access to service (e.g., for a mail server) then there can sometimes be logistical reverse DNS problems: for example, you might need the IP to resolve to one name to satisfy your SMTP peers, but you might need it to resolve to a different name to satisfy the SSL certificate processing for web sites you host.

When you have an global address range specified, then each outgoing host gets exclusive use of one entire IP for the transaction duration, with no Port Address Translation. That can sometimes be critical for use with protocols that interact badly with port translation. The rule in PIX 5/6 is that if there is an available IP in a ranged global {whose policy number matches the nat policy number} then the entire IP is allocated, and that PAT (signaled by a global with a single IP) is used (if configured) when the pool runs out. If only -some- of the traffic from a host really needs one-to-one translation then you either need a big pool of public IPs or else you need to start using "policy nat". PIX/ASA/FWSM 7 might have additional mechanisms for determining whether PAT or one-to-one NAT is used.

Beyond that... if you have multiple public IP ranges, then your choice of public IPs can affect return packet routing, which can be important sometimes.

Reply to
Walter Roberson

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.