Hi all,
The reason this does not work is more due to NAT concerns than anything else.
If we follow a theoretical connection attempt from 192.168.0.198, without
the PIX's 'bad' behavior, this becomes clear. Apologies if this appears
oversimplified, but the attempt is to clearly illustrate the problem.
First the client does a lookup for the destination address: www.myserver.com
This returns our servers 'outside' address: 199.199.199.199
Then we attempt to connect to that address. This is NOT on our local
subnet, therefore, we go to our default gateway (in this case the
PIX). The PIX would then translate the connection from 199.199.199.199 to
192.168.0.199 (because 199.199.199.199 doesn't really exist anywhere but
the PIX). Then the PIX would theoretically forward the packet back to the
192.168.0.199 host. That works fine up to this point. Now the
192.168.0.199 host needs to reply to the connection attempt. 192.168.0.199
looks at who to reply to - it's 192.168.0.198 - right on my local
subnet. The server will forward the packet directly to the host. We
can't legally make the server forward a packet destined locally to it's
default gateway, where the PIX would have a chance at swapping the source
address back again.
Now the problem is that 192.168.0.198 THINKS he is connecting to
199.199.199.199, and does not expect a response from 192.168.0.199. The
client resets the connection from 192.168.0.199, while still waiting for
199.199.199.199 to respond. Our client has no idea that 192.168.0.199 is
masquerading as 199.199.199.199.
PIX behaves the way it does to prevent this deadlocked situation. I like
to think of it as Lois Lane calling Superman for help, and being constantly
disappointed when Clark Kent shows up, never guessing they are the same
person.
The correct configuration is to have DNS such that the internal clients
resolve the hostname to the internal address, and external clients resolve
the hostname to the external address.
Within the PIX, you can use the ALIAS command to enable the PIX to adjust
the DNS responses accordingly. There are some upcoming enhancements in
version 5.1 which should be documented in Cisco Bug ID CSCdm62488. Please
check the release-notes and documentation for PIX 5.1 when it is available.
Hope that helps,
Lisa Napier
Product Security Incident Response Team
Cisco Systems
http://www.cisco.com/warp/public/707/sec_incident_response.shtml
At 11:42 PM 02/16/2000 -0800, Yi Liu wrote:
>I've created conduits for a Pix firewall for outside
>connections. However, connecting through the static NAT addresses will
>fail unless the inside address is used. For example:
>
>static (inside,outside) 199.199.199.199 192.168.0.199 netmask 255.255.255.255
>conduit permit tcp host 199.199.199.199 eq http any
>
>I cannot connect to 199.199.199.199 from 192.168.0.198. Does anyone know
>why? Any other connection works fine (example: 199.199.199.190 if it does
>not go through the Pix).
>
> YL
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
