Date: Mon, 06 Sep 2010 15:12:03 +0200 From: Ian FREISLICH <ianf@clue.co.za> To: Randy Bush <randy@psg.com> Cc: freebsd-current@freebsd.org Subject: Re: significantly slow IPFW + NATD + amd64 Message-ID: <E1OsbUR-0001Wr-6Q@clue.co.za> In-Reply-To: <m2wrqzgmeb.wl%randy@psg.com> References: <m2wrqzgmeb.wl%randy@psg.com> <4C84A44D.90403@3mail4.co.uk> <4C825094.5040204@secover.com.br> <20100905155311.GA48095@onelab2.iet.unipi.it> <4C84364D.9070700@DataIX.net> <E1OsXO0-00017U-Fa@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Randy Bush wrote:
> Ian FREISLICH wrote:
> > Peter Reo Molnar wrote:
> > > Hello,
> > >
> > > I tried setup NAT with IPFW, compiled my kernel and I found that there
> > > is very slow connection.
> > > After I disabled NAT and IPFW then speed was increased.
> > >
> > > 64-bit FreeBSD 9-CURRENT :
> > > With IPFW: 1.2 MB/sec
> > > Without IPFW: 33 MB/sec
> > >
> > >
> > > my ipfw work with i386 (stable) without speed decreasing:
> > >
> > > fw.test.conf:
> > > -f flush
> > > add 00050 divert 8668 ip4 from any to any via re0
> > > add 00100 allow ip from any to any via lo0
> > > add 00200 deny ip from any to 127.0.0.0/8
> > > add 00300 deny ip from 127.0.0.0/8 to any
> >
> > This looks like you're using the old style NAT - divert to userland.
> > That has always performed poorly. Perhaps not as poorly as this
> > though. How much CPU is natd consuming?
> >
> > Have you considered using in-kernel NAT? See the 'NETWORK ADDRESS
> > TRANSLATION' section in the ipfw manual. It's worth a try.
>
> i never managed to figure out how to convert my pppoe nat config to ipfw
> natting.
>
> foo:
> set device PPPoE:vr0
> set MTU 1454
> accept CHAP
> enable lqr
> add default HISADDR
> nat enable yes
> nat port tcp 192.168.0.33:51332 51332
> nat port udp 192.168.0.33:51332 51332
> set authname blogovitch
> set authkey vitchoblog
>
> loop:
> set log phase chat connect lcp ipcp command
> set device localhost:pptp
> set dial
> set login
> set ifaddr 192.168.0.200 192.168.0.201 255.255.255.255
>
> clue bat solicited
I should have prefaced this with "last used ipfw in 2005". One of the
reasons for this was poor NAT performance because of all the kernel-user
and back again copies. I've always done it your way for 2 reasons:
1. In this country, PPPoE means you're using ADSL or some broadband
connection, and you can't get them fast enough that filling your
line will use more than 1% CPU doing NAT in userland.
2. The broadband in this country assigns a dynamic IP address and
until recently reset the connection every 24h, so your NAT had
to be aware of these changes and restart itself.
You can use the ppp.linkup and ppp.linkdown files to make scripts
for your ppp profiles to add and delete NAT rules and restart natd.
For instance I used to run a PPP over UDP tunnel over my PPPoE
connection to get a static IP address at home. The ppp profile
that was always on was called adsl. I had a seperate profile called
tunnel that would start only when the adsl profile had link:
ppp.linkup
---
adsl:
! sh -c "pppctl -p pass 127.0.0.1:3001 quit all; sleep 30; /usr/sbin/ppp -unit 1 -quiet -ddial tunnel"
---
ppp.linkdown
---
[brane] /etc/ppp # cat ppp.linkdown
adsl:
! sh -c "pppctl -p pass 127.0.0.1:3001 quit all"
---
I'm sure you could coax these scripts to do what you want, but
unless you have more than 50mbps I doubt it's worth the effort.
pf just makes so much more sense for NAT, but it suffers the same
static addressing problem:
nat on vlan2 from { 41.154.7.0/24 } -> 41.161.16.1
Ian
--
Ian Freislich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1OsbUR-0001Wr-6Q>