Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Mar 2012 11:01:52 +1000
From:      Da Rock <freebsd-ipfw@herveybayaustralia.com.au>
To:        Julian Elischer <julian@freebsd.org>
Cc:        freebsd-ipfw@freebsd.org
Subject:   Re: newbie IPFW user - when handbook examples dont work...
Message-ID:  <4F6D1D00.1080607@herveybayaustralia.com.au>
In-Reply-To: <4F64BC7A.8080607@freebsd.org>
References:  <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 03/18/12 02:31, Julian Elischer wrote:
> On 3/17/12 1:36 AM, Da Rock wrote:
>> On 03/14/12 17:09, Rémy Sanchez wrote:
>>> On Saturday 10 March 2012 00:39:24 Da Rock wrote:
>>>> I'm relatively new to IPFW, not FBSD; the last time I used IPFW (I
>>>> believe) was using 4.3. I'm now attempting to use IPFW for some tests
>>>> (and hopefully move to production), and I'm trying to determine how I
>>>> would setup binat using IPFW; or even if its possible at all.
>>>>
>>>> I've been hunting some more in depth documentation, but it appears 
>>>> to be
>>>> scarce/not definitive. I suspect using the modes in libalias such as
>>>> "use same ports" and "reverse" might be able to do what I'm looking 
>>>> for?
>>>>
>>>> Any clarity much appreciated.
>>>> _______________________________________________
>>>> freebsd-ipfw@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>>>> To unsubscribe, send any mail to 
>>>> "freebsd-ipfw-unsubscribe@freebsd.org"
>>> Well, what do you want to do with your firewall ?
>>>
>>> Because ipfw is kick-ass for QoS management, and is fairly simple to 
>>> use in
>>> other tasks, but if you want to do some complex NAT, it's going to 
>>> be a pain
>>> in comparison to what pf offers.
>>>
>>> Just make sure of what your main requirement is :)
>>>
>>> My 2 cents,
>> Bluntly put, but very accurate :)
>>
>> I want it to do something pf cant - port forward ipsec packets for 
>> Android L2TP/IPSec. Apparently (according to pfsense experts) it is 
>> impossible until Android 3.0 or 4.0. My next port of call will be 
>> ipfilter, and thats a known working solution but I want to use more 
>> robust native tools.
>
> you need to really explain what you want here..  do you want the IP 
> packets to still have the original ports/addesses in them or do you 
> want to have the packets untouched, but redirected?
>
> a picture helps too.
To be honest I'm not sure anyone specifically understands why pf fails. 
I think it may have to do with fragmentation reassembly.

To describe in a nutshell (remembering that this is a testbed scenario 
atm to be replicated 1:1 with the real world):

[WAN] <---> [EXTIF/red0]<IPFW>[INTIF/green0] <---> [internal 
network/LAN] <---> [VPN - L2TP/IPSec]

This is in a VBox environment atm, using a virtual lan.

This is turning out to be a lot harder than I thought; I've tried all 
kinds of tricks but its a complete no go! I resorted to the example in 
the handbook for NAT, and I still cannot communicate from the VPN to the 
rest of the network. I cannot for the life of me determine the reason 
for this, and I now turn to the gurus of the IPFW :)

These are the rules I'm using (for the most part a direct copy/paste of 
the handbook, with some variations such as ssh and non discriminate 
outbound traffic):

#!/bin/sh
cmd="ipfw -q add"
skip="skipto 500"
pif=red0
ks="keep-state"
good_tcpo="22,25,37,43,53,80,443,110,119"

ipfw -q -f flush

$cmd 001 allow log ip from any to any ssh keep-state
$cmd 002 allow log all from any to any via green0  # exclude LAN traffic
$cmd 003 allow log all from any to any via lo0  # exclude loopback traffic

$cmd 100 divert natd log ip from any to any in via $pif
$cmd 101 check-state log

# Authorized outbound packets
$cmd 120 $skip log ip from any to any in via green0 setup $ks
#$cmd 121 $skip log udp from any to any 53 out via $pif $ks
#$cmd 125 $skip log tcp from any to any $good_tcpo out via $pif setup $ks
#$cmd 130 $skip log icmp from any to any out via $pif $ks
#$cmd 135 $skip log udp from any to any 123 out via $pif $ks


# Deny all inbound traffic from non-routable reserved address spaces
#$cmd 300 deny log all from 192.168.0.0/16  to any in via $pif  #RFC 
1918 private IP
$cmd 301 deny log all from 172.16.0.0/12   to any in via $pif  #RFC 1918 
private IP
$cmd 302 deny log all from 10.0.0.0/8      to any in via $pif  #RFC 1918 
private IP
$cmd 303 deny log all from 127.0.0.0/8     to any in via $pif  #loopback
$cmd 304 deny log all from 0.0.0.0/8       to any in via $pif  #loopback
$cmd 305 deny log all from 169.254.0.0/16  to any in via $pif  #DHCP 
auto-config
$cmd 306 deny log all from 192.0.2.0/24    to any in via $pif  #reserved 
for docs
$cmd 307 deny log all from 204.152.64.0/23 to any in via $pif  #Sun cluster
$cmd 308 deny log all from 224.0.0.0/3     to any in via $pif  #Class D 
& E multicast

# Authorized inbound packets
$cmd 400 allow log udp from any to me 68 in $ks

$cmd 440 allow log all from me to any
$cmd 445 allow log all from any to me

$cmd 450 deny log ip from any to any

# This is skipto location for outbound stateful rules
$cmd 500 divert natd log ip from any to any out via $pif

The default is to allow (for the moment).

I've set the natd in the rc.conf:

gateway_enable="YES"
firewall_enable="YES"
firewall_logging="YES"
natd_enable="YES"
natd_interface="red0"
natd_flags="-dynamic -m -log -log_denied"

So I can see the alias logs:

icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=13 (sock=0)
icmp=0, udp=14, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=14 (sock=0)
icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=13 (sock=0)
icmp=0, udp=14, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=14 (sock=0)
icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=13 (sock=0)
icmp=0, udp=12, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=12 (sock=0)
icmp=0, udp=11, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=11 (sock=0)
icmp=0, udp=10, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=10 (sock=0)
icmp=0, udp=11, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=11 (sock=0)
icmp=0, udp=10, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=10 (sock=0)

And the firewall logs show that the traffic *from* the VPN hits rule 3 
quitting at rule 450, and I cannot prevent it no matter what I try.

What am I missing here? Logging is verbose and unlimited. I did start 
with exactly what was in the handbook, with ssh turned on and a generic 
outbound skipto. The kernel is built with these options (although I did 
try without):

include GENERIC
ident FIREWALL

# IPFW for NAT
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=5
options IPFIREWALL_FORWARD
options DUMMYNET
options IPDIVERT
options HZ=1000

# ALTQ Support
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
#options ALTQ_NOPCC
options ALTQ_DEBUG

Also, I understand the need for protection from syslog DOS when verbose 
logging is on, but is there any way to mitigate it? The logs show only 
the first hits and then nothing, but they don't count individual peers - 
just the hits. That appears to be quite a hole in the system...

TIA
>
>>
>> As for being a pita - I don't know. It doesn't seem any harder to me, 
>> could even be easier; seems to be a psychological thing. I'll get 
>> back to you (the list) when I have achieved an outcome and let you 
>> know. So far I haven't had to compile a new kernel, so thats a 
>> definite plus... that could change though. More info in the next 
>> episode ;) I've just finished wrestling with certificate 
>> generation.... grr! It was easier last time, not sure what has been 
>> the issue this time.
>> _______________________________________________
>> freebsd-ipfw@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
>>
>>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F6D1D00.1080607>