Destination Host Unreachable

After installing the cable providers modem I had to change it to Bridge mode, so my AEBS would handle all the NAT and port and firewall stuff together with SERVER.

It is much more common to use the ISP's devices to provide DHCP (NAT) and provide the FireWall. Then your AEBS in Bridge mode provides the actual WiFi Access point.

What is required for advanced Server to work is correct forward and reverse lookup of your Fully Qualified Domain Name <--> IP Address of your Server.

Inside your network, it can look up to a "private" IP Address in one of the range of 192.168.xxx.yyy, 176.xxx.yyy.zzz, or 10.xxx.yyy.zzz ranges. If this does not already work automatically, you need to set up a DNS Server somewhere inside your Network, or use the ISP's DNS and Port Forwarding to go outside and back in again.

Outside your Network, your ISP needs to provide a mapping to your Router's IP Address, and you use Port forwarding to forward to the Manual, fixed IP Address of your Server. Or you need to buy a DNS mapping from somebody, because the Internet cannot see the private IP Addrsses inside your Network. Do you have an Internet-visible Fully Qualified Domain Name that uniquely identifies your Network?

Grant Bennet-Alder wrote:

After installing the cable providers modem I had to change it to Bridge mode, so my AEBS would handle all the NAT and port and firewall stuff together with SERVER.

It is much more common to use the ISP's devices to provide DHCP (NAT) and provide the FireWall. Then your AEBS in Bridge mode provides the actual WiFi Access point.

I usually use the ISP modem in its bridged setting, my own firewall doing NAT (preferably with an embedded VPN server), then AirPort or Time Capsule providing Access Point (bridged) access to the private network.

Inside your network, it can look up to a "private" IP Address in one of the range of 192.168.xxx.yyy, 176.xxx.yyy.zzz, or 10.xxx.yyy.zzz ranges. If this does not already work automatically, you need to set up a DNS Server somewhere inside your Network, or use the ISP's DNS and Port Forwarding to go outside and back in again.

Ayup. To elaborate on that, 192.168.0.0/16, 172.16.0.0/12 (that's also 172 and not 176, too), or 10.0.0.0/8, and preferably not in a subnet in one of the private blocks that is likely to be used elsewhere, as VPNs don't work well when the same IP subnet is in use on both ends of the connection.

FWIW, it's not usually correct to have public IP addresses behind NAT. (Do you have a block of public static IP addresses?)

If the external IP address is referenced from within the NAT'd network, the device performing NAT will have to reflect it back into the network. Or your local DNS configuration will be split-horizon or split-brain; configured as authoritative for the same DNS name(s) you're using in the public DNS services — split-horizon DNS can have its own configuration and management hassles — and translate the domain name to the local address. Otherwise — my usual recommendation — you use a subdomain of your registered domain or a separate domain you've registered or (less desirably) a bogus domain.

But if you're not getting the traffic sent to the external address to the target server, then either your local IP routing is misconfigured (and unless you have a block of public IP addresses, it's unusual to use public addresses on a private network — NAT is the usual solution, or sometimes using IPv6 if your ISP is clueful or if you set up a tunnel), or the device performing NAT is not reflecting the traffic back into the network (I haven't used AirPort or TC for this), or the device performing NAT is reflecting the traffic somewhere that's not getting a response — see if the traffic is getting to the target based on the log files on the server, is but not making it back to the client.

Pierre Froelicher1 wrote:

Mr Hoffmann, Grant,

Thanks for you excellent suggestions.

I do not want to use the ISP's modem because I run SERVER and it works well together with the AEBS.

After much pondering I phone my ISP provider NET and they sent me a more or less qualified person, who, after checking which hosts where open, confirmed that my setting with bridge mode and fixed IP on the AEBS should just work fine. After some testing he came to the conclusion that "they" forgot to register my modem as a fixed IP modem. Now "nearly" everything works. My site is up and running. However!!!! The problem that I cannot access the site from my home, only from there!! still persists.

I'd check with the ISP and find out of the routing has been updated — switching to a static address usually means the firewall has been moved out of the DHCP pool that is used for dynamic-assigned addresses, and there are associated routing changes with this change. These include different gateway router address associated with the new IP address within the firewall — these network settings can be statically assigned by you or can be provided by DHCP — yes, you can get static addresses via DHCP — depending on the ISP.

Confirm that your external static IP address is as correct, including as configured on your AEBS, if you're using that as your firewall.

The times I've worked on something similar, it's either been an incorrect setting within the local firewall (wrong public IP address, wrong next-hop router in the firewall, wrong subnet, etc), or an ISP routing configuration issue. The ISP routing cases generally either clear up after a half day or so, or take a call to the ISP to resolve.

I prefer running a server-grade firewall, so it's usually something like:

• ISP modem configured as a bridge >
• firewall configured with VPNs and NAT >
• switch >
• your internal network: AEBS configured as an access point, server, printer, whatever

If it's within budget, a firewall-based DMZ can partition the server from the rest of the internal network, which can isolate breaches when the firewall and the DMZ are configured securely.

If the target host is 201.6.116.2 as it appears, then you're apparently getting to the target IP. Next step involves confirming the IP return path from the device (that's the gateway router setting in your gateway box — the "next hop" that's used for returning IP packets) though you're clearly getting ICMP requests back, and also probing for a firewall block; using telnet or another client to probe specific and confirmed, known-open ports. For a few of these cases, I've ended up connecting a "scratch" box directly to the network (assuming the connection is bridged), to get the gateway-router-firewall box out of the way.

The reverse DNS is incorrect, but that won't adversely affect IP routing.