Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Feb 2005 16:40:17 -0500
From:      Bill Moran <wmoran@potentialtech.com>
To:        Julian Elischer <julian@elischer.org>
Cc:        freebsd-security@freebsd.org
Subject:   Re: need ipfw clarification
Message-ID:  <20050204164017.402680f3.wmoran@potentialtech.com>
In-Reply-To: <4203DA87.3080508@elischer.org>
References:  <42028032.2020701@att.net> <4202834D.7030000@supsi.ch> <4203D4BC.30409@att.net> <20050204150936.70e843fd.wmoran@potentialtech.com> <4203DA87.3080508@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Fri__4_Feb_2005_16_40_17_-0500_cz.I/xDMzV_9iYGP
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit


I'm confusing natd forwarding with IPFW forwarding.

My apoligies for posting incorrect information, and thanks to Julian for
correcting me.

Julian Elischer <julian@elischer.org> wrote:
> 
> Bill Moran wrote:
> 
> >Duane Winner <dwinner-lists@att.net> wrote:
> >
> >  
> >
> >>Thanks Roberto,
> >>
> >>Just to make sure I understand though, I only need to be concerned 
> >>"forwarding" and "forward rules" if I'm setting up a multi-homed host 
> >>(i.e., router), is this correct?
> >>    
> >>
> >
> >It doesn't even apply then.  IPFW forwarding forwards packets and rewrites
> >their IP headers to make one machine look like another.  While this is
> >commonly used on firewalls, it's not the same thing as turning on
> >forwarding (i.e. routing between interfaces) and isn't required to set
> >up a multi-homed "router".
> >
> 
> 
> Actually that's not QUITE correct..
> ipfw forwarding works as it does because it does NOT rewrite any headers.
> The packet just shows up at the other place without any clue as to how 
> it got there. :-)
> 
> >
> >For example, I use IPFW forwarding so that my firewall forwards VNC
> >packets to my desktop, so outsiders can connect directly to my desktop
> >through the firewall.
> >  
> >
> ipfw forwarding is actually two different services.
> 
> What it does is different depending on whether the forwarding target is 
> the local machine or
> is another machine.
> 
> When forwarding to another machine, the unalterred packet is sent to 
> that machine without
> alteration. If that other machine feels that the packet belongs 
> elsewhere,  it may send it on or
> even back.
> 
> The second form is when the local machine is the target. The packet is 
> sent to the socket listenning on
> the nominated port locally, regardless of what destination machine it is 
> supposed to go to.
> 
> If  you use type 1 to forward to another machine then if the packet is 
> not naturally destined for that
> machine,  you may need the same rule (working in the second form) on 
> that machine to make sure
> that it is used on that machine instead of being forwarded elsewhere.
> 
> The neat part about local forwarding is that the local socket itself 
> thinks it is on the intended destination
> machine so doing a getsockname() returns the address of the intended target.
> This makes proxying an absolutly simple process, as the sockaddr 
> returned can be used directly to open
> a socket to the intended target..
> 
> 
> >  
> >
> >>If I'm just using ipfw for  single-host based firewall protection, then 
> >>forwarding doesn't apply, right?
> >>    
> >>
> >
> >That's correct.
> >
> >  
> >
> >>Thanks again,
> >>Duane
> >>
> >>
> >>
> >>Roberto Nunnari wrote:
> >>
> >>    
> >>
> >>>Hi Duane.
> >>>
> >>>I had the same problem.. With 5.2.1 I had working forward rules
> >>>and that were broke with 5.3
> >>>
> >>>after some fiddling I managed to have that work again.. just
> >>>add them to your kernel:
> >>>
> >>>options         IPFIREWALL
> >>>options         IPFIREWALL_DEFAULT_TO_ACCEPT
> >>>options         IPFIREWALL_VERBOSE
> >>>options         IPFIREWALL_FORWARD
> >>>
> >>>if you don't add them to your kernel, forwarding in ipfw will
> >>>be disabled.
> >>>
> >>>Ciao.
> >>>
> >>>
> >>>Duane Winner wrote:
> >>>
> >>>      
> >>>
> >>>>Hello,
> >>>>
> >>>>I noticed that after enabling firewall in my kernel (5.3-release), my 
> >>>>dmesg now gives me this:
> >>>>
> >>>>ipfw2 initialized, divert disabled, rule-based forwarding disabled, 
> >>>>default to accept, logging limited to 5 packets/entry by default
> >>>>
> >>>>
> >>>>On 5.2.1, I used to get this:
> >>>>
> >>>>ipfw2 initialized, divert disabled, rule-based forwarding enabled, 
> >>>>default to accept, logging disabled
> >>>>
> >>>>If both cases, I am adding this to my KERNEL config:
> >>>>
> >>>>options         IPFIREWALL
> >>>>options         IPFIREWALL_DEFAULT_TO_ACCEPT
> >>>>
> >>>>
> >>>>It seems that the major difference between 5.2.1 and 5.3 is that now 
> >>>>rule-based forwarding is disabled.
> >>>>
> >>>>Is this correct? And what exactly is rule-based forwarding? I'm 
> >>>>guessing that it doesn't really apply to my situation, as in these 
> >>>>cases, I am using IPFW to create a deny all inbound to my laptop when 
> >>>>I'm on the road. But I just want to make sure.
> >>>>
> >>>>Thanks,
> >>>>DW
> >>>>_______________________________________________
> >>>>freebsd-security@freebsd.org mailing list
> >>>>http://lists.freebsd.org/mailman/listinfo/freebsd-security
> >>>>To unsubscribe, send any mail to 
> >>>>"freebsd-security-unsubscribe@freebsd.org"
> >>>>        
> >>>>
> >>>
> >>>      
> >>>
> >>_______________________________________________
> >>freebsd-security@freebsd.org mailing list
> >>http://lists.freebsd.org/mailman/listinfo/freebsd-security
> >>To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
> >>    
> >>
> >
> >
> >  
> >
> 


-- 
Bill Moran
Potential Technologies
http://www.potentialtech.com

--Signature=_Fri__4_Feb_2005_16_40_17_-0500_cz.I/xDMzV_9iYGP
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)

iD8DBQFCA+vBYOm/CGAEZUARAgPZAKCfUVuUg1TLrq8ByDWnh3FimaLdWQCdGVpT
BeY1QJeAcDTnaTQgWkkb/lQ=
=plHf
-----END PGP SIGNATURE-----

--Signature=_Fri__4_Feb_2005_16_40_17_-0500_cz.I/xDMzV_9iYGP--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050204164017.402680f3.wmoran>