Date: Mon, 31 Jan 2000 23:47:50 -0500 From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: John <papalia@udel.edu> Cc: Ruslan Ermilov <ru@ucb.crimea.ua>, zimon@iki.fi, freebsd-questions@freebsd.org Subject: Re: NATD/Divert broken ? Message-ID: <20000131234750.E31346@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <4.1.20000131123443.00975da0@mail.udel.edu>; from papalia@udel.edu on Mon, Jan 31, 2000 at 02:23:34PM -0500 References: <4.1.20000131120328.009749c0@mail.udel.edu> <4.1.20000131120328.009749c0@mail.udel.edu> <20000131193116.A72155@relay.ucb.crimea.ua> <4.1.20000131123443.00975da0@mail.udel.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 31, 2000 at 02:23:34PM -0500, John wrote: > >> Hey all, > >> > >> I'm having a small problem with my NATD and my firewall. Per the > >> instructions in "The Complete FreeBSD", I added the firewall rule: > >> > >> divert natd ip from any to any via fxp1 > >> > >> The problem is that this rule is causing partial problems on my loopback > >> device (lo0). > >> > >> What happens is that with the rule in place, for some connections within > >> the box (which definitely go thru lo0), the connections fail. If I remove > >> that rule, then the connections within the box can be made, but then I lose > >> all ability to host my internal 192.168. net. > >> > >> I have done tcpdumps of both the successful and unsuccessful connections > >> and have pasted them below. If the actual tcpdump files would be useful, I > >> can attach those to a subsequent email. > >> > >> Also, I'm currently running 3.3 and am suffering from NO other apparent > >> problems with lo0 that I can tell. > >> > >> tcpdumps are below. > >> > >> Thanks in advance, > >> John > >> > > > >> ****** > >> Failed connection, with divert rule in place: > >> ****** > >> > >> 12:01:10.744362 merlin.wondermutt.net.3482 > merlin.wondermutt.net.39536: S > >> 1027967984:1027967984(0) win 16384 <mss 16344,nop,wscale 0,nop,no > >> > >[...] > >Can you show me the above in numerical form (with -n), with the output of > >the following commands: > > Sure can :) > > tcpdump read in numerical form: > > 12:46:10.236727 128.175.75.157.3504 > 128.175.75.157.44540: S > 1546226005:1546226005(0) win 16384 <mss 16344,nop,wscale 0,nop,nop,timestamp 10 > 05956 0> (DF) > > 12:46:12.832052 128.175.75.157.3504 > 128.175.75.157.44540: S > 1546226005:1546226005(0) win 16384 <mss 16344,nop,wscale 0,nop,nop,timestamp 10 > 05961 0> (DF) > > 12:46:18.832277 128.175.75.157.3504 > 128.175.75.157.44540: S > 1546226005:1546226005(0) win 16384 <mss 16344,nop,wscale 0,nop,nop,timestamp 10 > 05973 0> (DF) > > >* ifconfig -au inet > > merlin# ifconfig -au inet > fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > inet 128.175.75.157 netmask 0xffffff00 broadcast 128.175.75.255 > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 > Is that _really_ how it looks? If so, your loopback is misconfigured, or should I say it is not configured at all. This makes me wonder about the tcpdump(8) output you showed. What interface was that from? Was it the loopback where those packets should have been going? Notice this: > merlin# netstat -arn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire [snip] > 127 lo0 USc 3 995 lo0 > 127.0.0.1 lo0 UHW 1 5510 lo0 [snip] > 128.175.75.157 lo0 UHS 0 168 lo0 [snip] These never actually lead anywhere. I don't think a device should ever be a gateway. Mine look like, 24.2.89.207 0:90:27:13:25:40 UHLW 0 30058 lo0 127.0.0.1 127.0.0.1 UH 1 51637 lo0 -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000131234750.E31346>