Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My original question was here: PAT users can't access website, but NAT users can?

I got a static IP now and just assumed it worked because i got no response after it was enabled, but then i was told yesterday that the client is still not accessing the website. The client is not able to change their networking settings due to corporate policy so I'm wondering if there is anything I can do on my side.

Now using NAT, everything connects fine. I was told by their IT guy that it connects to our static IP address twice and then our website tries to connect back on a random port. Then it connects to two other IP addresses belonging to Google (for web ranking) and then the website loads.

When using PAT, they connect to our static IP address twice, but nothing happens. When our website connects back their firewall drops it.

I have no idea if having the website trying to connect back is normal or not. Actually, i don't even know what is going on at all. I'm not a networking guy. I'm just in charge of the website.

share|improve this question
Do you know what he means by "connect back"? Does that mean a packet being sent back (like an ACK or similar); or perhaps it's a completely different connection (doubtful)? – Chris S Nov 15 '10 at 19:18
He is saying his firewall is seeing replies on totally different ports, and that traffic is being dropped. – alex Nov 15 '10 at 21:27

In your position, after clearing the idea with both parties, I would set up a conference call involving you, the client's IT guy and your hosting provider's technical support staff. I would encourage the other two to discuss the details and expect them to jointly arrive at a solution or identify concrete steps to identify the cause.

OK if you cant get the client to talk to the hosting service, you'll have to get a clear understanding of the technical details of the problem.

NAT is Network Address Translation, it is a very common way of dealing with the shortage of IPV4 addresses. Before NAT, every computer in every organisation connected to the Internet had to have a globally unique IP-address. NAT is performed in a router to hide your internal addresses behind a different public addresses. That way, a business with 10,000 computers might only need one public IP-address instead of 10,000. Normally nowadays, internal addresses are chosen from a group of IPV4 addresses reserved for private use.

So my PC might have an internal address of and your web-server might have an internal address of as well. NAT makes it possible for these computers to talk to one another. Your public DNS for does not give it's internal address, it gives the public IP-address of your router, let's say

So when I type into a web browser it sends a TCP packet that looks a bit like this

From= To= Payload="GET / HTTP/1.0"

Where 5432 is a port my PC chose at random. My router changes that to

From= To= Payload="GET / HTTP/1.0"

Where is my router's public IPV4 address. This is Network Address Translation (NAT). 6789 is a port number it allocates (it may already be using 5432 for some other guy's connection) this is Port Address Translation (PAT). The router records this translation in memory for later recall.

Your hosting service router at receives the packet and looks at the port number 80 to decide which internal computer to pass the packet onto. This is port forwarding. So on the hosting service LAN the packet is changed to

From= To= Payload="GET / HTTP/1.0"

The web-server receives this. It replies to When that reply gets to my router it uses the port number in the target address to lookup the source of the original connection - my My router alters the destination address accordingly and forwards the packet into my LAN.

I cannot see how this can be going wrong. But you can see that the port numbers are vital in making it all work.

share|improve this answer
I'm agreeing with Red at this point. There's no good reason this isn't working, and it certainly sounds like the problem is in the client's network (though it's remotely possible the problem is with your host). – Chris S Nov 15 '10 at 21:39
Yeah, that's not going to happen. I was told that our client is not going to change anything with their networking just to get some website working. I'm just the guy in the middle told to "fix it" by my superior. Our hosting provider doesn't see an issue so they're just speculating what could be the solution. I don't know if it helps, but I was told the Google cache of the website doesn't pull up either. – alex Nov 16 '10 at 23:25
See edits above – RedGrittyBrick Nov 17 '10 at 10:44
Thanks. Turns out the simplest solution was the one. Apparently our client just happened to have an IP address that was on our hosting provider's blacklist. The NAT IP used by the client was different than the PAT address (this was on the blacklist) which is why NAT worked, but PAT didn't. – alex Nov 17 '10 at 21:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.