On Thu, 14 Feb 2008, Dan Martin wrote:

I have a home LAN that uses a iptables firewall running on FC 4 on my gateway machine. I run Win2K on an internal LAN machine that I use to run (among other things) 2 applications that contact remote servers. Using SNAT in iptables, everything seemed to run fine, since all communications with the servers were initiated on my end and return packets were appropriately translated back.

Recently I upgraded one of the apps that accesses a broker and real time quotes. It then failed to run, and their minimal tech support could not help me get it going. The failure was blamed on my firewall. I changed it to allow some new connections from the internet (DNAT) but to no avail. I assumed that I had implemented DNAT incorrectly or there were things they weren't telling me.

This upgraded app may be using a better technique for verifying your identity. It works like this: 1) app opens TCP connection. NAT handles this correctly because you initiate the conneciton. 2) Server sends a UDP packet to a known port at your IP. The app is listening for it and completes authentication over the TCP connection from #1 using authentication (key) information sent in the UDP packet. But if your firewall stops this UDP packet the authentication cannot complete. These are tricky to diagnose unless you have iptables logging dropped packets and your firewall is set up to drop everything that is not initiated from your end. I use a rule like this to log to syslog before dropping packets. I turn it off when I'm just dropping the normal UDP chatter because I don't like to wear out my logging drive: iptables -N blocked-ext-udp # create the chain iptables -A blocked-ext-udp -j LOG --log-prefix "BLOCKED PACKET (ext-udp): " #iptables -A blocked-ext-udp -j REJECT --reject-with icmp-port-unreachable iptables -A blocked-ext-udp -j DROP Then in my chain where I've finished trying to qualify any UDP I really want to come in I put: iptables -A ext-udp -j blocked-ext-udp iptables -A ext-udp -j DROP Even though the -j DROP after the -j blocked-ext-udp is redundant, if I comment out the -j blocked-ext-udp the packet still gets dropped. Although I have my INPUT, OUTPUT, and FORWARD chain's policy set to drop, I prefer not to use it because `iptables -L -v' will show me which particular chain is dropping packets instead of just guessing from the policy. Occasionally I turn on the -j REJECT so those hapless individuals who are still trying to find my gaming server get a real port unreachable and quit thinking my gaming server is just temporarily down. It's been years since I ran it but certain server locators still ping it occassionally to see if it is up :) NOTE WELL: logging dropped packets can cause DoS on a busy machine. There is a rate limiting form of logging so only a few get logged. I don't use it as a DoS due to overlogging is just a fun "isn't that interesting" event for me but I'm just a hobbyist. It is best if you only log those packets coming from the server's IP you are trying to connect with but in some paranoid authentication schemes the UDP packet with the key you need comes from a different IP, presumably to stave off replay/man-in-the-middle attacks. The good news: when I last encountered a scheme like this I was able to add a specific rule for that source IP/port to allow the UDP packet to come in. Fairly tidy. I did have to port forward it to a specific host on the LAN since it was UDP, and not expected, my firewall didn't have a clue which LAN host should get it. So I'm restricted to only one machine that can access that level of secured information.

Yesterday, I found I was unable to run an app that accessed a second server - even though I had run it many times previously. It gave the error "Cannot connect to the ... server. Proxy connection failed: the configured proxy server is not accepting connections." Changing my firewall back to the previous version did not solve the problem.

Timing? Was their proxy just down at the time? "not accepting connections" is what some proxy respond with when they are overloaded. Squid can (and is usually) configured to only accept only a finite number of incoming connections at the same time (ie. try the proxy later).

I plugged my Win2K machine directly to the cable modem and configured it to connect by DHCP. I could not get an address for it. Shaw believes the modem is working and trying to assign an address.

This sounds like a job for the Windows version of ethereal and libpcap. Did you actually broadcast for DHCP and did shaw actually respond? I don't know enough about Shaw's modems to know what happens to a DHCP request when it goes out to one, but it sure has to respond correctly for *nix or Windows to grok the IP assigned.

I finally installed this second app into another Windows machine on the internal LAN and it ran perfectly.

Proxy server wasn't busy anymore possibly.

It shouldn't be a firewall problem - the iptables should handle one internal machine exactly the same as the other - no rules specify a particular machine except the DNAT rules, which were removed.

It is suspicious that the NIC would not configure when plugged to the cable modem - but everything else works. I can browse the web and get my mail.

I'm guessing a cable modem doesn't work like a normal TCP/IP connection. Somehow Shaw is tagging data floating around your cable node so your modem latches on to it. Likely it still sends data to you, you just don't have an IP. tcpdump would show you what IP is in the packets that are coming in.

Is this consistent with a NIC failure? could it be something else?

HTH, Daryl