[RndTbl] network problem

[Daryl Fonseca-Holt]

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