Client-Server VPN not able to see Inside network

Upgrading to 6.3(4) or 6.3(5) would be better. 6.3(4) fixes some security problems, and 6.3(5) has a number of bug fixes.

That line is not needed, as you have the ftp fixup turned on.

You usually want to restrict the icmp that are allowed inward, as some of them (e.g., icmp redirect) can be used to attack security. You need icmp unreachable and icmp time-exceeded, and icmp echo-reply is convenient. Everything else should be looked at closely.

That line is not useful. You cannot connect from "outside" to any other interface, not unless you have a "management" tunnel set up, which you do not have.

That line is not useful. Any traffic from outside that has a source address of your interface IP address is going to be a forged packet or a packet that routing has gone out and been routed back to the PIX; PIX 6 will always drop packets that go out and are routed back to the PIX.

We cannot be sure based upon what you have posted, but that line would appear to be redundant considering the earlier icmp line.

You permit new connections (on port 3389) in to this IP, but you do not permit new connections out from this IP, not even DNS resolution. This situation is possible, but unusual and should be re-checked.

These too are permitted incoming connections but not outgoing, which should be rechecked.

But you have a bigger problem here: it is not valid to static two different IPs to the same IP. You probably want to do static port forwarding for at least one of these.

This too is allowed incoming traffic but not outgoing. But again there are other problems, as you appear to be static'ing the same outside address, x.x.x.x7, to two different inside addresses,

There are reasons to prefer identity hostname when using dynamic maps, if the connecting hosts might change public IPs while a tunnel is active (e.g., they get a different DHCP address during the middle of a connection.)

That is not invalid, but I think you will find that in practice real DES MD5 hosts are going to use Group 1 and seldom Group 2. It would be very uncommon to encounter a host or device that refused Group 1 for DES MD5. Your Group 1 entry has the lower policy number, and therefor has higher priority than your Group 2 entry, so the arrangement you have now is NOT "Use Group 2 (more secure) if the other end supports it, and otherwise use Group 1 (less secure)". Reverse the group numbers on the entries if that was the policy you intended.

You have three types of VPN tunnel configured, and if you were using a sufficiently new Windows (XP SP2), or had specifically downloaded the updated MS VPN software for W2K, then your user's "MS's connection" might use either the IPSec dynamic connection or the PPTP; older MS software would not have the IPSec option.

If it is PPTP that you are using, then you should be aware that there have been a couple of different people reporting within the last couple of months that they are seeing PPTP in which the source IP address was the public IP of the connecting system, rather than the IP address that had been allocated by the pool. I note that you have syslog to an inside host and that you are already logging at 'debug' level: have a look through the logs and see whether you are getting some rejected packets with a 192.168.128/24 destination and a public source instead of the expected 10.99.99/24 source.

I have not seen any solutions yet to this PPTP issue. I know that a lot of people have PPTP set up to their PIX, so it has to be a fairly subtle problem. Hmmm, if I recall correctly, those posters were using the Cisco VPN client, but as we don't know what the problem was, it might or might not be the same as you are encountering... check those logs.

This was done not by me. Basically its websites that are located on one inside webserver. How might I change that to allow both those address in on port 80 to the same internal IP then?

This was setup for a box on the inside of the network to monitor the PIX itself and the router on the the outside of the network. As well as allow someone to SSH to that box if needed. Thats what I was told anyway.

This access-list acl-out permit tcp any host x.x.x.25 eq 3389 is the outside address that someone will Terminal into it then has a static to static (inside,outside) x.x.x.25 192.168.128.25 netmask 255.255.255.255 0 0 and access-list acl-in permit ip host 192.168.128.25 any lets all back out.

Might not be right though. I admit that.

My logging server is gone. (had to realocate it for something else) so I need to setup logs somewhere else or I need to just turn logging on locally. Which I need to remember how to do.

Not sure my client is upto date 100%. I know its WinXP with SP2.

You cannot do that with PIX 6 (and probably not with PIX 7 either.) You would need to translate them to different ports on the same server and have your web server listen on both ports. Or put up two different web servers on different internal IPs. Or change the DNS for the web servers to both have the same IP and rely upon the Host: header to differentiate between them (if so then pay a bit of attention to which site will be reached if there is no Host: header such as from a very old web client or from a telnet session from some admin trying to figure out what sites the users are going to.)

You do not need to "let all back out": the PIX automatically creates appropriate holes in the rules for return traffic. Permitting outward access from a host should only be used if the host needs to initiate connections to outside, such as to a DNS server or to send outgoing email (SMTP). Also, if you happen to have incoming UDP connections where there might not be traffic on the connection for more than 2 minutes, then you either need to raise the udp timeout or else you need to permit the return traffic outwards explicitly, as by default the PIX closes the automatic loophole for return UDP traffic after

logging buffered debug

then show log

but this tends to fill up and get overwritten quickly, so unless you have very low volume, it is a lot easier to debug with a syslog server.

Things here seem to be working fine, but I can change it. I'll look at changing the IP address on the DNS server for the website. In the mean time how would I route the differnt port on the same IP inside?

With my Configuration what do I need to change then? If you want to talk off list so you can see the IP's we can. I don't have any issues with anything right now, but I'm willing to make it work the way its suppossed to.

I'll see if I can get some logs.