IPSTEALTH - transparent router
Hi. I have many routers with wavelan card working with freeBSD and i am trying without sucessfull use IPSTEALTH work this is my kernel options options IPFIREWALL options IPDIVERT options IPSTEALTH options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=100 options DUMMYNET options NMBCLUSTERS=10240 i have some routes and i use ipfw fwd too i want whem one machine make traceroute dont show my router and go a way Thank for any help Romualdo Arcoverde UNINet Brasilia http://unimail.unisys.com.br To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Dummynet problem
I tried to configure dummynet to allow for normal work when downloading files using queue mechanism (4.2-STABLE). IPFW rules are: add 100 queue 10 tcp from any to any uid dnld1 in add 200 queue 11 ip from any to any queue 10 config weight 1 pipe 1 queue 11 config weight 10 pipe 1 mask all pipe 1 config bw 128Kbit/s sysctl net.inet.ip.fw.one_pass is set to 1 Although the counters for both (100 and 200) rules show that they both are hit during two parallel downloads (one by user dnld1), the bandwidth for both is equal. It should not be, I guess. Is it a bug or maybe I've misconfigured something. All the best in New Year, /S To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ipfw uid rules and matching specific services for bandwidth limiting
Hello, Are people actually using uid type rules heavily? I'm having trouble matching the packets generated by programs like Apache and ProFTPD. I believe that may be because of root binding the ports these programs use before they setuid() or something, I'm not sure. Particularly I have trouble matching the packets of active FTP, since I have random ports on both ends to deal with and can't match them by port either. Does anyone have a solution to this? Yep, this is for use with Dummynet, which works OK as long as I get to match the packets I need. :-) ProFTPD's mod_xfer module doesn't seem to be able to globally set a max. transfer rate for all transfers in total either, it seems. I suppose I can proxy the traffic and then match the packets somehow perhaps.. Cheers, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipfw uid rules and matching specific services for bandwidth limiting
On Mon, Jan 01, 2001 at 09:08:26PM +0100, Anders Nordby wrote: > Are people actually using uid type rules heavily? I'm having trouble matching > the packets generated by programs like Apache and ProFTPD. I believe that may > be because of root binding the ports these programs use before they setuid() or > something, I'm not sure. Particularly I have trouble matching the packets of > active FTP, since I have random ports on both ends to deal with and can't match > them by port either. Does anyone have a solution to this? sockstat is your friend, look at the 'user' that is defined per program, thats who is going to be charged for packets on that socket. -- Bill Fumerola - security yahoo / Yahoo! inc. - [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipfw uid rules and matching specific services for bandwidth limiting
On Mon, Jan 01, 2001 at 05:24:09PM -0600, Bill Fumerola wrote: >> Are people actually using uid type rules heavily? I'm having trouble matching >> the packets generated by programs like Apache and ProFTPD. I believe that may >> be because of root binding the ports these programs use before they setuid() or >> something, I'm not sure. Particularly I have trouble matching the packets of >> active FTP, since I have random ports on both ends to deal with and can't match >> them by port either. Does anyone have a solution to this? > sockstat is your friend, look at the 'user' that is defined per program, > thats who is going to be charged for packets on that socket. Nope, doesn't seem to work. Sockstat says: USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS ftp proftpd 751820 tcp4 10.0.0.8:21 192.168.0.34:4955 ftp proftpd 751821 tcp4 10.0.0.8:21 192.168.0.34:4955 ftp proftpd 75182 12 tcp4 10.0.0.8:478 192.168.0.34:4959 ftp proftpd 75182 13 tcp4 10.0.0.8:478 192.168.0.34:4959 nobody proftpd 688200 tcp4 *:21 *:* Then I add a rule to see if I can count the packets while the above mentioned session is kept alive: # ipfw add 00010 count all from any to any uid ftp And ipfw show shows that the rule doesn't intercept any packets: 000100 0 count ip from any to any uid ftp FYI I am running 4.1.1-STABLE as of Tue Oct 24 01:25:55 CEST 2000, and top(1) shows all proftpd processes as being owned by root. Regards, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipfw uid rules and matching specific services for bandwidth limiting
On Tue, Jan 02, 2001 at 01:14:18AM +0100, Anders Nordby wrote: > FYI I am running 4.1.1-STABLE as of Tue Oct 24 01:25:55 CEST 2000, and top(1) > shows all proftpd processes as being owned by root. If I filter on uid root, the rules will match the packets (I tried with specific IPs + uid root): 00010 15392307193 count log ip from any to 192.168.0.34 uid root 00011 881 35259 count log ip from 192.168.0.34 to any uid root But then again filtering on uid root is not what I want -- it will match ssh sessions and other things as well. And then I'm back to start.. Regards, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problems with VLAN and natd.
On Sun, 31 Dec 2000 19:54:19 PST, Julian Elischer wrote: > > The current VLAN (and Ethernet) implementaiton in FreeBSD needs work. > > FreeBSD should should handle multiple ethernet encapsulations on > > the same physical interface, and relay packets to/from some subordinate > > interface. This support would factor-out the need for current > > work-arounds like if_vlan, and if_ef, and perhaps even if_tap. > > sounds like a perfect use for netgraph.. I've thought about this, and and a migation to netgraph would require significant changes to how FreeBSD handles Ethernet (and other IEEE 802) interfaces. For example, you would no longer simply ``ifconfig xl'', but associate a netgraph link-layer node on top of the xl interface, and a netgraph interface node on top of the link-layer node, which would function (mostly) like xl does now. Netgraph is an excellent technology. While your comment makes sense, there are several issues that will need to be addressed. For instance, the current ARP implementation in FreeBSD is entangled with the generic ethernet code. I'm afraid to even contemplate the POLA and backward compatability issues involved. If this discussion is non-casual, we should eventually migrate it over to -arch. - Steve -- C. Stephen Gunn URL: http://www.waterspout.com/ WaterSpout Communications, Inc.Email: [EMAIL PROTECTED] 427 North 6th Street Phone: +1 765.742.6628 Lafayette, IN 47901 Fax: +1 765.742.0646 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problems with VLAN and natd.
On Tue, 2 Jan 2001, C. Stephen Gunn wrote: > For example, you would no longer simply ``ifconfig xl'', but > associate a netgraph link-layer node on top of the xl interface, > and a netgraph interface node on top of the link-layer node, which > would function (mostly) like xl does now. Interesting. Possibly that would make freebsd move away from hardware-specific interface names (such as xl0, rl0 ) and make them eth0, eth1, with a generic eth link-layer code to take care of things like ARP and bridging? Would that make sense? Essentially, what an ethernet driver will do is just capturing and sending packets. Then, netgraph "ethllcmac" node attached to it would perform all VLAN tagging/decapsulation and expose a [set of] eth interfaces back to the kernel? I'm thinking of something like this: ngctl mkpeer xl0: ethmacllc raw raw ngctl mkpeer xl0:raw:untagged iface ifconfig ng0 ngctl mkpeer xl0:raw:vlan3 iface ifconfig ng1 (the first might have to be set up to be executed on-interface-load) I'm still a bit inebriated...Let me know if I'm completely off-base) > Netgraph is an excellent technology. While your comment makes > sense, there are several issues that will need to be addressed. > For instance, the current ARP implementation in FreeBSD is > entangled with the generic ethernet code. > I'm afraid to even contemplate the POLA and backward compatability > issues involved. I'm afraid to ask, what's POLA? :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPSTEALTH - transparent router
Hello, > I have many routers with wavelan card working with freeBSD and i am > trying without sucessfull use IPSTEALTH work i want whem one machine > make traceroute dont show my router and go a way sysctl -w net.inet.ip.stealth=1 -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipfw uid rules and matching specific services for bandwidth limiting
the easy way could be (probably) force the ftp daemon run as some other user, or assign a second IP to the server and make sure that the ftpd binds to the second address. But in the end, one probably might also like to have a separate namespace where processes can [be forced to] register and whose values can be used as keys by the various resource allocators (dummynet is just an example, one might want to do the same thing with filesystem clients) cheers luigi > > FYI I am running 4.1.1-STABLE as of Tue Oct 24 01:25:55 CEST 2000, and top(1) > > shows all proftpd processes as being owned by root. > > If I filter on uid root, the rules will match the packets (I tried with > specific IPs + uid root): > > 00010 15392307193 count log ip from any to 192.168.0.34 uid root > 00011 881 35259 count log ip from 192.168.0.34 to any uid root > > But then again filtering on uid root is not what I want -- it will match > ssh sessions and other things as well. And then I'm back to start.. > > Regards, > > -- > Anders. > > > 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: Dummynet problem
> I tried to configure dummynet to allow for normal work when downloading files > using queue mechanism (4.2-STABLE). > > IPFW rules are: > > add 100 queue 10 tcp from any to any uid dnld1 in > add 200 queue 11 ip from any to any > > queue 10 config weight 1 pipe 1 > queue 11 config weight 10 pipe 1 mask all > > pipe 1 config bw 128Kbit/s > > sysctl net.inet.ip.fw.one_pass is set to 1 > > Although the counters for both (100 and 200) rules show that they both are hit > during two parallel downloads (one by user dnld1), the bandwidth for both is > equal. It should not be, I guess. Is it a bug or maybe I've misconfigured > something. it should not be equal provided the 'high weight' flow has sufficient traffic going. Of course bugs are always possible, but i think i checked that the mechanism did work before committing. Can you do an 'ipfw zero' before the transfer, and provide the output of ipfw show ipfw queue show ipfw pipe show after that ? cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problems with VLAN and natd.
"C. Stephen Gunn" wrote: > > On Sun, 31 Dec 2000 19:54:19 PST, Julian Elischer wrote: > > > > The current VLAN (and Ethernet) implementaiton in FreeBSD needs work. > > > FreeBSD should should handle multiple ethernet encapsulations on > > > the same physical interface, and relay packets to/from some subordinate > > > interface. This support would factor-out the need for current > > > work-arounds like if_vlan, and if_ef, and perhaps even if_tap. > > > > sounds like a perfect use for netgraph.. > > I've thought about this, and and a migation to netgraph would > require significant changes to how FreeBSD handles Ethernet (and > other IEEE 802) interfaces. > > For example, you would no longer simply ``ifconfig xl'', but > associate a netgraph link-layer node on top of the xl interface, > and a netgraph interface node on top of the link-layer node, which > would function (mostly) like xl does now. > > Netgraph is an excellent technology. While your comment makes > sense, there are several issues that will need to be addressed. > For instance, the current ARP implementation in FreeBSD is > entangled with the generic ethernet code. Under netgraph, it would be just another protocol in a netgraph node, and could be added to (and removed from) the interface as needed. That would be interesting from the standpoint of a secure system over which you wanted to control the ARP entries. Being able to simply turn off dynamic ARP has been discussed often, but never really acted upon. Doing link-layer encapsulation modules is really not very difficult. I've written pretty much the full complement, covering ethernet (10, 100, and 1000), FDDI/CDDI, token ring, ATM, and Frame Relay. (Chuck, I can identify that protocol in 20 instructions.) > I'm afraid to even contemplate the POLA and backward compatability > issues involved. Why would we need to violate POLA? The obvious default would be to extend ifconfig to configure the new protocol types, and to assume EthII framing unless explicitly specified. > If this discussion is non-casual, we should eventually migrate > it over to -arch. Perhaps so. If someone does the work to move EthII into netgraph, I can certainly contribute a SNAP/LLC module, and maybe even extensions to ifconfig so you can use it. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problems with VLAN and natd.
Wes Peters wrote: > > "C. Stephen Gunn" wrote: > > > > Netgraph is an excellent technology. While your comment makes > > sense, there are several issues that will need to be addressed. > > For instance, the current ARP implementation in FreeBSD is > > entangled with the generic ethernet code. > > Under netgraph, it would be just another protocol in a netgraph node, > and could be added to (and removed from) the interface as needed. That > would be interesting from the standpoint of a secure system over which > you wanted to control the ARP entries. Being able to simply turn off > dynamic ARP has been discussed often, but never really acted upon. Sorry to reply to my own message, but another thought hit me. Now that the swelling has gone down, I thought I should share it: This might even give us a start at a sticky problem that has been bugging VLAN switch makers from the start, namely, per-VLAN ARP tables. That is something really needed to do VLANs correctly. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problems with VLAN and natd.
Wes Peters wrote: > [SNIP] > > Doing link-layer encapsulation modules is really not very difficult. > I've written pretty much the full complement, covering ethernet (10, > 100, and 1000), FDDI/CDDI, token ring, ATM, and Frame Relay. (Chuck, What about a netgraph-enabled ATM NIC driver ? (this seems the missing piece to get bridged Ethernet over RFC1483 encapsulation on ATM) [SNAP] > > Perhaps so. If someone does the work to move EthII into netgraph, I can > certainly contribute a SNAP/LLC module, and maybe even extensions to > ifconfig so you can use it. ;^) > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > [EMAIL PROTECTED] http://softweyr.com/ -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPSTEALTH - transparent router
Hello, ( > Attila Nagy) > > I have many routers with wavelan card working with freeBSD and i am > > trying without sucessfull use IPSTEALTH work i want whem one machine > > make traceroute dont show my router and go a way > sysctl -w net.inet.ip.stealth=1 ...or you can live happy with IPFilter's fastroute feature, that does exactly what you want. -- __ o _. __ / / / (_(_(__(_) @ bsd.hu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
IP Filter auth rule
Hi, I\'m playing around the auth rule and the sample userauth.c of
IP Filter on FreeBSD 4.2-RELEASE and below are some results and
questions:
1. There is a typo in ip_auth.c which causes the ioctl(SIOCAUTHW)
unable to fetch all the fields of the frauth_t struct. Below is
a patch for 4.2-RELEASE stock version 3.4.8:
*** /sys/netinet/ip_auth.c Sat Dec 30 22:38:09 2000
--- /sys/netinet/ip_auth.c.orig Sat Dec 30 23:35:33 2000
***
*** 354,358
if ((fr_authnext != fr_authend) && fr_authpkts[fr_authnext])
{
error = IWCOPYPTR((char *)&fr_auth[fr_authnext],
data,
! sizeof(frauth_t));
RWLOCK_EXIT(&ipf_auth);
if (error)
--- 354,358
if ((fr_authnext != fr_authend) && fr_authpkts[fr_authnext])
{
error = IWCOPYPTR((char *)&fr_auth[fr_authnext],
data,
! sizeof(fr_info_t));
RWLOCK_EXIT(&ipf_auth);
if (error)
2. userauth.c should open IPAUTH_NAME instead of IPL_NAME for ioctl.
Maybe on other platforms it should be IPL_NAME?
3. It seems that \"keep state\" does not work for auth rules. For
example,
the rule:
auth in proto tcp from any to 127.0.0.1/32 port = telnet keep
state
makes every incoming telnet packet to go through the
authentication
despite the \"keep state\" option.
4. \"auth out ...\" rule does not work :-(. It makes the system hang
for a
while and then reboot.
5. auth in IP Filter 3.4.15 does not work in FreeBSD 4.2-RELEASE. The
authenticated packets nerver reach the destination even though the
variable fr_authstats.fas_queok increase as normal. I built the
KLD
module as follow:
# make freebsd4
# make install-bsd
# kldload ipf
Any hints?
Regards,
Song Bo Run
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Problems with VLAN and natd.
Wes Peters wrote: > > Thierry Herbelot wrote: > > > > Wes Peters wrote: > > > > > [SNIP] > > > > > > Doing link-layer encapsulation modules is really not very difficult. > > > I've written pretty much the full complement, covering ethernet (10, > > > 100, and 1000), FDDI/CDDI, token ring, ATM, and Frame Relay. (Chuck, > > > > What about a netgraph-enabled ATM NIC driver ? (this seems the missing > > piece to get bridged Ethernet over RFC1483 encapsulation on ATM) > > If the top of all the network interface drivers is a netgraph connection, we agree on it : FreeBSD needs a netgraphified hfa(4) : I've seen one or two trys to get it done (the trouble is not many of our commiters know well enough both ATM and netgraph to actually do it, and the ones who do are so busy with other, more interesting challenges) TfH PS : at one time, I would even have tried getting some money from my company to pay a consultant do it (there are not many of them in France, though) > any encapsulation should be straightforward. In the Xylan switch, we At work, I'm using a 1100 LSS : is it the same as the one you worked on ? > actually did the conversion on the outbound network interface module, > so the packet was never converted unless it had to be. We could mimic > that behavior, assuming the output device would check the packet to > see if it needs to be converted, and if so call a module to strip it > down to the bare packet, then another to add the correct encapsulation. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > [EMAIL PROTECTED] http://softweyr.com/ -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
