From owner-freebsd-questions@FreeBSD.ORG Thu Oct 30 04:20:08 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D71A0106564A for ; Thu, 30 Oct 2008 04:20:08 +0000 (UTC) (envelope-from terry@sucked-in.com) Received: from mail.sucked-in.com (got.sucked-in.com [64.251.22.156]) by mx1.freebsd.org (Postfix) with ESMTP id 915108FC1E for ; Thu, 30 Oct 2008 04:20:08 +0000 (UTC) (envelope-from terry@sucked-in.com) Received: from localhost (got.sucked-in.com [64.251.22.156]) by mail.sucked-in.com (Postfix) with ESMTP id 142041CCE0; Thu, 30 Oct 2008 15:20:08 +1100 (EST) X-Virus-Scanned: amavisd-new at sucked-in.com Received: from mail.sucked-in.com ([64.251.22.156]) by localhost (mail.sucked-in.com [64.251.22.156]) (amavisd-new, port 10024) with ESMTP id iyIAX97NZBDc; Thu, 30 Oct 2008 15:20:07 +1100 (EST) Received: from got.sucked-in.com (got.sucked-in.com [64.251.22.156]) by mail.sucked-in.com (Postfix) with ESMTPA id ACE191CCCA; Thu, 30 Oct 2008 15:20:07 +1100 (EST) Received: from eth4207.vic.adsl.internode.on.net (eth4207.vic.adsl.internode.on.net [150.101.153.110]) by webmail.tabmow.info (Horde Framework) with HTTP; Thu, 30 Oct 2008 15:20:07 +1100 Message-ID: <20081030152007.75514asofimxjqio@webmail.tabmow.info> Date: Thu, 30 Oct 2008 15:20:07 +1100 From: Terry Sposato To: Jeremy Chadwick References: <49090BA3.5090407@gmail.com> <20081030031231.8a5fccb9.freebsd@edvax.de> <49091B32.9060306@gmail.com> <20081030133658.79084brlqjxwpv6s@webmail.tabmow.info> <20081030032547.GA93923@icarus.home.lan> In-Reply-To: <20081030032547.GA93923@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-6.3 Cc: jackbarnett@gmail.com, Polytropon , Freebsd questions Subject: Re: Firewalls in FreeBSD? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2008 04:20:08 -0000 Quoting Jeremy Chadwick : > On Thu, Oct 30, 2008 at 01:36:58PM +1100, Terry Sposato wrote: >> Quoting Jack Barnett : >> >>> >>> yes, that is my setup. >>> hrm... well, I disabled the firewall completely, restarted, but still >>> doesn't work. >>> I have gateway and natd both enabled. x10 is the "external" interfac= e >>> (the one that is dhcp and connects to the cable modem). >>> I don't want to redirect anything to my windows box. I just want >>> anything that connects out from my windows box to be able to connect >>> or send data back in. >>> For example, I load up a client (game) and it connects out on XYZ >>> port. The server will send data back on ABC. >>> The problem, from what I can tell; is that I can get a connection out >>> - but when the server tries to send data back on ABC it is discarded. >>> Polytropon wrote: >>> >>> If I understood you correctly, your setting is: >>> >>> (Modem/Router)---DHCP---(FreeBSD)---("Windows") >>> >>> I may respond directly on your configuration settings: >>> >>> On Wed, 29 Oct 2008 20:19:31 -0500, Jack Barnett >>> [1] wro >>> te: >>> >>> >>> gateway_enable=3D"YES" >>> #firewall_enable=3D"YES" >>> #firewall_type=3D"open" >>> firewall_type=3D"simple" >>> #firewall_type=3D"open" >>> firewall_logging=3D"YES" >>> >>> >>> Use instead: >>> >>> gateway_enable=3D"YES" >>> natd_enable=3D"YES" >>> natd_interface=3D"xl0" >>> >>> You may add special redirect directives to NATD's settings, such >>> as >>> natd_flags=3D"-redirect_port tcp 192.168.1.2:5900 5900" >>> natd_flags=3D"-redirect_port tcp 192.168.1.5:23 6666" >>> >>> or >>> natd_flags=3D"-redirect_address 192.168.1.2 141.44.165.58 \ >>> -redirect_address 192.168.1.5 141.44.165.58" >>> >>> Examples taken from a very old configuration. :-) >>> >>> Then, >>> >>> firewall_enable=3D"YES" >>> firewall_type=3D"/etc/ipfw.conf" >>> >>> Then, be sure to have nice firewall settings, you can use things >>> similar to this, enabling just the services you really need and want, >>> it's easy to write your own one or to rewrite this: >>> >>> -f flush >>> add divert natd ip from any to any via xl0 >>> add allow tcp from any to any ftp in recv xl0 >>> add allow tcp from any to any ssh in recv xl0 >>> add allow tcp from any to any auth in recv xl0 >>> add allow udp from any to any ntp in recv xl0 >>> add allow udp from any to any ntalk in recv xl0 >>> add deny udp from any to any x11 in recv xl0 >>> add reset tcp from any to any x11 in recv xl0 >>> add allow ipencap from any to any >>> add allow ip from any to any >>> >>> This should work fine. NB to use the correct interface names. >>> >>> References >>> >>> 1. mailto:jackbarnett@gmail.com >>> _______________________________________________ >>> freebsd-questions@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >>> To unsubscribe, send any mail to =20 >>> "freebsd-questions-unsubscribe@freebsd.org" >>> >> >> Jack, >> >> It is most likely caused by your ruleset not being stateful. If packets >> are going out certain sessions and your firewall isn't then allowing back >> in you would see the issue you are seeing. I am not sure how this is >> accomplished via ipfw as I use pf but there would be a tonne of >> documentation out there on how to make your rules stateful. > > Are you sure about that? Read his statement once more: > >>> For example, I load up a client (game) and it connects out on XYZ >>> port. The server will send data back on ABC. Ahh yes correct, I was going on the assumption that the traffic is =20 trying to return using the same session details. This is usually how =20 it is with gaming traffic and the non stateful ruleset is usually the =20 cause of why this sort of traffic get's blocked. Would like to see if =20 the OP has actually sniffed the traffic and can say without a shadow =20 of a doubt that different ports are being used ingoing & outgoing. > > I assume based on this, the following is happening: > > - 192.168.x.x:aaaaa sends packet to gameserver:xyz > > - NAT gateway translates packet (where "natgw" is a public WAN IP) > > 192.168.x.x:aaaaa <--> natgw:bbbbb <--> gameserver:xyz > > - gameserver sees packet to port xyz, and initiates new connection > to natgw:abc > > - NAT gateway drops packet destined to WAN IP port abc, because the > gameserver:abc connection is *new*, and does not relate to the > previous NAT'd gameserver:xyz connection. > > If this is **truly** how the protocol works (the OP will need to be > absolutely 100% positive of that fact; I recommend he reconfirm how it > works), then the only solution is to set up a port forward on the NAT > gateway for port abc to point to 192.168.x.x. > > This also means that only one computer on the LAN will be capable of > playing this game. Not much one can do about that, other than write > the authors of the game and explain that their protocol is absolutely > disgusting. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.or= g" > Regards, Terry Sposato terry@sucked-in.com Have you been sucked in? http://www.sucked-in.com ----------------------------------------------------------------------------= --------- This message was sent from the Sucked In Webmail Interface - =20 http://www.sucked-in.com