Re: pollng: pcap bench
Le 19 sept. 07 à 16:59, Fabien THOMAS a écrit : Result of pcap benchmark requested by Vlad Galu: Using polling is better. Test setup: --- netblast -- em|fxp -- pcap_bmark under FreeBSD 6.2 Small product (fxp interface): --- pollng: Captured 30322.00 pps (total of 333542) and dropped 144 Captured 30358.45 pps (total of 333943) and dropped 219 Captured 30253.18 pps (total of 332785) and dropped 151 Captured 30276.82 pps (total of 333045) and dropped 88 Captured 30362.64 pps (total of 333989) and dropped 369 intr: Captured 0.01 pps (total of 6877442) and dropped 6876215 completly stuck with intr mode so the period take more than 10s. Large product (em interface): --- pollng: Captured 114669.09 pps (total of 1261360) and dropped 0 Captured 115263.18 pps (total of 1267895) and dropped 0 Captured 115226.45 pps (total of 1267491) and dropped 0 Captured 115003.64 pps (total of 1265040) and dropped 0 intr: Captured 99091.91 pps (total of 1090011) and dropped 629467 Captured 105180.64 pps (total of 1156987) and dropped 617526 Captured 99722.36 pps (total of 1096946) and dropped 607367 Captured 104180.91 pps (total of 1145990) and dropped 626567 Hello Fabien, Thanks one more time for your contribution. One small question for you, what was the overhall packet size during capture ? By the way, I found out similar reports regarding polling in new FreeBSD releases: - http://www.net.t-labs.tu-berlin.de/papers/SWF-PCCH10GEE-07.pdf - a couple on our mailing lists. Would be nice if some commiters can take the time to review this code (pollng). Best regards, /Olivier -- Olivier Warin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2
On Mon, Aug 20, 2007 at 12:43:25PM -0400, Scott Ullrich wrote: > On 8/20/07, VANHULLEBUS Yvan <[EMAIL PROTECTED]> wrote: > > I tracked down the problem a few years ago, on FreeBSD 4.11, with > > KAME's IPSec stack. > > > > But the problem was not really in the stack itself, but rather in > > socket processing (in other words: not in netkey/*, but in > > kern/uipc_socket2.c). > > > > And as both IPSec stacks shares some PFKey constraints (for example > > one message per entry when dumping SADB / SPD), I guess the same > > problem existed in FAST_IPSEC. > > > > But when I had some time a few months ago to start filling a PR for > > the problem, I had a look at FreeBSD6 source code, and I noticed that > > sbspace macro (which was a quite important part of the problem) has > > changed, and I didn't have the required setup to do the test again, so > > I just can't be really sure the problem still exists... > > > > But the reported problem really has similar symptoms. > > Thank you Yvan and George! > > The PR has been filed and the ID# is > > kern/115651 > > I have added some interesting notes that seem to affect NetBSD as well. > > We will be happy to work with anyone to get this solved and access to > the machine in question is available if need be. I'd also like to express an interest in helping with this problem in any way possible. We're running into the same problem on our fileservers and have had to rollback a large project when we unexpectedly discovered the problem. Thanks, -- Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley pgpVbYzktq3Va.pgp Description: PGP signature
Large-scale 1-1 NAT
Hello, We're working on expanding our wireless network. Unfortunately, we're running out of IP addresses (aren't we all). As much as I'd love to just tell everyone to use IPv6, that isn't gonna fly. The next plan to consider is using an RFC1918 pool and NATing the traffic. If only it were that simple. The security folks have mandated that anyone who can talk to the internet at large must be individually indentifiable. This means having hundreds of users NATing to a single internet-routable IP isn't happening. I want to try a setup in which we have a big RFC1918 pool of addresses, say 10.8/16. In their initial state, these hosts might NAT to a single public IP and perform some transparent proxying to get them to an authentication page. The firewall on our NAT box would be extremely restrictive for these clients. When a user authenticates, we will allocate a single public IP for the session. At this time, our code would use ipfw to move the user into a different lookup table and also update the NAT table. The real question is: what's the best way to dynamically update the NAT table? It doesn't look like there's any way to have a running natd update its configuration without restarting. That's obviously disruptive. I also doubt it's a good idea to try to launch a single natd process per authenticated client. We have a /22 and a /23 in our public pools, and we expect to max that out (1500+ clients). Has anyone attempted a setup like this? Do you have any pointers for designing this to scale well? We are planning on throwing hardware at it, but that only gets us so far. Thanks for your help, -- Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley pgp7zgtaOdi9s.pgp Description: PGP signature
Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2
On Sat, Aug 18, 2007 at 03:58:16PM -0400, Scott Ullrich wrote: > We have worked around the problem for now with a simple shell script > that looks for racoon falling over and simply restarting it. How are you detecting when racoon gets wedged? I'd like to replicate that on our systems. Thanks, -- Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley pgpL0JUN5aRn6.pgp Description: PGP signature
Re: Large-scale 1-1 NAT
Hi, Christopher Cowart wrote: > Hello, > > We're working on expanding our wireless network. Unfortunately, we're > running out of IP addresses (aren't we all). As much as I'd love to just > tell everyone to use IPv6, that isn't gonna fly. The next plan to > consider is using an RFC1918 pool and NATing the traffic. > > If only it were that simple. The security folks have mandated that > anyone who can talk to the internet at large must be individually > indentifiable. This means having hundreds of users NATing to a single > internet-routable IP isn't happening. We used to have this problem too, for some NATed networks. The solution which has been adopted is to capture the flows on the gateway and send them the security team. The netflow protocol is very well suited for this. > The real question is: what's the best way to dynamically update the NAT > table? You may use IPFW with IPNAT or PF instead. PF is able to reload its configuration without disruption. Moreover, because the state table is not flushed during a reload, you can even move NATed clients from one public IP to another, without them noticing. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quagga as border router
On Fri, 21 Sep 2007 10:10:06 -0700
"Kevin Oberman" <[EMAIL PROTECTED]> wrote:
> Ever run into a non-existent 'olive'?
Hi Kevin,
I dont understand :)
> Or even a J series Juniper?
> Juniper put together a very impressive software based routing system
> that is FreeBSD based.
Yes, I know of this, but ... I see that Richard has touched what I was going to
ask, whether Juniper has extended the fbsd network code or simply used FBSD as
the base to build their own system.
It's the along the same lines as saying that OS-X was built from FBSD, isn't
it ?
If what you mean is "look at Juniper's cool/great routing software , using
freebsd as a starting point - that kind of thing is what we should try to
build" , excellent, that's the kind of answer i was trying to get from
someone...what are we aiming for...
thanks for your time :)
B
_
{Beto|Norberto|Numard} Meijome
"Produce great people, the rest will follow."
Elbert Hubbard
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quagga as border router
Richard, good day. Fri, Sep 21, 2007 at 02:10:06PM -0400, Richard A Steenbergen wrote: > > Interesting what is the golden aim of software based router we should be > > trying to reach? > > Well for starters, to have a routing stack that is based on any modern > techniques developed in the last 20 years or so. It may not even matter, > there is plenty to FreeBSD that has absolutely nothing to do with routing, > and if all you're doing is throw 5Mbps at a core 2 duo it really doesn't > matter how the routing code is implemented. :) There are plenty of good > folks who understand all of this perfectly well (for example Andre > Oppermann), who are working hard to modernize fbsd's routing code, so I > have full faith that it will be fixed eventually. :) Could you please throw some links to these modern techniques? I am keen to read about it. Thank you. -- Eygene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Large-scale 1-1 NAT
On Monday 24 September 2007, Cristian KLEIN wrote: > Hi, > > Christopher Cowart wrote: > > Hello, > > > > We're working on expanding our wireless network. Unfortunately, we're > > running out of IP addresses (aren't we all). As much as I'd love to > > just tell everyone to use IPv6, that isn't gonna fly. The next plan > > to consider is using an RFC1918 pool and NATing the traffic. > > > > If only it were that simple. The security folks have mandated that > > anyone who can talk to the internet at large must be individually > > indentifiable. This means having hundreds of users NATing to a single > > internet-routable IP isn't happening. > > We used to have this problem too, for some NATed networks. The solution > which has been adopted is to capture the flows on the gateway and send > them the security team. The netflow protocol is very well suited for > this. > > > The real question is: what's the best way to dynamically update the > > NAT table? > > You may use IPFW with IPNAT or PF instead. PF is able to reload its > configuration without disruption. Moreover, because the state table is > not flushed during a reload, you can even move NATed clients from one > public IP to another, without them noticing. In fact pf comes with an almost ready-made sollution. Check out authpf(8) for details. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Current problem reports assigned to you
Current FreeBSD problem reports Critical problems S Tracker Resp. Description o kern/115360 net[ipv6] IPv6 address and if_bridge don't play well toge o kern/116172 netNetwork / ipv6 recursive mutex panic 2 problems total. Serious problems S Tracker Resp. Description s kern/21998 net[socket] [patch] ident only for outgoing connections a kern/38554 netchanging interface ipaddress doesn't seem to work s kern/39937 netipstealth issue s kern/81147 net[net] [patch] em0 reinitialization while adding aliase o kern/92552 netA serious bug in most network drivers from 5.X to 6.X s kern/95665 net[if_tun] "ping: sendto: No buffer space available" wit s kern/105943 netNetwork stack may modify read-only mbuf chain copies o kern/106316 net[dummynet] dummynet with multipass ipfw drops packets o kern/108542 net[bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net[ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net[ipsec] Filtering incoming packets with enc0 does not o kern/112528 net[nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net[patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 netIP v4 udp fragmented packet reject o kern/113457 net[ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net[ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net[gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net[fxp] fxp looses ability to speak with traffic o kern/115239 net[ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net6.2-STABLE panic during use of multi-cast networking c o kern/116185 netif_iwi driver leads system to reboot o kern/116186 netcan not set wi channel on current o kern/116328 net[bge]: Solid hang with bge interface o kern/116330 net[nfe]: network problems under -current, nfe(4) and jum 24 problems total. Non-critical problems S Tracker Resp. Description o conf/23063 net[PATCH] for static ARP tables in rc.network s bin/41647netifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net[nfs] [patch] NFS root configurations without dynamic s kern/60293 netFreeBSD arp poison patch o kern/95267 netpacket drops periodically appear f kern/95277 net[netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net[netisr] suggestion to fix suboptimal network polling o kern/102035 net[plip] plip networking disables parallel port printing o conf/102502 net[patch] ifconfig name does't rename netgraph node in n o kern/103253 netinconsistent behaviour in arp reply of a bridge o conf/107035 net[patch] bridge interface given in rc.conf not taking a o kern/112654 net[pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114095 net[carp] carp+pf delay with high state limit o kern/114915 net[patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f 14 problems total. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2
On 9/24/07, Christopher Cowart <[EMAIL PROTECTED]> wrote: > On Sat, Aug 18, 2007 at 03:58:16PM -0400, Scott Ullrich wrote: > How are you detecting when racoon gets wedged? I'd like to replicate > that on our systems. Our script is primitive at best but does seem to do the job okay: http://pfsense.com/cgi-bin/cvsweb.cgi/pfSense/usr/local/sbin/racoon_watch.sh?rev=1.8;content-type=text%2Fplain Let me know if it helps. This generally well detect the problem quick enough to minimize downtime between the tunnels (in our experience). Scott ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Large-scale 1-1 NAT
Christopher Cowart wrote: Hello, We're working on expanding our wireless network. Unfortunately, we're running out of IP addresses (aren't we all). As much as I'd love to just tell everyone to use IPv6, that isn't gonna fly. The next plan to consider is using an RFC1918 pool and NATing the traffic. If only it were that simple. The security folks have mandated that anyone who can talk to the internet at large must be individually indentifiable. This means having hundreds of users NATing to a single internet-routable IP isn't happening. Are you sure it doesn't just mean you need to keep logs of who was NAT'd to what at any time? I want to try a setup in which we have a big RFC1918 pool of addresses, say 10.8/16. In their initial state, these hosts might NAT to a single public IP and perform some transparent proxying to get them to an authentication page. The firewall on our NAT box would be extremely restrictive for these clients. When a user authenticates, we will allocate a single public IP for the session. At this time, our code would use ipfw to move the user into a different lookup table and also update the NAT table. The real question is: what's the best way to dynamically update the NAT table? I don't think we have the ability to do that. it may take some coding on your part. It doesn't look like there's any way to have a running natd update its configuration without restarting. That's obviously disruptive. I also doubt it's a good idea to try to launch a single natd process per authenticated client. We have a /22 and a /23 in our public pools, and we expect to max that out (1500+ clients). Has anyone attempted a setup like this? Do you have any pointers for designing this to scale well? We are planning on throwing hardware at it, but that only gets us so far. never heard of such a setup. I suggest you find out if that is the only solution your security people would accept. (As someone doing security stuff for a few years I think that someone is confused somewhere). Thanks for your help, ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TX Multiqueue?
On 9/23/07, Kip Macy <[EMAIL PROTECTED]> wrote: > On 9/23/07, Darren Reed <[EMAIL PROTECTED]> wrote: > > Kip Macy wrote: > > > My ethng branch supports multiple rx and tx queues. > > > > > > -Kip > > > > > > > What are your plans for how we use/manage/interact with the mutiple > > rx/tx queues? > > The rx hardware queue is determined by the hardware. Different > hardware allows for different policies. I just use the stock rss_hash > of a crc32 of the 4-tuple in cxgb. I've added a field to the pkthdr > which cxgb uses the least significant bits of to determine which > outbound queue to use. Its up to the upper layers to determine how to > set those bits. One of the changes that is required to take advantaged > of this is moving the queues into the driver. I've added a new > if_start function to ifnet to take advantage of this. I also have a > normal if_start function for backward compatibility. Yes, the queues in Oplin and Zoar are also a hardware feature, not just some software infrastructure. There are a number of different ways that it can be configured. I did not have some settled notion of how things should be managed but I would rather not have it be something done under the covers in the driver, a configurable stack option seems better to me. This needs to be done right or it will just be a hack, I don't know who the right parties are, it should not be just a one-person decision, those with a stake in this sort of thing should all be involved. Cheers, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: nat and ipfw - divert or builtin
> divert > ipnat > ipfw's integrated nat > > I believe the integrated version makes configuration simpler. I would > choose the old classic divert with ipfw if it is for a important network > that must work, but if I was running -current I would try the integrated > variant beacuse it seems to be simpler to use. you seem to imply that you have reason to suspect that ipfw integrated nat might not be reliable, or at least not as reliable as divert+natd. any particular experiences or gossip to tell? randy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Large-scale 1-1 NAT
On Mon, Sep 24, 2007 at 11:58:15AM +0300, Cristian KLEIN wrote: >Christopher Cowart wrote: >>We're working on expanding our wireless network. Unfortunately, we're >>running out of IP addresses (aren't we all). As much as I'd love to just >>tell everyone to use IPv6, that isn't gonna fly. The next plan to >>consider is using an RFC1918 pool and NATing the traffic. >> >>If only it were that simple. The security folks have mandated that >>anyone who can talk to the internet at large must be individually >>indentifiable. This means having hundreds of users NATing to a single >>internet-routable IP isn't happening. > >We used to have this problem too, for some NATed networks. The solution which >has been adopted is to capture the flows on the gateway and send them the >security team. The netflow protocol is very well suited for this. We have automated intake and processing for security cases. These often just contain the IP the bad traffic appeared to be coming from. While we could probably reconstruct things using netflow, we definitely wouldn't have the staff time to do so. As such, we'd have to keep this information in a database, which will add up fast. Keeping track who was using an IP at a given time is relatively easy. Granted, this places the complexity in the network and not the security processing, but that's where we have resources. >>The real question is: what's the best way to dynamically update the NAT >>table? > >You may use IPFW with IPNAT or PF instead. PF is able to reload its >configuration without disruption. Moreover, because the state table is not >flushed during a reload, you can even move NATed clients from one public IP to >another, without them noticing. We would prefer to stick with ipfw. The most common documentation I've founded is natd+ipfw. I've also seen pf+ipnat. I haven't really seen any documentation on ipfw+ipnat. Is this possible? Or would we be able to do ipfw+pf+ipnat? What solution would scale best to 1500-4000 authenticated users? -- Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley pgpx7Vh0AhCCb.pgp Description: PGP signature
Re: Large-scale 1-1 NAT
On Mon, Sep 24, 2007 at 12:57:19PM +0200, Max Laier wrote: > On Monday 24 September 2007, Cristian KLEIN wrote: > > Christopher Cowart wrote: > > > The real question is: what's the best way to dynamically update the > > > NAT table? > > > > You may use IPFW with IPNAT or PF instead. PF is able to reload its > > configuration without disruption. Moreover, because the state table is > > not flushed during a reload, you can even move NATed clients from one > > public IP to another, without them noticing. > > In fact pf comes with an almost ready-made sollution. Check out authpf(8) > for details. That looks pretty cool. The problem is these are not local users; the only way to authenticate them is to use web-based services. -- Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley pgp5PM4J8pomA.pgp Description: PGP signature
Re: Large-scale 1-1 NAT
On Mon, Sep 24, 2007 at 01:26:13PM +0400, [EMAIL PROTECTED] wrote: > original: >> We're working on expanding our wireless network. Unfortunately, we're >> running out of IP addresses (aren't we all). As much as I'd love to just >> tell everyone to use IPv6, that isn't gonna fly. The next plan to >> consider is using an RFC1918 pool and NATing the traffic. >> >> If only it were that simple. The security folks have mandated that >> anyone who can talk to the internet at large must be individually >> indentifiable. This means having hundreds of users NATing to a single >> internet-routable IP isn't happening. > > do your security foulks want connections to be identifiable > outside-in or inside-out? If inside-out then netflow before single > ip nat should do the trick Complaints from the outside world must be traceable to a single individual behind the NAT. This is a significantly easier, especially in automated case handling, when only one person is using a public IP at a time. >> I want to try a setup in which we have a big RFC1918 pool of addresses, >> say 10.8/16. In their initial state, these hosts might NAT to a single >> public IP and perform some transparent proxying to get them to an >> authentication page. The firewall on our NAT box would be extremely >> restrictive for these clients. >> >> When a user authenticates, we will allocate a single public IP for the >> session. At this time, our code would use ipfw to move the user into a >> different lookup table and also update the NAT table. >> >> The real question is: what's the best way to dynamically update the NAT >> table? > > we used pf to binat people (in parallel with ipfw to filter them). > How are you going to nat them (ipf, pf, netgraph)? Updating rules on > the fly was as simple as reloading them (no disruption to existing > pf states). Netgraph nat states behave similarly. The real problem > with pf binat was when we had about a hundred binat rules it almost > halted the traffic through the router. Are you suggesting that a pf solution isn't going to scale well on the order of 1500 clients? We may even get additional public address space to support 4000 or more clients. Will netgraph scale better? >> It doesn't look like there's any way to have a running natd update its >> configuration without restarting. That's obviously disruptive. > > use ipfw+netgraph instead So you recommend ipfw+netgraph? We don't have any experience working with netgraph. I see ng_nat(4), but if anyone could point me to a more thorough howto, I'd greatly appreciate it. >> I also doubt it's a good idea to try to launch a single natd process per >> authenticated client. We have a /22 and a /23 in our public pools, and >> we expect to max that out (1500+ clients). > > you are right. It is not. > My expirience is it is bad idea to even have more than a couple of > doezns binat rules in sequence (although i tried it with pf, not > with netgraph). > >> Has anyone attempted a setup like this? Do you have any pointers for >> designing this to scale well? We are planning on throwing hardware at >> it, but that only gets us so far. > > my ploblem was how to not reserve large number of small address > pools in advance and use a single pool of /22 to number customers > belonging to many different physical segments (even living behind > different routers). > > i used binat first but it scaled badly, so i found a better > solution. I guess you problem is different. What do you mean? We do have 3 discontiguous subnets (/22, /23, /26), and may add one or more /22 or /23 subnets in the future, so we definitely need the ability to pull from various pools. Our NAT box will be attached to a trunked interface and use vlan interfacess to reach the routers for each of the subnets. Thanks for your experiences trying to get binat to scale -- we were definitely considering the pf+ipnat solution. -- Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley pgpN3DoitnYDi.pgp Description: PGP signature
Re: Large-scale 1-1 NAT
Christopher Cowart wrote: > On Mon, Sep 24, 2007 at 11:58:15AM +0300, Cristian KLEIN wrote: >> Christopher Cowart wrote: >>> We're working on expanding our wireless network. Unfortunately, we're >>> running out of IP addresses (aren't we all). As much as I'd love to just >>> tell everyone to use IPv6, that isn't gonna fly. The next plan to >>> consider is using an RFC1918 pool and NATing the traffic. >>> >>> If only it were that simple. The security folks have mandated that >>> anyone who can talk to the internet at large must be individually >>> indentifiable. This means having hundreds of users NATing to a single >>> internet-routable IP isn't happening. >> We used to have this problem too, for some NATed networks. The solution which >> has been adopted is to capture the flows on the gateway and send them the >> security team. The netflow protocol is very well suited for this. > > We have automated intake and processing for security cases. These often > just contain the IP the bad traffic appeared to be coming from. While we > could probably reconstruct things using netflow, we definitely wouldn't > have the staff time to do so. As such, we'd have to keep this > information in a database, which will add up fast. Keeping track who was > using an IP at a given time is relatively easy. Granted, this places the > complexity in the network and not the security processing, but that's > where we have resources. I must admit I haven't thought of this. With this new information I am missing a point. Since you need to make a 1-to-1 association between clients and public IPs, why do you need the NAT at all. Is this to save public IPs by NOT giving them to unauthenticated users? There is another thing I wanted to point out. I remember you used the words "authentication web page". This made me think you are establishing a captive portal, which is not secure at all. If I understand well the authpf solution would be secure, except perhaps a small delay. You might proxy your clients to a "click here and download this preconfigured PuTTY" page. >>> The real question is: what's the best way to dynamically update the NAT >>> table? >> You may use IPFW with IPNAT or PF instead. PF is able to reload its >> configuration without disruption. Moreover, because the state table is not >> flushed during a reload, you can even move NATed clients from one public IP >> to >> another, without them noticing. > > We would prefer to stick with ipfw. The most common documentation I've > founded is natd+ipfw. I've also seen pf+ipnat. I haven't really seen any > documentation on ipfw+ipnat. Is this possible? Or would we be able to do > ipfw+pf+ipnat? What solution would scale best to 1500-4000 authenticated > users? I have used ipfw + pf for almost a year, for about 400 clients and I am very happy with it. Note that I only use ipfw for dummynet. In all other situations I only use PF. PF uses a binary tree to store NAT states, so it isn't really affected by the number of clients. It also features state timeouts reduction based on the number of NAT states, which is very useful if one Windows station gets a "lets scan the whole /16" virus. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nat and ipfw - divert or builtin
Randy Bush wrote: divert ipnat ipfw's integrated nat I believe the integrated version makes configuration simpler. I would choose the old classic divert with ipfw if it is for a important network that must work, but if I was running -current I would try the integrated variant beacuse it seems to be simpler to use. you seem to imply that you have reason to suspect that ipfw integrated nat might not be reliable, or at least not as reliable as divert+natd. any particular experiences or gossip to tell? No, like I said I only have experience with divert, but in my opinion it's best to not use the latest software for things that *must* work and the integrated nat is a new thing and only available for -current. However it's based on something that been around for a while, libalias, so I guess it's stable. I'm planning on trying to use ipnat with ipfw on freebsd 6.2 because I think that's simpler than divert and has been around for a while. But again if I was running a system based on -current I would go for the integrated variant. -- Christer Hermansson ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Large-scale 1-1 NAT
On Tue, Sep 25, 2007 at 12:44:47AM +0300, Cristian KLEIN wrote: >Christopher Cowart wrote: >> On Mon, Sep 24, 2007 at 11:58:15AM +0300, Cristian KLEIN wrote: >>> Christopher Cowart wrote: We're working on expanding our wireless network. Unfortunately, we're running out of IP addresses (aren't we all). As much as I'd love to just tell everyone to use IPv6, that isn't gonna fly. The next plan to consider is using an RFC1918 pool and NATing the traffic. If only it were that simple. The security folks have mandated that anyone who can talk to the internet at large must be individually indentifiable. This means having hundreds of users NATing to a single internet-routable IP isn't happening. >>> We used to have this problem too, for some NATed networks. The >>> solution which has been adopted is to capture the flows on the >>> gateway and send them the security team. The netflow protocol is >>> very well suited for this. >> >> We have automated intake and processing for security cases. These often >> just contain the IP the bad traffic appeared to be coming from. While we >> could probably reconstruct things using netflow, we definitely wouldn't >> have the staff time to do so. As such, we'd have to keep this >> information in a database, which will add up fast. Keeping track who was >> using an IP at a given time is relatively easy. Granted, this places the >> complexity in the network and not the security processing, but that's >> where we have resources. > > I must admit I haven't thought of this. With this new information I > am missing a point. Since you need to make a 1-to-1 association > between clients and public IPs, why do you need the NAT at all. Is > this to save public IPs by NOT giving them to unauthenticated users? This is exactly the point. At any given time, people may have their laptop sitting in their rooms plugged into a wired connection or they may be walking near an access point with an iPhone on their person. All of these devices are associating with our APs and eating up public IP addresses, even though they aren't using the network. Our goal is to only allocate the device a public AP after authentication has occured. > There is another thing I wanted to point out. I remember you used the > words "authentication web page". This made me think you are > establishing a captive portal, which is not secure at all. If I > understand well the authpf solution would be secure, except perhaps > a small delay. You might proxy your clients to a "click here and > download this preconfigured PuTTY" page. We are planning on using a captive portal. The only authentication mechanism we have for clients is a web-based SSO solution using CAS that isn't maintained by our staff. The people trying to authenticate are not intended to be local users on the system. What are the security problems you see with a captive portal interface? The real question is: what's the best way to dynamically update the NAT table? >>> You may use IPFW with IPNAT or PF instead. PF is able to reload its >>> configuration without disruption. Moreover, because the state table is not >>> flushed during a reload, you can even move NATed clients from one >>> public IP to another, without them noticing. >> >> We would prefer to stick with ipfw. The most common documentation I've >> founded is natd+ipfw. I've also seen pf+ipnat. I haven't really seen any >> documentation on ipfw+ipnat. Is this possible? Or would we be able to do >> ipfw+pf+ipnat? What solution would scale best to 1500-4000 authenticated >> users? > > I have used ipfw + pf for almost a year, for about 400 clients and I > am very happy with it. Note that I only use ipfw for dummynet. In > all other situations I only use PF. > > PF uses a binary tree to store NAT states, so it isn't really > affected by the number of clients. It also features state timeouts > reduction based on the number of NAT states, which is very useful if > one Windows station gets a "lets scan the whole /16" virus. I received a response off-list (to which I replied on-list) from somebody who said the pf binat solution doesn't scale will beyond 500 clients. We currently have over 1500 public IPs that could be in use, and we may eventually have more than 4000. Can anyone confirm this limitation? -- Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley pgpEr4jCjdi0Y.pgp Description: PGP signature
