Date: Sat, 08 Apr 2000 11:40:21 -0400 (EDT) From: Mike Heffner <mheffner@mailandnews.com> To: cjclark@home.com, FreeBSD-ipfw <FreeBSD-ipfw@freebsd.org> Subject: Re: Problems with natd Message-ID: <XFMail.20000408114021.mheffner@mailandnews.com> In-Reply-To: <20000408014522.B8928@cc942873-a.ewndsr1.nj.home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ re-added -ipfw ] On 08-Apr-2000 Crist J. Clark wrote: | | I'm going crazy. Me too! ;) | | I've been dissecting individual packets for the last two | hours... unwrap the TCP from the IP from the Ethernet... and I think | I've had enough for now. | | But I'm getting ahead of myself. It looks like your packets all get | here, but my machine decides to stop responding to them. Here is a | successfully initiated telnet followed by an unsuccessful, | [ packets snipped to hide addresses ] | | When I diff the packets, the only things changing are sequence numbers, | ids, and checksums. I can't figure out why my, and aparently others | too, will not respond to the second one. | | I was about to start checking the cksums by hand, but that is the path | to insanity. Attached are the raw tcpdump'ed data. Well, I have done some rewiring of my network so that I can test it on my home network, and yes the problem is still occuring. My setup is simple, I have the box (I'll call it A) that was giving me problems connected to the same segment as another box (B). When I have a completely open firewall on A, *without* natd, I can successfully telnet, ftp, etc into B. When I start natd and add the divert rule, I can not telnet, ftp, etc into B. Now the strange part, as you mentioned, the packets are going out on the wire when running natd and they are arriving at B, and they are being read/accepted by B as viewed by netstat, and no, they aren't being dropped at all. Box B just does not respond at all to the packets when natd is running on A. I've spent several hours trying to pick apart the packets, and so far I cannot see anything that is significantly different between them. At first I thought maybe the checksum was bad in the TCP header, but I don't think it's that, since they don't seem to be dropped. I plan to spend several hours tonight and basically backtrace the packet from inetd and through the kernel. Hopefully I'll be able to tell where it's being lost. Below are the packet dumps of testing on my home network ( all the tests were an attempted telnet from A to B). Is there something simple here that I'm not seeing? 10.0.0.1 == A 10.0.0.2 == B Dump on A of an unsuccessfull attempt: 02:00:14.274828 10.0.0.1.1036 > 10.0.0.2.23: S 336217990:336217990(0) win 16384 <mss 1460> (DF) [tos 0x10] 0x0000 4510 002c 0336 4000 4006 2384 0a00 0001 E..,.6@.@.#..... 0x0010 0a00 0002 040c 0017 140a 4786 0000 0000 ..........G..... 0x0020 6002 4000 1421 0000 0204 05b4 `.@..!...... 02:00:17.274087 10.0.0.1.1036 > 10.0.0.2.23: S 336217990:336217990(0) win 16384 <mss 1460> (DF) [tos 0x10] 0x0000 4510 002c 0337 4000 4006 2383 0a00 0001 E..,.7@.@.#..... 0x0010 0a00 0002 040c 0017 140a 4786 0000 0000 ..........G..... 0x0020 6002 4000 1421 0000 0204 05b4 `.@..!...... 02:00:23.274233 10.0.0.1.1036 > 10.0.0.2.23: S 336217990:336217990(0) win 16384 <mss 1460> (DF) [tos 0x10] 0x0000 4510 002c 0338 4000 4006 2382 0a00 0001 E..,.8@.@.#..... 0x0010 0a00 0002 040c 0017 140a 4786 0000 0000 ..........G..... 0x0020 6002 4000 1421 0000 0204 05b4 `.@..!...... Dump on B of same packets above : 02:02:14.803644 10.0.0.1.1036 > 10.0.0.2.23: S 336217990:336217990(0) win 16384 <mss 1460> (DF) [tos 0x10] 0x0000 4510 002c 0336 4000 4006 2384 0a00 0001 E..,.6@.@.#..... 0x0010 0a00 0002 040c 0017 140a 4786 0000 0000 ..........G..... 0x0020 6002 4000 1421 0000 0204 05b4 fc24 `.@..!.......$ 02:02:17.803411 10.0.0.1.1036 > 10.0.0.2.23: S 336217990:336217990(0) win 16384 <mss 1460> (DF) [tos 0x10] 0x0000 4510 002c 0337 4000 4006 2383 0a00 0001 E..,.7@.@.#..... 0x0010 0a00 0002 040c 0017 140a 4786 0000 0000 ..........G..... 0x0020 6002 4000 1421 0000 0204 05b4 fc22 `.@..!......." 02:02:23.804566 10.0.0.1.1036 > 10.0.0.2.23: S 336217990:336217990(0) win 16384 <mss 1460> (DF) [tos 0x10] 0x0000 4510 002c 0338 4000 4006 2382 0a00 0001 E..,.8@.@.#..... 0x0010 0a00 0002 040c 0017 140a 4786 0000 0000 ..........G..... 0x0020 6002 4000 1421 0000 0204 05b4 fc24 `.@..!.......$ Dump on A of succesfull attempt (natd not running): (first two packets in negotiation) 02:01:38.215986 10.0.0.1.1037 > 10.0.0.2.23: S 352566635:352566635(0) win 16384 <mss 1460> (DF) [tos 0x10] 0x0000 4510 002c 0362 4000 4006 2358 0a00 0001 E..,.b@.@.#X.... 0x0010 0a00 0002 040d 0017 1503 bd6b 0000 0000 ...........k.... 0x0020 6002 4000 6d91 0000 0204 05b4 `.@.m....... 02:01:38.216357 10.0.0.2.23 > 10.0.0.1.1037: S 2686710328:2686710328(0) ack 352566636 win 17520 <mss 1460> (DF) 0x0000 4500 002c 4535 4000 4006 e194 0a00 0002 E..,E5@.@....... 0x0010 0a00 0001 0017 040d a023 f238 1503 bd6c .........#.8...l 0x0020 6012 4470 d6b3 0000 0204 05b4 0100 `.Dp.......... Dump on B of same two packets above: 02:03:38.758954 10.0.0.1.1037 > 10.0.0.2.23: S 352566635:352566635(0) win 16384 <mss 1460> (DF) [tos 0x10] 0x0000 4510 002c 0362 4000 4006 2358 0a00 0001 E..,.b@.@.#X.... 0x0010 0a00 0002 040d 0017 1503 bd6b 0000 0000 ...........k.... 0x0020 6002 4000 6d91 0000 0204 05b4 fc22 `.@.m........" 02:03:38.759083 10.0.0.2.23 > 10.0.0.1.1037: S 2686710328:2686710328(0) ack 352566636 win 17520 <mss 1460> (DF) 0x0000 4500 002c 4535 4000 4006 e194 0a00 0002 E..,E5@.@....... 0x0010 0a00 0001 0017 040d a023 f238 1503 bd6c .........#.8...l 0x0020 6012 4470 d6b3 0000 0204 05b4 `.Dp........ /**************************************** * Mike Heffner <spock@techfour.net> * * Fredericksburg, VA ICQ# 882073 * * Sent at: 08-Apr-2000 -- 11:12:12 EST * * http://my.ispchannel.com/~mheffner * ****************************************/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20000408114021.mheffner>