ping yes; tcp no

I've been assinged a single static IP (call it EXTIP), by my provider (DNAI/Covad).  I'm using a SpeedStream 5250 bridge.  The 5250 is connected to a linux firewall/router which also performs IP masq and IP forwarding on some selected ports to a linux server behind the firewall.  All machines behind the firewall are assinged IPs in the 192.168.0. address space.  The internal interface card on the firewall has the address, and that's the default route for all the internal boxes.
I host several virtual domains on the linux server using apache's named virtual host feature.  I administer DNS for the virtual domains, also from the linux server.
From outside my network, I can both ping and request web pages from any of the virtual domains: all is well.
From inside my network, I can ping a virtual domain.  It's name resolves to $EXTIP, and all packets transmitted are received and acknowledged.  However, when I try to request a web page from a virtual domain, the connection always times out.  
At first, I though that the problem might be firewall related, but I log all denied packets, and these requests aren't in the log.
Any ideas would be appreciated.
Who is Participating?
crouchetConnect With a Mentor Commented:
Apparently you have set up a split DNS with forwarders, which is good. However, that also means that your requests for virtual domains are all being sent outside your firewall and must come back in (which is why is resolves to $EXPIT  when you ping).

So, you send a request, it goes out through the firewall, the request comes back in and gets a hit. Then the response goes back out but your firewall will not allow the response to re-enter. That is why your programs just hang waiting for that reply.

The solution is to set your firewall to allow these responses to enter.

Also, having two NICs for this sort of operation is a very good idea. They are soooo cheap, and trying to do both the internal and external stuff on the same NIC is confusing at best and probably unstable.

Can you post the /etc/hosts.allow and /etc/hosts.deny files?  

In httpd.conf, do you have HostnameLookups turned on?  I wonder if Apache is choking on your probably-unnamed 192.168.0.x hosts.

Did you find anything interesting in /var/log/httpd/access_log or error_log?

Have you considered adding a virtual domain in the 192.168.0.x subnet, just to see if the local machines could get to it?

Does telnet, ftp or any other tcp protocol work?  If so, we can narrow down the problem to Apache, otherwise we have more possibilities.
gookinAuthor Commented:
I was using http as an example.  Sadly, the problem is not limited to only http, but all IP layer traffic.  Ssh also fails, as does dns (both UDP and TCP), etc.

To clarify:

I can access the server by its address without difficulty.  The problem seems to arise when I use a virtual name.  DNS resolves to the external IP, and the request inevitably times out.

I remember reading somewhere that it is illegal behaviour for a packet to exit via the same interface it entered.  If this is the case, it would perhaps explain things, since my vague recollection using tcpdump was that the tcp/udp packets headed out the firewall's internal interface (their default gateway), and then disappeared in the firewall.  The proper behavior should have been to return via the same interface, heading for the server, but they never get that far (perhaps lost in some obscure port forwarding conflict).  

I don't understand, though, why ICMP works but IP does not.  

Thing is, this used to work fine with my other DSL setup, where instead of a bridge, I had a Flowpoint router.

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Does the Linux box have one Ethernet card or two?   If you don't have two,  I strongly suggest it.  

Is IP packet forwarding enabled?

If you "cheat" on the internal machines and set up the hosts file to resolve everything as, does that work?   Not everyone know this, but even Win95 will recogize a hosts file (in the Windows directory).
Please post the results of the ifconfig and route -n commands.  I wonder if you need a static route for the $EXTIP address specifically:

route add $EXTIP netmask <interface that EXTIP is on>

On your default route from Linux, try using no gateway IP:

route del default
route add default netmask <interface that EXTIP is on>

I could be more specific if I knew the specific details from ifconfig and route -n
gookinAuthor Commented:

What do you mean by "split DNS with forwarders"?  My DNS configuration seems pretty standard.  It services all the internal boxen as well as the virtual domains.  At one point, I did have it set up to emit two IP addresses for the virtual hosts (both $EXTIP and the IP of the linux server).  This works fine unless an external machine making a DNS lookup also happens to be on a 192.168.0. network, at which point their DNS seems to prefer the IP address to the $EXTIP, and cannot correctly make the request.

If there were a way to use BIND to selectively send different IP addresses depending on the address of the requestor (so that the internal machines get a 192.168.0. address and all external machines get $EXTIP), that would also solve this problem.

Anyone know how to do that?

BTW, the linux firewall does indeed have 2 interfaces (I didn't realize it was even possible to use only one for a router)
Ok, after re-reading I realize you are describing a full DNS which is (I assume) authoratative for your system and the virtual domains you host. I guess you need to reject my answer and let someone else have a shot at it. Still, here are a few additional thoughts.

I went through the route and came to the same conclusion you did, that it must the the packet filtering. However if you have checked the logs and these are not denied then that can't be it.

Do you know if your ports are being hit when the request is made (e.g. port 80 for http request)? If so then you know the problem must be in the final incomming section. However, I take it from what you wrote about tcpdump that is not the case.

The change you made was from a router to a bridge. A router routes things and a bridge does not, so is it possible that those packets are actually physically being sent out and not coming back? Could it be that the router was polite and returned your packets to you but the bridge just sends them on? Again, I don't really know the physical layer so this is just a guess.

J Crouchet
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.