Routing AOL traffic

[shaunole]

forgive my ignorance as I'm new to gentoo and I'm learning by starting with a home router.

I have a home network set up with a vista machine, linux laptop both connecting through a linksys WRT54G (running as a gateway) router. The linksys gateway is connected to the gentoo router, and of course the gentoo router is connected directly to the cable modem.

Well, I've got dhcp, PowerDNS, iptables and moblock running successfully and general website browsing works well.

Users of the vista machine have been attempting to connect to AOL desktop and it's not recognizing the internet connection.

Within moblock, I've whitelisted both TCP/UDP for the following ports, which I understand to be dedicated to AOL, 5191 5192 5193. II've also whitelisted port forwarding for those ports.

I keep adding rules to iptables to try to remedy the issue, but now I have a bunch of rules that are most likely not needed and I'm possibly missing some that are needed. Here's my iptables rules list:

# Generated by iptables-save v1.4.0 on Sat Sep 6 16:42:37 2008
*raw
:PREROUTING ACCEPT [3223012:1494051451]
:OUTPUT ACCEPT [1232446:361721685]
COMMIT
# Completed on Sat Sep 6 16:42:37 2008
# Generated by iptables-save v1.4.0 on Sat Sep 6 16:42:37 2008
*nat
:PREROUTING ACCEPT [414214:139914697]
:POSTROUTING ACCEPT [2607:763021]
:OUTPUT ACCEPT [49785:3835390]
[97522:5928903] -A POSTROUTING -o eth1 -j MASQUERADE
COMMIT
# Completed on Sat Sep 6 16:42:37 2008
# Generated by iptables-save v1.4.0 on Sat Sep 6 16:42:37 2008
*mangle
:PREROUTING ACCEPT [3223012:1494051451]
:INPUT ACCEPT [1421400:393113264]
:FORWARD ACCEPT [1583162:995957333]
:OUTPUT ACCEPT [1232446:361721685]
:POSTROUTING ACCEPT [2811440:1357442459]
COMMIT
# Completed on Sat Sep 6 16:42:37 2008
# Generated by iptables-save v1.4.0 on Sat Sep 6 16:42:37 2008
*filter
:INPUT ACCEPT [82670:24065458]
:FORWARD ACCEPT [1569091:995131915]
:OUTPUT ACCEPT [1196140:357285775]
[286:22138] -A INPUT -s 127.0.0.1/32 -j ACCEPT
[1126106:303889975] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[9874:592236] -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 20 -j ACCEPT
[18:996] -A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
[62:2656] -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 137:139 -j ACCEPT
[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 426 -j ACCEPT
[0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 445 -j ACCEPT
[158:7584] -A INPUT -p tcp -m state --state NEW -m tcp --dport 6881:6886 -j ACCEPT
[2180:145721] -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT
[0:0] -A INPUT -i eth0 -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT
[10:400] -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
[10:560] -A INPUT -p udp -m udp --dport 53 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 953 -j ACCEPT
[0:0] -A INPUT -i eth0 -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT
[0:0] -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT
[0:0] -A INPUT -i eth1 -p udp -m udp --dport 53 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 53 -m iprange --src-range 192.168.2.1-192.168.2.200 -j ACCEPT
[0:0] -A INPUT -p udp -m udp --dport 53 -m iprange --src-range 192.168.2.1-192.168.2.200 -j ACCEPT
[0:0] -A INPUT -i eth0 -p udp -m udp --dport 53 -m iprange --src-range 192.168.2.1-192.168.2.200 -j ACCEPT
[0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 53 -m iprange --src-range 192.168.2.1-192.168.2.200 -j ACCEPT
[278:17071] -A INPUT -i eth0 -p tcp -m tcp --dport 4080 -j ACCEPT
[0:0] -A OUTPUT -o eth0 -p udp -m udp --sport 1024:65535 --dport 53 -j ACCEPT
[0:0] -A OUTPUT -o eth0 -p udp -m udp --sport 1024:65535 --dport 53 -j ACCEPT
[0:0] -A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
[0:0] -A OUTPUT -o eth0 -p tcp -m tcp --dport 4080 -j ACCEPT
COMMIT
# Completed on Sat Sep 6 16:42:37 2008

I'm not sure that I'm even approaching this from the right direction. again, I appreciate the help.

[Hu]

You are definitely going about this wrong. You are intentionally trying to make AOL related software work.

Posting the iptables-save output is a good first step. To continue with this, we need to know what the AOL software is doing to make it think that there is no network connection. Please emerge net-analyzer/tcpdump, run tcpdump -i LAN_INTERFACE -w /tmp/lan.pcap -p, run tcpdump -i WAN_INTERFACE -w /tmp/wan.pcap -p, and start the AOL software. Once it reports an error, interrupt the tcpdump processes. Since we do not know exactly what AOL is trying to send, we need to capture everything and sort it out after the fact. Thus, it would be helpful to halt all unnecessary network traffic while tcpdump is running. After you have those capture files, check that any AOL related traffic that appears on the internal interface also appears on the external interface, that it has been properly masqueraded, and whether any response is returned by AOL.

As a separate item, not related to your immediate problem, your iptables rules could use some tweaking. You are allowing all systems to attempt to connect to services that you typically do not want to expose externally.

• You are matching on the IP address of the loopback interface instead of its name. Using lo is preferred, since it properly allows loopback connections without regard to the IP address entered.
  
• If you do not intend to ssh into your Gentoo machine from the Internet, remove the rule for port 22.
  
• Remove 20/21 if you are not hosting a public ftp site.
  
• Remove 80/443 if you are not running an HTTP server on your machine.
  
• Remove 137:139 regardless. No one should be using Windows filesharing protocols over the Internet.
  
• Your rule -i eth0 -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT does not appear to be useful, and is present twice. It is written to allow systems running DNS servers to send to you, but that intent is better served by your connection tracking rules.
  
• You allow Internet facing systems to access DNS on your machine. I doubt you want this.
  
• Even worse, you appear to be allowing access to a port described as "rndc control sockets (BIND 9)".
  
• You have redundant rules that reiterate granting DNS access to external hosts several times in different ways.
  
• You have rules for OUTPUT to ACCEPT specific ports, but then you have a default policy to ACCEPT anyway.