[RndTbl] network problem
Daryl Fonseca-Holt
daryl at prairieturtle.ca
Thu Feb 14 23:33:55 CST 2008
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
More information about the Roundtable
mailing list