Re: natd restart
Am 27.01.2002 um 00:41:23 schrieb Rogier R. Mulhuijzen: Hi Roger, > What sort of changes are you talking about here? Maybe there's a different > way of going about it. I want to move an existing network from 91.0.0.0/8 to 172.16.0.0/16. Furthermore name resolution changes from wins to dns and dhcp is no longer used. The whole story has to take place during normal operation and I can not enter a gateway on any machine. It will take ~2 weeks and there are ~100 computers. I thought of using FreeBSD/ipfw/natd and two nics. One nic is in the 91.0.0.0 and the other in 172.16.0.0. Whenever a computer moves from 91.0.0.0 to 172.16.0.0 I define his old IP as alias on the freebsd-box. Natd forwards packets to the new IP. In the same way I define any IP of not-yet changed computers as alias on the 172.16.0.0 nic of the FreeBSD box. Name-Resolution should not become a problem because in the "old" net, wins stays active and in the "new" net I setup the dns. So I must add/delete/change natd rules frequently. I did never do such a thing before and I did not find any information how it could be done. If there are any books/webpages/whatever which cover the issue I would be glad to know. tia /ch -- "Contrary to popular belief, Unix is user friendly. It just happens to be selective about who it makes friends with." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
Am 27.01.2002 um 02:11:30 schrieb Matthew Emmerton: Hi Matt, > Here's the patch that I wrote some time ago. thanks a lot! Did you send-pr the patch? It seems quite necessary to be added. greetz /ch -- "Contrary to popular belief, Unix is user friendly. It just happens to be selective about who it makes friends with." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ipsec, racoon, win2000, certifications, how-to?
I have posted a similar question a few days ago on freebsd-questions already but with no luck. I'm attempting to configure road-warrior win2000 laptops to access a ipsec server at the office. Since these win2000 laptops are dynamically assigned ip addresses, sometimes even behind nat, it seems like using certifications is the only possible option. But I can find very little documentation of how to do it. Does any of you know where to find documentation for how to create certifications, where to place them, how to use them, and how to configure ipsec, racoon and win2000 computers? I have attempted to use pre_shared keys, but it appear like they can only be used with fixed IP addresses in the psk.txt file. Or am I wrong? Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipsec, racoon, win2000, certifications, how-to?
- Original Message - From: "Soren Dossing" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 27, 2002 10:31 AM Subject: ipsec, racoon, win2000, certifications, how-to? > I have posted a similar question a few days ago on freebsd-questions > already but with no luck. > > I'm attempting to configure road-warrior win2000 laptops to access a ipsec > server at the office. Since these win2000 laptops are dynamically assigned > ip addresses, sometimes even behind nat, it seems like using > certifications is the only possible option. But I can find very little > documentation of how to do it. > > Does any of you know where to find documentation for how to create > certifications, where to place them, how to use them, and how to configure > ipsec, racoon and win2000 computers? > > I have attempted to use pre_shared keys, but it appear like they can only > be used with fixed IP addresses in the psk.txt file. Or am I wrong? Uhm, you can also use a email add and a password [EMAIL PROTECTED]thekeything There are a bit about certificates in a kame newsletter, try looking on the site :) How did you solve the setkey setup if the ip adress is dynamic, do you have an example? /Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
> Am 27.01.2002 um 02:11:30 schrieb Matthew Emmerton:
>
> Hi Matt,
>
> > Here's the patch that I wrote some time ago.
>
> thanks a lot!
> Did you send-pr the patch? It seems quite necessary to be added.
Not yet. One of the things that I don't like about this patch is that old
rules still stay around (re-reading the configuration will only modify
existing rules and add new rules.) I'm also taking a lot of flak on my side
of the fence since NAT runs as a userland process, so every packet gets
copied between the kernel and userland twice (once on the way in, once on
the way out.) Apparently Linux doesn't do this.
I'm looking at making natd into a kernel option ("options IPNAT") and using
a combination of sysctls and a front-end program to manage how nat operates,
much like "options IPFIREWALL" and ipfw works today.
This (in my mind) should greatly enhance the throughput of FreeBSD's NAT and
keep those Linux people from bashing us (or me, at least.)
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
> Am 27.01.2002 um 00:41:23 schrieb Rogier R. Mulhuijzen: > > Hi Roger, > > > What sort of changes are you talking about here? Maybe there's a different > > way of going about it. > > I want to move an existing network from 91.0.0.0/8 to 172.16.0.0/16. > Furthermore name resolution changes from wins to dns and dhcp is no longer > used. > The whole story has to take place during normal operation and I can not > enter a gateway on any machine. > It will take ~2 weeks and there are ~100 computers. Why not just add an IP alias for the "new" network on each machine? Each system will respond to packets directed to either network, but without the complexity of a NAT box in the middle. Once you've got everything switched, then you can remove the original IP addresses. I've used this method in the past to transition LANs between IP ranges and it works absolutely fine. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
(order of quoted mail slightly altered)
>I'm looking at making natd into a kernel option ("options IPNAT") and using
>a combination of sysctls and a front-end program to manage how nat operates,
>much like "options IPFIREWALL" and ipfw works today.
I've been kicking around the idea of making it a netgraph node. And I know
several other people have too.
>Not yet. One of the things that I don't like about this patch is that old
>rules still stay around (re-reading the configuration will only modify
>existing rules and add new rules.) I'm also taking a lot of flak on my side
>of the fence since NAT runs as a userland process, so every packet gets
>copied between the kernel and userland twice (once on the way in, once on
>the way out.) Apparently Linux doesn't do this.
libalias is very nice, natd to me has a hackey feeling to it. Try setting
up a firewall that nats and uses dynamic rules I haven't been able to,
have had to rely on natd to do my state checking, resulting in ipfw rule
lists that are not easily read by the layman. So maybe that's another
reason to re-evaluate our current NAT solution.
Would it be hard to keep using libalias? I know we can't just link against
userland libraries in kernel land, but would there be much difficulty in
making use of the exact same code? Because the beauty of having libalias is
of course the -nat switch on ppp for instance
Then again, ppp already knows about Netgraph, so if it's done as a netgraph
node, that might as well be converted =)
Does anything but ppp and natd use libalias?
>This (in my mind) should greatly enhance the throughput of FreeBSD's NAT and
>keep those Linux people from bashing us (or me, at least.)
Would be very nice indeed =)
BTW, I hereby volunteer as junior kernel hacker to help on this project. To
me NAT has been one of the strongpoints of FreeBSD (very nice features,
works very well with FTP/DCC/PPTP) and making it even better would be a
pleasure.
>--
>Matt Emmerton
Just my $0.02,
Doc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
Matthew Emmerton wrote:
>
> > Am 27.01.2002 um 02:11:30 schrieb Matthew Emmerton:
> >
> > Hi Matt,
> >
> > > Here's the patch that I wrote some time ago.
> >
> > thanks a lot!
> > Did you send-pr the patch? It seems quite necessary to be added.
>
> Not yet. One of the things that I don't like about this patch is that old
> rules still stay around (re-reading the configuration will only modify
> existing rules and add new rules.) I'm also taking a lot of flak on my side
> of the fence since NAT runs as a userland process, so every packet gets
> copied between the kernel and userland twice (once on the way in, once on
> the way out.) Apparently Linux doesn't do this.
>
> I'm looking at making natd into a kernel option ("options IPNAT") and using
> a combination of sysctls and a front-end program to manage how nat operates,
> much like "options IPFIREWALL" and ipfw works today.
Have a look at IPFILTER where IPNAT is part of. It does everything in
the kernel.
> This (in my mind) should greatly enhance the throughput of FreeBSD's NAT and
> keep those Linux people from bashing us (or me, at least.)
Profile, don't speculate. On today's machines you don't notice any
difference between userland vs. kernel NAT. I've tested FreeBSD's
userland natd and it could easily push 93Mbit/s through a Athlon-
1.4GHz (which is essentially wirespeed (FreeBSD 4.3)) with two fxp
cards.
--
Andre
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
You can also add rules that allow packets that are going over the INTERNAL
interface to skip the NAT divert rules.
then you'd only be doing it once.
On Sun, 27 Jan 2002, Andre Oppermann wrote:
> Matthew Emmerton wrote:
> >
> > > Am 27.01.2002 um 02:11:30 schrieb Matthew Emmerton:
> > >
> > > Hi Matt,
> > >
> > > > Here's the patch that I wrote some time ago.
> > >
> > > thanks a lot!
> > > Did you send-pr the patch? It seems quite necessary to be added.
> >
> > Not yet. One of the things that I don't like about this patch is that old
> > rules still stay around (re-reading the configuration will only modify
> > existing rules and add new rules.) I'm also taking a lot of flak on my side
> > of the fence since NAT runs as a userland process, so every packet gets
> > copied between the kernel and userland twice (once on the way in, once on
> > the way out.) Apparently Linux doesn't do this.
> >
> > I'm looking at making natd into a kernel option ("options IPNAT") and using
> > a combination of sysctls and a front-end program to manage how nat operates,
> > much like "options IPFIREWALL" and ipfw works today.
>
> Have a look at IPFILTER where IPNAT is part of. It does everything in
> the kernel.
>
> > This (in my mind) should greatly enhance the throughput of FreeBSD's NAT and
> > keep those Linux people from bashing us (or me, at least.)
>
> Profile, don't speculate. On today's machines you don't notice any
> difference between userland vs. kernel NAT. I've tested FreeBSD's
> userland natd and it could easily push 93Mbit/s through a Athlon-
> 1.4GHz (which is essentially wirespeed (FreeBSD 4.3)) with two fxp
> cards.
>
> --
> Andre
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
> (order of quoted mail slightly altered)
>
> >I'm looking at making natd into a kernel option ("options IPNAT") and
using
> >a combination of sysctls and a front-end program to manage how nat
operates,
> >much like "options IPFIREWALL" and ipfw works today.
I've been told that 'options IPFILTER' with ipf(8) and ipnat(8) does NAT in
the kernel, whereas 'options IPDIVERT' and ipfw(8) and natd(8) is a userland
solution.
> I've been kicking around the idea of making it a netgraph node. And I know
> several other people have too.
This is probably the easiest starting point.
> libalias is very nice, natd to me has a hackey feeling to it. Try setting
> up a firewall that nats and uses dynamic rules I haven't been able to,
> have had to rely on natd to do my state checking, resulting in ipfw rule
> lists that are not easily read by the layman. So maybe that's another
> reason to re-evaluate our current NAT solution.
See the alternatives above. Perhaps ipf might handle dynamic rules better?
( I don't know, since I've used ipfw since I started using FreeBSD.)
> Would it be hard to keep using libalias? I know we can't just link against
> userland libraries in kernel land, but would there be much difficulty in
> making use of the exact same code? Because the beauty of having libalias
is
> of course the -nat switch on ppp for instance
It would be nice to keep libalias functionality, since it is a very easy
interface to use.
> Does anything but ppp and natd use libalias?
A quick check of the sources says no.
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
On Sun, Jan 27, 2002 at 09:55:03AM -0500, Matthew Emmerton wrote:
> > Am 27.01.2002 um 02:11:30 schrieb Matthew Emmerton:
> >
> > Hi Matt,
> >
> > > Here's the patch that I wrote some time ago.
> >
> > thanks a lot!
> > Did you send-pr the patch? It seems quite necessary to be added.
>
> Not yet. One of the things that I don't like about this patch is that old
> rules still stay around (re-reading the configuration will only modify
> existing rules and add new rules.) I'm also taking a lot of flak on my side
> of the fence since NAT runs as a userland process, so every packet gets
> copied between the kernel and userland twice (once on the way in, once on
> the way out.) Apparently Linux doesn't do this.
>
> I'm looking at making natd into a kernel option ("options IPNAT") and using
> a combination of sysctls and a front-end program to manage how nat operates,
> much like "options IPFIREWALL" and ipfw works today.
That would be just great. A lot of people would benefit from this. I had to
switch to IPF/IPNAT because of the cpu load NATD had. But for some reason, I
find NATD to be a bit "better" than IPNAT (I'm having a lot of problems
with Audiogalaxy's satellite service running with ftp).
> This (in my mind) should greatly enhance the throughput of FreeBSD's NAT and
> keep those Linux people from bashing us (or me, at least.)
Sorry, I *was* one of them :)
veedee.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Netgraph
Julian Elischer writes:
> you need to attach the tty node to a tty using the regular
> terminal "line disciplin" methods.
> (similar to the way the ppp protocol handler is attached to a tty
> for kernel ppp)
Right.. you can only create an ng_tty node by installing it
as a line discipline, e.g., something like this:
#include
int fd, disc;
fd = open("/dev/cuaa0", O_RDWR);
disc = NETGRAPHDISC;
ioctl(fd, TIOCSETD, &disc);
...
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
Am 27.01.2002 um 18:43:11 schrieb Andre Oppermann: Hi Andre, > Have a look at IPFILTER where IPNAT is part of. It does everything in > the kernel. to come back to my initial question: is there a way to modify ipnat rules without breaking existing connections? tia /ch -- "Contrary to popular belief, Unix is user friendly. It just happens to be selective about who it makes friends with." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
Am 27.01.2002 um 09:59:14 schrieb Matthew Emmerton: Hi Matthew, > Why not just add an IP alias for the "new" network on each machine? Each > system will respond to packets directed to either network, but without the > complexity of a NAT box in the middle. Once you've got everything switched, > then you can remove the original IP addresses. Sounds like a way better solution as the one I thought of. Thanks a lot for this hint! > I've used this method in the > past to transition LANs between IP ranges and it works absolutely fine. Did you use Windows machines in this setup? There are many NT4 Boxes, Win2k, some 98 and 95 computers here. tia /ch -- "Contrary to popular belief, Unix is user friendly. It just happens to be selective about who it makes friends with." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
> Am 27.01.2002 um 09:59:14 schrieb Matthew Emmerton: > > Hi Matthew, > > > Why not just add an IP alias for the "new" network on each machine? Each > > system will respond to packets directed to either network, but without the > > complexity of a NAT box in the middle. Once you've got everything switched, > > then you can remove the original IP addresses. > > Sounds like a way better solution as the one I thought of. > Thanks a lot for this hint! > > > I've used this method in the > > past to transition LANs between IP ranges and it works absolutely fine. > > Did you use Windows machines in this setup? > There are many NT4 Boxes, Win2k, some 98 and 95 computers here. No, I used the alias trick on a bunch of UNIX and NT4 servers. All of the desktops on the LAN used DHCP so it was easy to change them. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: natd restart
On Sun, Jan 27, 2002 at 09:53:56PM +0100, Clemens Hermann wrote: > Am 27.01.2002 um 18:43:11 schrieb Andre Oppermann: > > Hi Andre, > > > Have a look at IPFILTER where IPNAT is part of. It does everything in > > the kernel. > > to come back to my initial question: is there a way to modify ipnat > rules without breaking existing connections? With ipnat(1)? Yes. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: netgraph: how to setsockopt on ksocket node ?
Archie do you want to check this in, or shall I? Florent Parent wrote: > > --On 2002-01-18 21:30:00 -0800 [EMAIL PROTECTED] wrote: > >> netgraph: sendto(.dummy): Bad address > > > > Hmm.. I wonder if the problem is that this has never worked :-) > > That would explain why I couldn't find any examples on using this ;-) > > > That is, maybe setsockopt() is expecting the value pointer to point > > into user memory, while ng_ksocket is using a pointer that points > > into kernel memory? > > > > In which case, I don't know how to go about fixing it.. Julian? > > This is what I did to make it work for me. A better fix would probably be > around the struct proc definition. If fact, you had noted "broken" > probably as a memo to fix something here... > > struct proc *p = curproc ? curproc : &proc0;/* XXX broken */ > > *** ng_ksocket.c.orig Sat Jan 19 11:05:28 2002 > --- ng_ksocket.cSat Jan 19 11:45:23 2002 > *** > *** 759,765 > sopt.sopt_name = ksopt->name; > sopt.sopt_val = ksopt->value; > sopt.sopt_valsize = valsize; > ! sopt.sopt_p = p; > error = sosetopt(so, &sopt); > break; > } > --- 759,765 > sopt.sopt_name = ksopt->name; > sopt.sopt_val = ksopt->value; > sopt.sopt_valsize = valsize; > ! sopt.sopt_p = 0; > error = sosetopt(so, &sopt); > break; > } > > Florent. > -- > Florent Parent > Viagénie http://www.viagenie.qc.ca -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
