On Wednesday 12 February 2003 10:44 pm, Tom Eastep wrote: <snip> > Here is the connection tracking table: > > udp 17 177 src=192.168.1.1 dst=12.77.140.250 sport=1347 dport=1193 > src=12.77.140.250 dst=12.243.227.207 sport=1193 dport=1347 [ASSURED] use=1 > udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1348 dport=1039 > src=12.77.140.250 dst=12.243.227.207 sport=1039 dport=1348 [ASSURED] use=1 > udp 17 18 src=10.175.0.1 dst=255.255.255.255 sport=67 dport=68 > [UNREPLIED] src=255.255.255.255 dst=10.175.0.1 sport=68 dport=67 use=1 > udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1037 dport=1194 > src=12.77.140.250 dst=12.243.227.207 sport=1194 dport=1037 [ASSURED] use=1 > udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1349 dport=1040 > src=12.77.140.250 dst=12.243.227.207 sport=1040 dport=1349 [ASSURED] use=1 > tcp 6 431989 ESTABLISHED src=192.168.1.1 dst=216.187.103.211 > sport=1304 dport=5501 src=216.187.103.211 dst=12.243.227.207 sport=5501 > dport=1304 [ASSURED] use=1 > udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1038 dport=1195 > src=12.77.140.250 dst=12.243.227.207 sport=1195 dport=1038 [ASSURED] use=1 > > The ICMP 11,0 packets in the log are explained by the third entry which > suggests that the culprit is a DHCP client using an RFC 1918 source > address. > > 216.187.103.211 is "chat.eyeball.com" - the EyeBall Chat server. Sean's IP > address is 12.243.227.207 and 12.77.140.250 is Mom's IP address. > > So: > > a) The "Magic Technology" worked without any races on Sean's end (we didn't > see any denied packets). > b) The 5 UDP connections between Sean and Mom are as described in the > EyeBall documentation. > > c) Sean -- is the AOL subscriber that you mention able to connect with > EyeBall users other than yourself?
I think most, if not all, of AOL services are proxy'ed and likely VPN'ed as well the last time I looked. I know a lot of services are not working as advertised on AOL, especially when the connection is to the internet at-large. Maybe their proxy messes this up. > I would still like to get your tcpdump capture Sean to see if Ray's > conjecture is correct. I would to. It would be quite interesting to see how the connection is setup initally w/o port-fw'ing. It's not breaking in the NAT ports, so this must be application specific, especially with use of TCP . Very interesting! ;-) Thanks, -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
