02-10-2005 06:32 AM - edited 03-09-2019 10:17 AM
I have a customer that wishes to permit access from subnet 172.30.0.0 255.254.0.0 on the 3rd_party segment to a web server 192.168.1.121 on the DMZ segment . The customers applications have a destination IP address of 192.168.254.13 and we have configured DNaT to amend this to 192.168.1.121 . The PIX is running ver 5.3.3 , we can ping and traceroute end to end and also map virtual drives from host to host but when the customers browse to host 192.168.1.121 we see "error code 400" issued . When we debug packets on the DMZ we see "normal" packets with a destination address 192.168.1.121 socket 0x50 (80) I have attached the current wr term from the PIX
Many Thanks
Mike
02-15-2005 12:55 PM
The config of the PIX seems fine, and the fact that traffic is possible between the desired endpoints indicates NAT is happening as it should. This sounds more like a name resolution issue. Some web servers insist on being able to resolve incoming addresses to a name, so it's possible the DMZ server just can't resolve the 172.30 addresses and that's causing the problem. It's usually possible on most systems to just put an entry in the appropriate "hosts" file as test. So, if you have a user at 172.30.x.y who can do some testing for you, put an entry in the local "hosts" file that assigns a name to that 172.30.x.y address (it doesn't matter what the name is). If that fixes the problem for that user, then you know you have a name resolution issue and you can then pursue the appropriate fix (e.g. DNS, WINS, etc.). If it doesn't fix the problem, then you need to keep looking for the cause, but at least you know one thing that it isn't.
Good luck!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide