Re: kern/80642: [patch] IPFW small patch - new RULE OPTION
The following reply was made to PR kern/80642; it has been noted by GNATS.
From: "Andrey V. Elsukov" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/80642: [patch] IPFW small patch - new RULE OPTION
Date: Fri, 17 Jun 2005 14:31:20 +0400
This is a multi-part message in MIME format.
--020602060206080505060104
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Robert Watson wrote:
> This patch breaks the ABI by inserting a new type into an implicitly
> numbered enumeration, renumbering all entries later in the enum.
> O_BOUND, if added, should be appended to the end, and/or we should
> number the operations explicitly.
Ok. I have corrected this.
* ipfw_bound.diff - the patch with smallest changes, with only bound option.
* ipfw_bound2.diff - bound and check-bound option.
Examples:
We can limit incoming traffic (internet is external interface):
# ipfw add allow ip from any to 10.0.0.20 in recv internet bound 10MB
# ipfw add deny ip from any to 10.0.0.0/24 in recv internet
We can use traffic shaper after excess of a limit:
# ipfw add allow ip from any to 10.0.0.20 in recv internet bound 10MB
# ipfw add pipe 1 ip from any to 10.0.0.20 in recv internet
# ipfw pipe 1 config bw 5Kbit/s queue 10Kbytes
We can block any access after limit excess:
# ipfw add 100 allow ip from 10.0.0.20 to any out xmit internet \
check-bound 200
# ipfw add 200 allow ip from any to 10.0.0.20 in recv internet bound \ 10MB
# ipfw add 300 deny ip from any to any
More details you can read on http://butcher.heavennet.ru/
--
WBR, Andrey V. Elsukov
--020602060206080505060104
Content-Type: text/plain;
name="ipfw_bound.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ipfw_bound.diff"
--- sbin/ipfw/ipfw2.c Tue Jun 7 18:11:17 2005
+++ sbin/ipfw/ipfw2.c Fri Jun 17 13:09:43 2005
@@ -277,6 +277,7 @@
TOK_SRCIP6,
TOK_IPV4,
+ TOK_BOUND,
};
struct _s_x dummynet_params[] = {
@@ -403,6 +404,7 @@
{ "dst-ip6",TOK_DSTIP6},
{ "src-ipv6", TOK_SRCIP6},
{ "src-ip6",TOK_SRCIP6},
+ { "bound", TOK_BOUND},
{ "//", TOK_COMMENT },
{ "not",TOK_NOT }, /* pseudo option */
@@ -1858,6 +1860,10 @@
print_ext6hdr( (ipfw_insn *) cmd );
break;
+ case O_BOUND:
+ printf(" bound %u", ((ipfw_insn_u64
*)cmd)->bound);
+ break;
+
default:
printf(" [opcode %d len %d]",
cmd->opcode, cmd->len);
@@ -2515,7 +2521,7 @@
" icmp6types LIST | ext6hdr LIST | flow-id N[,N] |\n"
" mac ... | mac-type LIST | proto LIST | {recv|xmit|via} {IF|IPADDR} |\n"
" setup | {tcpack|tcpseq|tcpwin} NN | tcpflags SPEC | tcpoptions SPEC |\n"
-" tcpdatalen LIST | verrevpath | versrcreach | antispoof\n"
+" tcpdatalen LIST | verrevpath | versrcreach | antispoof | bound VALUE\n"
);
exit(0);
}
@@ -3683,6 +3689,7 @@
int i;
int open_par = 0; /* open parenthesis ( */
+ int have_bound = 0;
/* proto is here because it is used to fetch ports */
u_char proto = IPPROTO_IP; /* default protocol */
@@ -4492,6 +4499,33 @@
fill_comment(cmd, ac, av);
av += ac;
ac = 0;
+ break;
+
+ case TOK_BOUND:
+ NEED1("bound requires numeric value");
+ if (have_bound)
+ errx(EX_USAGE, "only one of bound is allowed");
+ if (open_par)
+ errx(EX_USAGE, "bound cannot be part "
+ "of an or block");
+ if (cmd->len & F_NOT)
+ errx(EX_USAGE,
+ "\"not\" not allowed with bound option");
+ {
+ char *end = NULL;
+ uint64_t bound = strtoull(*av, &end, 0);
+ if (bound)
+ switch (*end){
+ case 'G': bound *= 1024;
+ case 'M': bound *= 1024;
+ case 'K': bound *= 1024;
+
Re: ipfw+altq
vladone wrote: Hi! I have an frebsd 5.4 release system. I want to use ipfw+altq. I read I try'it with this optins presented (and PF enabled), and when i give "ipfw enable altq", i receive an error, about unknow option "altq". You must update your system to RELENG_5. In 5.4-RELEASE ipfw's ALTQ not supported. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nonprivileged access to ipfw
Hi All!
I want a nonprivileged access to ipfw (without sudo, suid and etc..).
But RAW sockets restrict this. I have an one idea - a pseudo device
/dev/ipfw. I think that realisation of this feature is not
difficult task. Now i have some questions.
1. I think correctly about following?
* adding cdevsw declaration with ipfw_ioctl implementation;
* adding make_dev into ipfw initialization function (on MOD_LOAD event);
* adding destroy_dev (on MOD_UNLOAD);
* adding needed functionaly into /sbin/ipfw.
2. About ipfw_ioctl implemetation:
I can pack an ioctl params into sockopt structure and directly call
ipfw_ctl function. It's ok?
3. About ioctl requests - What symbol I should place into definition of
ioctl request? On what it depends? For example:
#define DIOCCLRSTATES _IOWR('D', 18, struct pfioc_state_kill)
>>-^
4. I can define only two ioctl requests, for example:
IPFWIOCSCMD _IOW('x', 0, struct sockopt_like_struct)
IPFWIOCGCMD _IOR('x', 1, struct sockopt_like_struct)
and pass IP_FW_XXX sockoption's into sockopt_like_struct member,
or I should define two definition (set/get) for each IP_FW_XXX option?
Thanks and sorry for my english :(
--
WBR, Andrey V. Elsukov
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nonprivileged access to ipfw
Andrey V. Elsukov wrote: I want a nonprivileged access to ipfw (without sudo, suid and etc..). But RAW sockets restrict this. I have an one idea - a pseudo device /dev/ipfw. I think that realisation of this feature is not difficult task. Now i have some questions. Thanks for more answers :) I has finished this. But i have one question, how to I should act with a dummynet code? Through a pseudo device /dev/ipfwctl we can control an ipfw state. The access to ipfwctl device can be configured via devfs.conf. User must have a write permissions to /dev/ipfwctl for change ipfw state and a read permissions for read ipfw state. Patch can be found here: http://butcher.heavennet.ru/ipfw_ioctl/ -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: limited logging when using limit
Arvinn wrote:
ipfw add pipe 5 log tcp from 200.0.0.0/7 to me dst-port 25 limit src-addr 2
ipfw add allow log tcp from any to me dst-port 25 limit src-addr 10
All I get in syslog is:
Sep 30 11:14:40 hostname drop session, too many entries
You can try this patch. ipfw will be logging a session drops like following:
Oct 4 14:15:44 hostname kernel: ipfw: drop session, too many entries
(by rule 200)
--
WBR, Andrey V. Elsukov
--- sys/netinet/ip_fw2.c.orig Mon Sep 13 11:21:17 2004
+++ sys/netinet/ip_fw2.cTue Oct 4 14:18:51 2005
@@ -1090,7 +1090,8 @@
if (fw_verbose && last_log != time_second) {
last_log = time_second;
log(LOG_SECURITY | LOG_DEBUG,
- "drop session, too many entries\n");
+ "ipfw: drop session, too many
entries (by rule %d)\n",
+ rule->rulenum);
}
return 1;
}
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/87032: [PATCH] ipfw ioctl interface implementation
The following reply was made to PR kern/87032; it has been noted by GNATS.
From: "Andrey V. Elsukov" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/87032: [PATCH] ipfw ioctl interface implementation
Date: Wed, 12 Oct 2005 08:36:51 +0400
This is a multi-part message in MIME format.
--050604070508040903090904
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Related with the jail the addition patch.
Full last version of the patch can be found on the URL
http://butcher.heavennet.ru/ipfw_ioctl/
--050604070508040903090904
Content-Type: text/plain;
name="netinet.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="netinet.diff"
--- sys/netinet/ip_dummynet.c.orig Tue Oct 11 16:33:13 2005
+++ sys/netinet/ip_dummynet.c Wed Oct 12 08:01:24 2005
@@ -88,6 +88,7 @@
#ifdef DEV_DNCTL
#include
#include
+#include
#include
static d_ioctl_t ip_dn_ioctl;
@@ -2119,6 +2120,9 @@
size_t size;
struct ip_dummynet_ctl* ctl = (struct ip_dummynet_ctl*)data;
+ if (jailed(td->td_ucred)) {
+ return EPERM;
+ }
switch(cmd) {
case IPDNIOCSCMD:
if ((fflag & FWRITE) != FWRITE) {
--- sys/netinet/ip_fw2.c.orig Tue Oct 11 16:19:32 2005
+++ sys/netinet/ip_fw2.c Wed Oct 12 07:58:55 2005
@@ -4127,6 +4127,9 @@
size_t size;
struct ip_fw_ctl* ctl = (struct ip_fw_ctl*)data;
+ if (jailed(td->td_ucred)) {
+ return EPERM;
+ }
switch(cmd) {
/*
* IPFWIOCSCMD makes some modifications of ipfw's state
--050604070508040903090904--
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dynamically adding ipfw & natd rule
Alessandro Parrinello wrote: Hi, i need to change the natting rules of natd by a c program dynamically based on information gived me by a server. How can i do this? If you speak about an ipfw divert rules, then you can see the sbin/ipfw source code as example. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/60154: [ipfw] ipfw core (crash)
The following reply was made to PR kern/60154; it has been noted by GNATS.
From: "Andrey V. Elsukov" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: kern/60154: [ipfw] ipfw core (crash)
Date: Thu, 08 Dec 2005 08:58:02 +0300
This is a multi-part message in MIME format.
--080701000609020709080702
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
The following patch can fix this error for CURRENT.
--
WBR, Andrey V. Elsukov
--080701000609020709080702
Content-Type: text/plain;
name="pr-60154.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="pr-60154.diff"
--- ipfw2.c.orig Thu Dec 8 01:51:14 2005
+++ ipfw2.cThu Dec 8 01:54:59 2005
@@ -2641,6 +2641,14 @@
int masklen;
char md;
+ if (len > 30) {
+ /*
+ * O_IP_SRC_MASK and O_IP_DST_MASK can't have length
+ * greater than 31
+ */
+ errx(EX_DATAERR, "too many addresses");
+ }
+
if (p) {
md = *p;
*p++ = '\0';
--080701000609020709080702--
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/60154: [ipfw] ipfw core (crash)
Maxim Konovalov wrote:
Synopsis: [ipfw] ipfw core (crash)
http://www.freebsd.org/cgi/query-pr.cgi?pr=60154
I have updated patch and make the perl script for testing.
--
WBR, Andrey V. Elsukov
#!/usr/local/bin/perl -w
#===
#
# FILE: test.pl
# DESCRIPTION: ipfw parser test
# AUTHOR: (c) Andrey V. Elsukov, <[EMAIL PROTECTED]>
# CREATED: 16.12.2005 06:05:09 UTC
#===
use strict;
sub result
{
if ($? == -1) {
print "ipfw failed to execute: $!\n";
} elsif ($? & 127) {
printf "ipfw died with signal %d, %s coredump\n",
($? & 127), ($? & 128) ? 'with':'without';
} else {
printf "ipfw exited with value %d\n", $? >> 8;
}
}
sub ip($$)
{
my $dig = shift;
my $separator = shift;
my $str;
$str .= "10.0.0.$_$separator" foreach(1..$dig-1);
$str .= "10.0.0.$dig";
return $str;
}
sub port($$)
{
my $dig = shift;
my $separator = shift;
my $str;
$str .= "$_$separator" foreach(1..$dig-1);
$str .= $dig;
return $str;
}
my $rule;
my @cnt = (5, 10, 25, 50, 100, 250, 500);
my @tests = (
{ description => "protocols",
rule => "allow {\$ } from any to any",
func => \&port, separator => ' or ' },
{ description => "source addresses (or block)",
rule => "allow ip from { \$ } to any",
func => \&ip, separator => ' or ' },
{ description => "source addresses (list)",
rule => "allow ip from { \$ } to any",
func => \&ip,
separator => ',' },
{ description => "source addresses (sets)",
rule => "allow ip from 10.0.0.0/24{\$} to any",
func => \&port,
separator => ',' },
{ description => "source ports (list)",
rule => "allow ip from 10.0.0.1 \$ to any",
func => \&port,
separator => ',' },
{ description => "destination addresses (or block)",
rule => "allow ip from any to { \$ }",
func => \&ip,
separator => ' or ' },
{ description => "destination addresses (lists)",
rule => "allow ip from any to { \$ }",
func => \&ip,
separator => ',' }
);
foreach my $test (@tests) {
print "Check with multiple ", $test->{description}, ":\n";
foreach my $c (@cnt) {
print "try $c count ... ";
my $rule = $test->{rule};
my $substr = $test->{func}($c, $test->{separator});
$rule =~ s/\$/$substr/;
# print "ipfw -q add $rule\n";
system("ipfw -q add $rule");
&result();
}
}
--- ipfw2.c.origTue Dec 13 12:16:02 2005
+++ ipfw2.c Fri Dec 16 11:39:44 2005
@@ -83,6 +83,26 @@
#define NEED1(msg) {if (!ac) errx(EX_USAGE, msg);}
/*
+ * Some functions here get as argumet an ipfw_insn pointer
+ * and fills him. This pointer typically stored in statical
+ * buffer with fixed size. And some ipfw_insn can have a
+ * variable size (for example, ipfw_insn_u16, ipfw_insn_u32,..).
+ * Free left space of this buffers do not controlled.
+ * As result we have some stange core dumps when user try
+ * add rules. To fix this errors we add the "size_left"
+ * paramter to thises functions. size_left indicates which
+ * size we can write into buffer. Before any writes we
+ * must check this size and update him after each write.
+ *
+ */
+#define CHECK_SIZE(size) \
+ { \
+ if ((int)(size_left - (size)) < 0) \
+ errx(EX_DATAERR, "too big rule size\n"); \
+ }
+#define UPDATE_SIZE(size) size_left -= (size)
+
+/*
* _s_x is a structure that stores a string <-> token pairs, used in
* various places in the parser. Entries are stored in arrays,
* with an entry with s=NULL as terminator.
@@ -777,12 +797,14 @@
* Fill the body of the command with the list of port ranges.
*/
static int
-fill_newports(ipfw_insn_u16 *cmd, char *av, int proto)
+fill_newports(ipfw_insn_u16 *cmd, char *av, int proto, int size_left)
{
Re: FreeBSD 6.0 Buffer Overrrun System Crash
John B. Wood wrote: After several minutes of operating as expected the system crashes with the kernel message "em0: RX overrun" and the system has to be rebooted. You can try update your 6.0 system to the lastest RELENG_6 branch. em(4) driver now have more changes, may be this would help to you. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[patch] ipfw packet tagging
Hi, All! I have written a small patch for a packets tagging with ipfw. The description of OpenBSD packet tagging is here: http://www.openbsd.org/faq/pf/tagging.html An IPFW tags is not compatible with PF tags. This feature can be usable with some netgraph modules. We can create a netgraph node that marks packets with some tags and use this node with other nodes. IPFW can detect and filter packets with tags. Also we can mark packets before NAT and detect tagged packets after translation. NAT based on divert sockets do not allow this, but i think ng_nat can.. Patches can be found here: http://butcher.heavennet.ru/patches/kernel/ipfw_tags/ -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw + nat
mufalani wrote: How to redirect requisitions at 80?s port (200.X.X.X:80) > to address (192.x.x.x:80) with nat and ipfw? You can try following: # natd -alias_address 200.X.X.X -redirect_port tcp 192.x.x.x:80 80 # ipfw add divert natd tcp from any to 200.X.X.X in recv $ExtIf # ipfw add divert natd tcp from 192.x.x.x 80 to any out xmit $ExtIf $ExtIf - external interface. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [fbsd] [patch] ipfw packet tagging
Jeremie Le Hen wrote: trip through the kernel. Would it be possible to slightly modify the routing code in order to make those tags a routing criteria ? You can use tags with a fwd rules, like a: # ipfw add fwd $gw_addr ip from any to any tagged $N And as i know, oleg@ has committed a new patch that uses a tableargs feature with ipfw_tags to CURRENT: http://docs.freebsd.org/cgi/mid.cgi?200606150939.k5F9dMrB019958 -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
The following reply was made to PR kern/80642; it has been noted by GNATS. From: "Andrey V. Elsukov" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION Date: Tue, 27 Jun 2006 16:39:21 +0400 I think this PR can be closed. I don't see any interest in him among committers. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly
The following reply was made to PR bin/102422; it has been noted by GNATS. From: "Andrey V. Elsukov" <[EMAIL PROTECTED]> To: "Stephen E. Halpin" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], Oleg Bulyzhin <[EMAIL PROTECTED]>, Gleb Smirnoff <[EMAIL PROTECTED]>, Luigi Rizzo <[EMAIL PROTECTED]> Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly Date: Mon, 28 Aug 2006 14:26:36 +0400 Stephen E. Halpin wrote: > processing, and it worked fine. I still have a question about PR 91245, > as when I went to the following page: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ > > and it looks like the last version of ipfw2.c is 1.96 on the MAIN > branch, and the changes in PR 91245 are not there. It would be awesome > if all three fixes could make it into the 6.2 release! This PR was closed by rev. 1.88 in CURRENT, and rev. 1.76.2.10 in RELENG_6, and will be in 6.2-RELEASE. But i don't know about this PR. Gleb, Oleg - any comments? :) -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: maximum deny entries?
Jin Guojun [VFFS] wrote: I am not sure if this is a bug or is there some limitation for total deny entry, when the deny list exceeds a certain length (36 lines at this case), ipfw stop working (see the *** line below). # ipfw list ...all non deny entries are removed 00361 deny ip from 202.124.17.215 to any ... 00364 deny ip from 71.135.96.85 to any 00364 deny ip from 71.135.41.68 to any 00364 deny ip from 71.135.35.252 to any 00364 deny ip from 71.135.178.215 to any First, try an ipfw logging rules for each rule and at the end of rules. Second, you can use ipfw tables and replace all your rules with one. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw buffers too small?
Hi, John > >It seems that the buffer sizes inside ipfw did not keep up with its >possible uses. If I run this: Some time ago i've look at this problem and tried to write a patch for kern/60154. You can found my patches in ipfw@ mail-list archive. http://freebsd.rambler.ru/bsdmail/freebsd-ipfw_2005/msg00634.html -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A bit weird code
Roman Bogorodskiy wrote: I was reading ipfw sources and spotted such line (sbin/ipfw/ipfw2.c, line 4871): err(EX_UNAVAILABLE, "getsockopt(%s)", "IP_FW_ADD"); And it's there since 1.1 revision of this file. I wonder it has some sacred meaning or just a typo. I don't see this code at this line :) If you mean this code: if (do_cmd(IP_FW_ADD, rule, (uintptr_t)&i) == -1) err(EX_UNAVAILABLE, "getsockopt(%s)", "IP_FW_ADD"); I think this is "copy&paste" bug :) -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adding opcode in ipfw_opcodes
[EMAIL PROTECTED] wrote: The problem is, i used this opcodes in ipfw2.c value . When i compile the ipw2.c the compiler generate the erro undefined value (first use in this function) for the two added opcodes for the other opcodes gcc doesn't gives the error. You can try add -I/usr/src/sys/netinet to CFLAGS or replace /usr/include/netinet/ip_fw.h with a new ip_fw.h. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/103454: [ipfw] [patch] add a facility to modify DF bit of the IP packet
Roman Bogorodskiy wrote:
+.It Cm setdf Ar value
+Changes
+.Cm DF
+bit of the IP packet.
+Value may be 0 (May Fragment) or 1 (Don't Fragment).
May be, it would be more handy make this feature via modifier
(not an action).
Rule format:
[setdf|resetdf]
Or more extensible, use not only DF modification:
[{modip [DF|TOS|DSCP|TTL]}]
I think this is easy to pack any of an instructions into one
ipfw_insn_xx structure.
+ case O_SET_IPDF:
+ switch (cmd->arg1) {
+ case 0:
+ ip->ip_off &=3D ~IP_DF;
+ break;
+ case 1:
+ ip->ip_off |=3D IP_DF;
+ break;
+ default:
+ goto next_rule;
+ /* NOTREACHED */
We can check cmd->arg1 for correct values in the ipfw_chk
function.
--
WBR, Andrey V. Elsukov
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw versions - /usr/src/sbin
Alvin Oga wrote: i've been having some fun with ipfw-1.99 on freebsd-6.1 Some binary files in FreeBSD don't have a numeric version like a linux programms. These programms is a part of the operating system and should be in the consistent with FreeBSD kernel. If you want using some of new ipfw features, you should use a respective FreeBSD version. i do have /usr/src/sys for the kernel and it recompiled nicely with the new config changes -- errors from make cd /usr/src/sbin/ipfw make Warning: Object directory not changed from original /usr/src/CVS.manually/ipfw cc -O2 -fno-strict-aliasing -pipe -c ipfw2.c ipfw2.c:619: error: `O_TAGGED' undeclared here (not in a function) See this document: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cutting-edge.html You can rebuild and reinstall world, or try this: # cd /usr/src/sbin/ipfw # env DEBUG_FLAGS=-I/usr/src/sys/netinet make install -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw versions - /usr/src/sbin
Alvin Oga wrote: You can rebuild and reinstall world, or try this: # cd /usr/src/sbin/ipfw # env DEBUG_FLAGS=-I/usr/src/sys/netinet make install same "TAG" errors do you happen to know the released version of ipfw for freebsd-.60 or freebsd-5.2 ( a previous released stable version ) Which FreeBSD version you use? And why you want to use another version of ipfw? Please, provide output of these commands: # uname -a # sysctl kern | grep osrel # grep ^REV /usr/src/sys/conf/newvers.sh # ident /usr/src/sbin/ipfw/ipfw2.c # ident /usr/src/sys/netinet/ip_fw.h -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw versions - /usr/src/sbin
Alvin Oga wrote: i'm curious why i do not have /usr/src/sbin You can install another sources from the official cd. And why you want to use another version of ipfw? i need to change the lines: # # line 3484 in ipfw2.c v1.99 # if ( p.fs.qsize > 100 ) errx ( EX_DATAERR, "2 <= queue size <= 100 ) the 100 need to be changed to 10,000 to allow for a bigger queue according to the customer that wants to use ipfw + dummynet for testing gigE thruput I think this is not good idea. This limit will be checked later in kernel, and if you'll set qsize value greater that 100 - kernel will correct this to 50. (if i correctly understood a kernel sources..) /usr/src/sbin/ipfw/ipfw2.c: $FreeBSD: /repoman/r/ncvs/src/sbin/ipfw/ipfw2.c,v 1.99 2006/09/29 08:00:40 maxim Exp $ This is HEAD branch, you should use RELENG_6_1 for your system. cd /usr/src/sbin setenv CVSROOT [EMAIL PROTECTED]:/home/ncvs setenv CVS_RSH ssh To get a RELENG_6_1 sources try this command: cvs co -r RELENG_6_1 src/sbin/ipfw -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw tracing
Hi, All! I've make a small patch that add a rule action tracing feature to ipfw2. http://butcher.heavennet.ru/patches/kernel/ipfw_trace/ This patch can be usefull when you have too many ipfw-rules. When some packets not pass ipfw - It is not easy to determine rule which block these packets. How to use: # ipfw add 1 count tag # sysctl net.inet.ip.fw.trace_tag= # tail -f /var/log/security - some tag number - rule for matching needed packets What you think about that? -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw tracing
Julian Elischer wrote: What you think about that? Can you show some sample usage and output? Sorry, i don't have patched ipfw on production servers and can show only syntetic example. Let us suppose that we have a lots of rules on the our gateway (allow, deny, skipto, pipe, divert, etc). And we have a task - permit an access from some host A to some host B. This can be easy by adding a permit rule into some place at the head of rules. But i got used to store some related rules in the blocks and don't want to have a random sequences of rules. The tracing is simple way to determine which a rules process our packets. We add a tagging rule in the head of rules and begin tracing. Example: # ipfw add 1 count tag 123 ip from any to 239.192.2.21 # sysctl net.inet.ip.fw.trace_tag=123 # tail -f /var/log/security Oct 25 09:08:07 btr-nb kernel: ipfw: 1 Count UDP 172.21.81.221:1102 239.192.2.21:4545 in via nve0 Oct 25 09:08:07 btr-nb kernel: ipfw: 1014 SkipTo 2050 UDP 172.21.81.221:1102 239.192.2.21:4545 in via nve0 Oct 25 09:08:07 btr-nb kernel: ipfw: 65535 Deny UDP 172.21.81.221:1102 239.192.2.21:4545 in via nve0 Oct 25 09:08:08 btr-nb kernel: ipfw: 1 Count UDP 172.21.81.222:1089 239.192.2.21:4545 in via nve0 Oct 25 09:08:08 btr-nb kernel: ipfw: 1014 SkipTo 2050 UDP 172.21.81.222:1089 239.192.2.21:4545 in via nve0 Oct 25 09:08:08 btr-nb kernel: ipfw: 65535 Deny UDP 172.21.81.222:1089 239.192.2.21:4545 in via nve0 I think this feature can be usable, but needed some limiting.. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request fro source code
arjun badarinath пишет: Hi all , Where can i find the BSD source code for ipfw (user level ) code . I searched in a couple of websites and was able retreive the kernel level code for ipfw . Can u guys help me in getting thje user level code . http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: System calls
arjun badarinath пишет: Hi all, I wanted to know wat these system calls actually do . ip_dn_ctl_ptr ip_dn_io_ptr ip_dn_ruledel_ptr It's not a system calls. It's a pointers for the interaction with dummynet. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet filter
arjun badarinath пишет: Hi all , I wanted to know how the paket filter (pf) is implemented on bsd . can u please send me the link of the source code correponding to this http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/pf/ PS. Please, to the future, before asking a similar questions try to use find(1) and grep(1) with your source tree. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/111121: After the latest changes ipfw2 complains: "ipfw: opcode 50 size 2 wrong"
Remko Lodder пишет: Synopsis: After the latest changes ipfw2 complains: "ipfw: opcode 50 size 2 wrong" Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: remko Responsible-Changed-When: Mon Apr 2 05:56:31 UTC 2007 Responsible-Changed-Why: Over to ipfw maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=21 Hi, try this patch. --- src/sys/netinet/ip_fw2.c.orig Mon Apr 2 11:48:03 2007 +++ src/sys/netinet/ip_fw2.cMon Nov 20 18:19:10 2006 @@ -3861,7 +3836,7 @@ case O_PIPE: case O_QUEUE: - if (cmdlen != F_INSN_SIZE(ipfw_insn)) + if (cmdlen != F_INSN_SIZE(ipfw_insn_pipe)) goto bad_size; goto check_action; -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[patch] /sbin/ipfw - mac/mac-type show as an options (small fix)
Hi, All. As i can see in CVS log, current implementation of a MAC/mac-type options is not first. A long time ago implementation of this options was changed, but i think not fully. An example: # ipfw add count icmp from any to any mac any any 03100 count icmp MAC any any any I wrote a small fix for this: http://butcher.heavennet.ru/patches/other/ipfw_mac_fix/ipfw2.c.diff My tests don't show other break, what you think about this patch? -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/107305: [ipfw] ipfw fwd doesn't seem to work
The following reply was made to PR kern/107305; it has been noted by GNATS. From: "Andrey V. Elsukov" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/107305: [ipfw] ipfw fwd doesn't seem to work Date: Fri, 27 Apr 2007 08:46:09 +0400 Hi, IP Address 212.59.27.254 is local for your system. In 6.0-RELEASE you should add IPFIREWALL_FORWARD_EXTENDED kernel option in your kernel config. http://www.freebsd.org/releases/6.0R/relnotes-i386.html "The ipfw(8) ipfw fwd rule now supports the full packet destination manipulation when the kernel option options IPFIREWALL_FORWARD_EXTENDED is specified in addition to options IPFIRWALL_FORWARD. This kernel option disables all restrictions to ensure proper behavior for locally generated packets and allows redirection of packets destined to locally configured IP addresses. Note that ipfw(8) rules have to be carefully crafted to make sure that things like PMTU discovery do not break." -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/107305: [ipfw] ipfw fwd doesn't seem to work
Julian Elischer wrote: This was fixed in 6.[later] (6.2 at least, maybe 6.1) (The need for the EXTENDED option) Yes, i know. I think this PR can be closed. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/80913: [patch] /sbin/ipfw2 silently discards MAC addr arg with improper characters
The following reply was made to PR bin/80913; it has been noted by GNATS.
From: "Andrey V. Elsukov" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
Maxim Konovalov <[EMAIL PROTECTED]>
Cc:
Subject: Re: bin/80913: [patch] /sbin/ipfw2 silently discards MAC addr arg
with improper characters
Date: Thu, 03 May 2007 08:38:01 +0400
This is a multi-part message in MIME format.
--080506050005050409040606
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Hi, can you test the following patch? (for CURRENT or RELENG_6)
--
WBR, Andrey V. Elsukov
--080506050005050409040606
Content-Type: text/plain;
name="ipfw2.c.diff.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ipfw2.c.diff.txt"
--- src/sbin/ipfw/ipfw2.c Wed Apr 18 18:03:08 2007
+++ src/sbin/ipfw/ipfw2.c Wed May 2 20:05:20 2007
@@ -47,6 +47,7 @@
#include
#include
+#include
#include
#include
#include
@@ -4374,36 +4375,51 @@
}
static void
-get_mac_addr_mask(char *p, uint8_t *addr, uint8_t *mask)
+get_mac_addr_mask(const char *p, uint8_t *addr, uint8_t *mask)
{
int i, l;
+ char *ap, *ptr, *optr;
+ struct ether_addr *mac;
+ const char *macset = "0123456789abcdefABCDEF:";
- for (i=0; i<6; i++)
+ if (strcmp(p, "any") == 0) {
+ for (i = 0; i < ETHER_ADDR_LEN; i++)
addr[i] = mask[i] = 0;
- if (strcmp(p, "any") == 0)
return;
+ }
- for (i=0; *p && i<6;i++, p++) {
- addr[i] = strtol(p, &p, 16);
- if (*p != ':') /* we start with the mask */
- break;
- }
- if (*p == '/') { /* mask len */
- l = strtol(p+1, &p, 0);
- for (i=0; l>0; l -=8, i++)
- mask[i] = (l >=8) ? 0xff : (~0) << (8-l);
- } else if (*p == '&') { /* mask */
- for (i=0, p++; *p && i<6;i++, p++) {
- mask[i] = strtol(p, &p, 16);
- if (*p != ':')
- break;
+ optr = ptr = strdup(p);
+ if ((ap = strsep(&ptr, "&/")) != NULL && *ap != 0) {
+ l = strlen(ap);
+ if (strspn(ap, macset) != l || (mac = ether_aton(ap)) == NULL)
+ errx(EX_DATAERR, "Incorrect MAC address");
+ bcopy(mac, addr, ETHER_ADDR_LEN);
+ } else
+ errx(EX_DATAERR, "Incorrect MAC address");
+
+ if (ptr != NULL) { /* we have mask? */
+ if (p[ptr - optr - 1] == '/') { /* mask len */
+ l = strtol(ptr, &ap, 10);
+ if (*ap != 0 || l > ETHER_ADDR_LEN * 8 || l < 0)
+ errx(EX_DATAERR, "Incorrect mask length");
+ for (i = 0; l > 0 && i < ETHER_ADDR_LEN; l -=8, i++)
+ mask[i] = (l >= 8) ? 0xff: (~0) << (8 - l);
+ } else { /* mask */
+ l = strlen(ptr);
+ if (strspn(ptr, macset) != l ||
+ (mac = ether_aton(ptr)) == NULL)
+ errx(EX_DATAERR, "Incorrect mask");
+ bcopy(mac, mask, ETHER_ADDR_LEN);
}
- } else if (*p == '\0') {
- for (i=0; i<6; i++)
+ } else { /* default mask: ff:ff:ff:ff:ff:ff */
+ for (i = 0; i < ETHER_ADDR_LEN; i++)
mask[i] = 0xff;
}
- for (i=0; i<6; i++)
+
+ for (i = 0; i < ETHER_ADDR_LEN; i++)
addr[i] &= mask[i];
+
+ free(optr);
}
/*
--080506050005050409040606--
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/80913: [patch] /sbin/ipfw2 silently discards MAC addr arg with improper characters
The following reply was made to PR bin/80913; it has been noted by GNATS.
From: "Andrey V. Elsukov" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
Maxim Konovalov <[EMAIL PROTECTED]>
Cc:
Subject: Re: bin/80913: [patch] /sbin/ipfw2 silently discards MAC addr arg
with improper characters
Date: Thu, 03 May 2007 08:36:27 +0400
This is a multi-part message in MIME format.
--030401010501060202090501
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Hi, can you test the following patch?
--
WBR, Andrey V. Elsukov
--030401010501060202090501
Content-Type: text/plain;
name="ipfw2.c.diff.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ipfw2.c.diff.txt"
--- src/sbin/ipfw/ipfw2.c Wed Apr 18 18:03:08 2007
+++ src/sbin/ipfw/ipfw2.c Wed May 2 20:05:20 2007
@@ -47,6 +47,7 @@
#include
#include
+#include
#include
#include
#include
@@ -4374,36 +4375,51 @@
}
static void
-get_mac_addr_mask(char *p, uint8_t *addr, uint8_t *mask)
+get_mac_addr_mask(const char *p, uint8_t *addr, uint8_t *mask)
{
int i, l;
+ char *ap, *ptr, *optr;
+ struct ether_addr *mac;
+ const char *macset = "0123456789abcdefABCDEF:";
- for (i=0; i<6; i++)
+ if (strcmp(p, "any") == 0) {
+ for (i = 0; i < ETHER_ADDR_LEN; i++)
addr[i] = mask[i] = 0;
- if (strcmp(p, "any") == 0)
return;
+ }
- for (i=0; *p && i<6;i++, p++) {
- addr[i] = strtol(p, &p, 16);
- if (*p != ':') /* we start with the mask */
- break;
- }
- if (*p == '/') { /* mask len */
- l = strtol(p+1, &p, 0);
- for (i=0; l>0; l -=8, i++)
- mask[i] = (l >=8) ? 0xff : (~0) << (8-l);
- } else if (*p == '&') { /* mask */
- for (i=0, p++; *p && i<6;i++, p++) {
- mask[i] = strtol(p, &p, 16);
- if (*p != ':')
- break;
+ optr = ptr = strdup(p);
+ if ((ap = strsep(&ptr, "&/")) != NULL && *ap != 0) {
+ l = strlen(ap);
+ if (strspn(ap, macset) != l || (mac = ether_aton(ap)) == NULL)
+ errx(EX_DATAERR, "Incorrect MAC address");
+ bcopy(mac, addr, ETHER_ADDR_LEN);
+ } else
+ errx(EX_DATAERR, "Incorrect MAC address");
+
+ if (ptr != NULL) { /* we have mask? */
+ if (p[ptr - optr - 1] == '/') { /* mask len */
+ l = strtol(ptr, &ap, 10);
+ if (*ap != 0 || l > ETHER_ADDR_LEN * 8 || l < 0)
+ errx(EX_DATAERR, "Incorrect mask length");
+ for (i = 0; l > 0 && i < ETHER_ADDR_LEN; l -=8, i++)
+ mask[i] = (l >= 8) ? 0xff: (~0) << (8 - l);
+ } else { /* mask */
+ l = strlen(ptr);
+ if (strspn(ptr, macset) != l ||
+ (mac = ether_aton(ptr)) == NULL)
+ errx(EX_DATAERR, "Incorrect mask");
+ bcopy(mac, mask, ETHER_ADDR_LEN);
}
- } else if (*p == '\0') {
- for (i=0; i<6; i++)
+ } else { /* default mask: ff:ff:ff:ff:ff:ff */
+ for (i = 0; i < ETHER_ADDR_LEN; i++)
mask[i] = 0xff;
}
- for (i=0; i<6; i++)
+
+ for (i = 0; i < ETHER_ADDR_LEN; i++)
addr[i] &= mask[i];
+
+ free(optr);
}
/*
--030401010501060202090501--
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem applying TOS/DSCP patch in 6.2 RELEASE
Jim Sifferle wrote: Am I missing some intermediate steps? Thanks for any help... You can try to make with DEBUG_FLAGS=-I/usr/src/sys or replace header /usr/include/netinet/ip_fw.h with patched /usr/src/sys/netinet/ip_fw.h -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem applying TOS/DSCP patch in 6.2 RELEASE
Jim Sifferle wrote: Am I missing some intermediate steps? Thanks for any help... You can try to make with DEBUG_FLAGS=-I/usr/src/sys or replace header /usr/include/netinet/ip_fw.h with patched /usr/src/sys/netinet/ip_fw.h -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112708: ipfw is seems to be broken to limit number of connections
The following reply was made to PR kern/112708; it has been noted by GNATS. From: "Andrey V. Elsukov" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/112708: ipfw is seems to be broken to limit number of connections Date: Thu, 17 May 2007 16:42:16 +0400 Hi, What show `ipfw -d show` and `netstat -anf inet | grep -E "SYN|ESTAB"`? -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[ipfw][patch] manipulation with rules within a specified sets
Hi, All. I've wrote a small patch for the ipfw2. http://butcher.heavennet.ru/patches/kernel/ipfw_sets/ It allow use following commands: # ipfw set N show list all rules only from set N. # ipfw set N delete M delete rules with number M from set N. What you think about it? Several guys ask me for implement a "delete rules by template" (text of rule), like a cisco-way (no ). What you think about that? -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: skipto bug
AT Matik wrote: seems to be a skipto bug in ipfw # ipfw add 6 skipto 65535 ip from any to any ipfw: illegal argument for skipto This is not a bug. I am not sure how long it so but this I get on latest releng_6 sources I think this behaviour was introduced with the new feature "tablearg". The number 65535 is reserved for the "tablearg". -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW Mac filter confusion.
Danny Carroll wrote: > I think I must be misunderstanding how the MAC option to ipfw works. > The man page is not terribly helpful so I was wondering if someone can > enlighten me. From ipfw(8): net.link.ether.ipfw: 0 Controls whether layer-2 packets are passed to ipfw. Default is no. Do you change this option to 1? -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ip6fw byte reporting error in v6
Pekka Savola wrote: Fiddling around with ipfw, I noticed that 'ip6fw -ta l', under byte reports, does not include the base IPv6 header in the length calculation (hmm.. I wonder how it would calculate the length of extension-header chained packet). IPv4 byte statistics, on the other hand, include the IPv4 header bytes. Is this a known problem? Is it a more general BSD kernel problem? Probably, you should use ipfw(8) instead of ip6fw(8). ip6fw was removed and it's functional moved into ipfw(8). -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/115372: [ipfw]: "ipfw show" prints ill result.
The following reply was made to PR bin/115372; it has been noted by GNATS.
From: "Andrey V. Elsukov" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: Maxim Konovalov <[EMAIL PROTECTED]>,
Oleg Bulyzhin <[EMAIL PROTECTED]>
Subject: Re: bin/115372: [ipfw]: "ipfw show" prints ill result.
Date: Fri, 10 Aug 2007 11:50:02 +0400
This is a multi-part message in MIME format.
--040106090808050103000507
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
this bug was not introduced by mentioned commit.
You can see this bug also with following rules:
# ipfw add allow ip from any to any not ipid 1,2,3,4,5
# ipfw add allow ip from any to any not ipttl 1,2,3,4,5
# ipfw add allow ip from any to any not iplen 1,2,3,4,5
and "not tcpdatalen 1,2,3,4", "not tagged 1,2,3,4".
Can you try this patch?
--
WBR, Andrey V. Elsukov
--040106090808050103000507
Content-Type: text/plain;
name="ipfw2.c.diff.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ipfw2.c.diff.txt"
--- src/sbin/ipfw/ipfw2.c.orig 2007-06-18 21:52:37.0 +0400
+++ src/sbin/ipfw/ipfw2.c 2007-08-09 20:54:21.749670029 +0400
@@ -668,8 +668,6 @@
int i;
char const *sep;
- if (cmd->o.len & F_NOT)
- printf(" not");
if (opcode != 0) {
sep = match_value(_port_name, opcode);
if (sep == NULL)
@@ -1755,6 +1753,8 @@
show_prerequisites(&flags, HAVE_PROTO|HAVE_SRCIP, 0);
if ((cmd->len & F_OR) && !or_block)
printf(" {");
+ if (cmd->len & F_NOT)
+ printf(" not");
print_newports((ipfw_insn_u16 *)cmd, proto,
(flags & HAVE_OPTIONS) ? cmd->opcode : 0);
break;
--040106090808050103000507--
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw2 deep packet filtering
Hi, > I'm trying to solve a problem with ipfw2, so would be grateful for help > from anyone on the list with moving things forward. This is not an ipfw problem. > I would like to understand if it's possible to discover the real MAC > address of a packet that has been NAT'd by another device. The scenario > for using this would be for hosts on a wireless LAN that connect to a > wireles router which NAT's their connection and then routes the packets > to another LAN (across a wire) where a FreeBSD server performs firewall > packet filtering via ipfw2. As all the connections from the hosts on > the wireless LAN have had their MAC and IP addresses NAT'd to that of > the wireless router, it is difficult to distinguish between hosts, > unless some form of deep packet inspection could be performed to > discover the true MAC address. Is this something that would be possible > with ipfw2? There is no way to discover this information. Maybe, you can parse some specific protocols that contain a MAC addresses within packets. But this is hard and don't give a 100% results. The right way, IMHO, is an VPN-connections between Wireless clients and FreeBSD server. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dummynet / ipfw2: panic, double fault
Hi, I got a trace for this fault. dummynet reinject packet to the ip_input through netisr_dispath. This procedure was done success several times, but in the next time it's fault. (kgdb) p &ipfw_chk $1 = (int (*)(struct ip_fw_args *)) 0xc3374ea0 (kgdb) l *(0xc3374ea0+0x16) 0xc3374eb6 is in ipfw_chk (/usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2304). 2299 * ip is the beginning of the ip(4 or 6) header. 2300 * Calculated by adding the L3offset to the start of data. 2301 * (Until we start using L3offset, the packet is 2302 * supposed to start with the ip header). 2303 */ 2304struct mbuf *m = args->m; 2305struct ip *ip = mtod(m, struct ip *); 2306 2307/* 2308 * For rules which contain uid/gid or jail constraints, cache I don't understand why we have panic here.. Can someone explain this panic? -- WBR, Andrey V. ElsukovFatal double fault: eip = 0xc3343eb6 esp = 0xd4f80f7c ebp = 0xd4f8127c cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: enter: panic [thread pid 33 tid 100037 ] Stopped at kdb_enter+0x32: leave db> bt Tracing pid 33 tid 100037 td 0xc2ece400 kdb_enter(c0a8a0dc,0,c0ab6f9e,c0c06cb0,0,...) at kdb_enter+0x32 panic(c0ab6f9e,0,0,0,0,...) at panic+0x124 dblfault_handler() at dblfault_handler+0x9b --- trap 0x17, eip = 0xc3343eb6, esp = 0xd4f80f7c, ebp = 0xd4f8127c --- ipfw_chk(d4f81294,41ec0d7e,0,0,c30de000,...) at ipfw_chk+0x16 ipfw_check_in(0,d4f81398,c2eae800,1,0,...) at ipfw_check_in+0xd7 pfil_run_hooks(c0be9e00,d4f813ec,c2eae800,1,0,...) at pfil_run_hooks+0x88 ip_input(c30de000,c2ece498,c0b3b764,c337ab06,c30de000,...) at ip_input+0x24d netisr_dispatch(2,c30de000,c337cb2c,1,c0a88e3d,...) at netisr_dispatch+0x73 dummynet_send(c337cb2c,0,c337ab06,560,cf,...) at dummynet_send+0x136 dummynet_io(c30de000,2,d4f814fc,0,c30de000,...) at dummynet_io+0x373 ipfw_check_in(0,d4f81600,c2eae800,1,0,...) at ipfw_check_in+0x220 pfil_run_hooks(c0be9e00,d4f81654,c2eae800,1,0,...) at pfil_run_hooks+0x88 ip_input(c30de000,c2ece498,c0b3b764,c337ab06,c30de000,...) at ip_input+0x24d netisr_dispatch(2,c30de000,c337cb2c,1,c0a88e3d,...) at netisr_dispatch+0x73 dummynet_send(c337cb2c,0,c337ab06,560,cf,...) at dummynet_send+0x136 dummynet_io(c30de000,2,d4f81764,0,c30de000,...) at dummynet_io+0x373 ipfw_check_in(0,d4f81868,c2eae800,1,0,...) at ipfw_check_in+0x220 pfil_run_hooks(c0be9e00,d4f818bc,c2eae800,1,0,...) at pfil_run_hooks+0x88 ip_input(c30de000,c2ece498,c0b3b764,c337ab06,c30de000,...) at ip_input+0x24d netisr_dispatch(2,c30de000,c337cb2c,1,c0a88e3d,...) at netisr_dispatch+0x73 dummynet_send(c337cb2c,0,c337ab06,560,cf,...) at dummynet_send+0x136 dummynet_io(c30de000,2,d4f819cc,0,c30de000,...) at dummynet_io+0x373 ipfw_check_in(0,d4f81ad0,c2eae800,1,0,...) at ipfw_check_in+0x220 pfil_run_hooks(c0be9e00,d4f81b24,c2eae800,1,0,...) at pfil_run_hooks+0x88 ip_input(c30de000,c2ece498,c0b3b764,c337ab06,c30de000,...) at ip_input+0x24d netisr_dispatch(2,c30de000,c337cb2c,1,c0a88e3d,...) at netisr_dispatch+0x73 dummynet_send(c337cb2c,0,c337ab06,560,cf,...) at dummynet_send+0x136 dummynet_io(c30de000,2,d4f81c34,0,c30de000,...) at dummynet_io+0x373 ipfw_check_in(0,d4f81d38,c2eae800,1,0,...) at ipfw_check_in+0x220 pfil_run_hooks(c0be9e00,d4f81d8c,c2eae800,1,0,...) at pfil_run_hooks+0x88 ip_input(c30de000,c2ece498,c0b3b764,c337ab06,c30de000,...) at ip_input+0x24d netisr_dispatch(2,c30de000,c337cb2c,1,c0a88e3d,...) at netisr_dispatch+0x73 dummynet_send(c337cb2c,0,c337ab06,560,cf,...) at dummynet_send+0x136 dummynet_io(c30de000,2,d4f81e9c,0,c30de000,...) at dummynet_io+0x373 ipfw_check_in(0,d4f81fa0,c2eae800,1,0,...) at ipfw_check_in+0x220 pfil_run_hooks(c0be9e00,d4f81ff4,c2eae800,1,0,...) at pfil_run_hooks+0x88 ip_input(c30de000,c2ece498,c0b3b764,c337ab06,c30de000,...) at ip_input+0x24d netisr_dispatch(2,c30de000,c337cb2c,1,c0a88e3d,...) at netisr_dispatch+0x73 dummynet_send(c337cb2c,0,c337ab06,560,cf,...) at dummynet_send+0x136 dummynet_io(c30de000,2,d4f82104,0,c30de000,...) at dummynet_io+0x373 ipfw_check_in(0,d4f82208,c2eae800,1,0,...) at ipfw_check_in+0x220 pfil_run_hooks(c0be9e00,d4f8225c,c2eae800,1,0,...) at pfil_run_hooks+0x88 ip_input(c30de000,c2ece498,c0b3b764,c337ab06,c30de000,...) at ip_input+0x24d netisr_dispatch(2,c30de000,c337cb2c,1,c0a88e3d,...) at netisr_dispatch+0x73 dummynet_send(c337cb2c,0,c337ab06,560,cf,...) at dummynet_send+0x136 dummynet_io(c30de000,2,d4f8236c,0,c30de000,...) at dummynet_io+0x373 ipfw_check_in(0,d4f82470,c2eae800,1,0,...) at ipfw_check_in+0x220 pfil_run_hooks(c0be9e00,d4f824c4,c2eae800,1,0,...) at pfil_run_hooks+0x88 ip_input(c30de000,c2ece498,c0b3b764,c337ab06,c30de000,...) at ip_input+0x24d netisr_dispatch(2,c30de000,c337cb2c,1,c0a88e3d,...) at netisr_dispatch+0x73 dummynet_send(c337cb2c,0,c337ab06,560,cf,...) at dummynet_send+0x136 dummynet_io(c30de000,2,d4f825d4,0,c30de000,...) at dummynet_io+0x373 ipfw_check_in(0,d4f826d8,c2eae800,1,0,.
Re: bin/116458: [ipfw]: Logging problems with syslog and ipfw an 6.2.REL-p5
Remko Lodder wrote: > > bge0 is running in promisc mode because of dsc which is running. > > > > sample content of /var/log/messages > > Sep 14 12:00:00 ns2 newsyslog[94585]: logfile turned over due to size>100K > > Sep 14 12:00:02 ns2 kernel: 5 > > Sep 14 12:00:05 ns2 kernel: > > Sep 14 12:00:05 ns2 kernel: 7 > > Sep 14 12:00:08 ns2 kernel: > > Sep 14 12:00:08 ns2 kernel: 9 > > Sep 14 12:00:11 ns2 kernel: 8 > > Sep 14 12:00:14 ns2 kernel: > > Sep 14 12:00:14 ns2 kernel: e0 > > Sep 14 12:00:15 ns2 kernel: a bge0 > > Sep 14 12:00:15 ns2 kernel: e0 > > Sep 14 12:00:15 ns2 kernel: < This problem is not related to the ipfw. But you can try this patch: http://people.yandex-team.ru/~sem/FreeBSD/kernel/log_mutex.diff Please, report back if it will help you. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/113803: [patch] bin/ipfw.8 - don't get bitten by the fwd rule
[EMAIL PROTECTED] wrote: Maybe somebody from the mailinglist wants to comment on the PR. Yes, the packet forwarding may work only compiled within custom kernel. I think have a full chapter about ipfw-specific kernel options and a small howto about building a custom kld (without kernel rebuild) will be good. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/118993: [ipfw] page fault - probably it's a locking problem
[EMAIL PROTECTED] wrote: State-Changed-When: Tue Dec 25 14:14:45 UTC 2007 State-Changed-Why: Oops, it was actually a recursive panic and the first one is indeed ipfw-related. The ipfw ruleset would still help though. I'm not sure that Maxim (a person who got the problem) can publish his rules. But as i know there is a typical firewall-script (`ipfw -f flush` and a lot of other rules). As i see in the code, panic is in the line 2538: if (set_disable & (1 << f->set) ) continue; I think panic here can be only when "f" is invalid. I'm right? But it seems protected with IPFW_RLOCK... -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disabling syslog messages?
rihad wrote: Dec 26 13:00:01 foo kernel: ipfw: Entry 1001 cleared. Dec 26 13:00:01 foo kernel: ipfw: Entry 1002 cleared. ... and so on. After looking in ipfw's sources in /usr/src/sbin/ipfw/ipfw2.c I now think that quite probably the messages are generated by some setsockopt call or by the kernel itself. I _could_ work around the issue by piping the "ipfw:" messages to /dev/null in syslogd, but there might be a cleaner solution? If you don't use `ipfw log ...` rules you can reset sysctl variable net.inet.ip.fw.verbose to 0 and these messages will not be logged. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121122: [ipfw] [patch] add support to ToS IP PRECEDENCE fields
[EMAIL PROTECTED] wrote:
Synopsis: [ipfw] [patch] add support to ToS IP PRECEDENCE fields
Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw
Responsible-Changed-By: araujo
Responsible-Changed-When: Tue Feb 26 19:08:49 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=121122
Hi, Marcelo.
I talked to Roman when he submitted his first patch about
it's design. What you think about making TOK_SETIPTOSPRE not
an action, but a modifier? I think it will be much usable.
A syntax example:
# ipfw add allow iptospre flashover ip from any to any
# ipfw add count iptospre immediate ip from anyt to any
# ipfw add skipto
Also I talked to Roman about extensible variant of this ability.
A syntax example:
[{modip [DF|TOS|DSCP|TTL]}]
Also look into:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/102471
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/103454
I added to CC several men who are active in ipfw area.
It will be interested what you think about this?
--
WBR, Andrey V. Elsukov
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121122: [ipfw] [patch] add support to ToS IP PRECEDENCE fields
Marcelo Araujo wrote: Yes, I've interest to work around this function, this work help me for my degree project. I think also this work is a good opportunity to work in SoC 2008. I think this work is too easy for the SoC'08 :) -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Paolo Pisati wrote: On Thu, Mar 13, 2008 at 09:21:11AM +, Vadim Goncharov wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=80642 Yes, this is useful, but some minor changes are needed, I think. First, rename it to "bytelimit" or somewhat. Second, allow this to use tablearg and possibly ability to reference a counter to corresponding dynamic rule, to allow this to act for a specific IP or connection without need to write many rules. Third, add packet counter as well. That's all possible with one opcode, though... if anyone post an updated patch, i'll commit it. So, updated patch is here: http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff Now this option divided into two "counterlimit-bytes" and "counterlimit-packets". Rules example: add allow ip from any to 10.0.0.1 counterlimit-bytes 100M \ in recv external_if add allow ip from any to 10.0.0.1 counterlimit-pakets 50 \ in recv external_if About Vadim's prepositions: 1. tablearg: it's possible, but now we use u32 argument in tables, but counterlimits are 64-bits values. First of we should extend our current table argument to 64 bit. 2. dynamic rules: i think it should be implemented as extension to current O_LIMIT opcode or something similar. Also i have question about my current implementation. Does it needed to have ability of "humanized" printing of limits, which was implemented before? -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Julian Elischer wrote: About Vadim's prepositions: 1. tablearg: it's possible, but now we use u32 argument in tables, but counterlimits are 64-bits values. First of we should extend our current table argument to 64 bit. tables should be expanded to have different types of values.. 32 but ints IP addresses (currently I'm overlaying it on 32 bit ints) IPV6 addresses. skipto locations byte limits.. Yes, i agree. As I remember, we already talked about this some time ago. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
Alexander Shulikov wrote: For bug kern/121955: ([ipfw] [panic] freebsd 7.0 panic with mpd) I receive new dump with mpd-4.4 and FreeBSD 7.0-RELEASE: Did you reset sysctl variable `net.inet.ip.fw.one_pass` into zero? There is well known double panic with dummynet, when packet re injected into pipe again and again. Check your rules. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
AT Matik wrote: what do you mean? By setting to 0 the packages are not re-injected into the pipe but go through other existing rules after the matching pipe, or not? When you reset net.inet.ip.fw.one_pass to zero, packets return back into ipfw to the next rule after dummynet/netgraph. And if you have similar rules packets will be passed into dummynet/netgraph again. This is example how to get double fault (from mail archive): ifconfig em0 192.168.0.2/24 kldload ipfw kldload dummynet sysctl net.inet.ip.fw.one_pass=0 ipfw pipe 2 config bw 0 ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ping 192.168.0.1 -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
AT Matik wrote: jaaa well but that is the famous bw 0 example which is not valid, as by itself certainly an invalid config, not connected to the existing problem the reporter has I guess bw 0 is valid example. It's default value. It means unlimited bandwidth. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: addition to ipfw table..
Julian Elischer wrote:
I do know it won't handle non contiguous masks well but as the
ipfw ABI code only accepts a network mask length instead of a
mask, there's not much that can be done.
I may suggest a later fix for that but it will break the ABI.
comments?
What you think about my patch?
--
WBR, Andrey V. Elsukov
Index: src/sbin/ipfw/ipfw2.c
===
RCS file: /ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.118
diff -u -p -r1.118 ipfw2.c
--- src/sbin/ipfw/ipfw2.c 27 Feb 2008 13:52:33 - 1.118
+++ src/sbin/ipfw/ipfw2.c 17 Apr 2008 05:45:27 -
@@ -5833,7 +5833,7 @@ table_handler(int ac, char *av[])
ipfw_table_entry ent;
ipfw_table *tbl;
int do_add;
- char *p;
+ char *p, md;
socklen_t l;
uint32_t a;
@@ -5850,10 +5850,22 @@ table_handler(int ac, char *av[])
ac--; av++;
if (!ac)
errx(EX_USAGE, "IP address required");
- p = strchr(*av, '/');
+ p = strpbrk(*av, "/:");
if (p) {
+ md = *p;
*p++ = '\0';
- ent.masklen = atoi(p);
+ switch (md) {
+ case ':':
+ if (!inet_aton(p, (struct in_addr *)&a))
+ errx(EX_DATAERR, "bad netmask ``%s''",
p);
+ ent.masklen = contigmask((uint8_t *)&a, 32);
+ if (ent.masklen > 32)
+ errx(EX_DATAERR,
+ "netmask ``%s'' is not
contiguous", p);
+ break;
+ case '/':
+ ent.masklen = atoi(p);
+ }
if (ent.masklen > 32)
errx(EX_DATAERR, "bad width ``%s''", p);
} else
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/123174: [ipfw] table add value lists as ip/uint16 instead of uint32.
[EMAIL PROTECTED] wrote: the change came as part of the change allowing: ipfw table 1 add 1.2.3.4 5.6.7.8 ipfw add 100 fwd tablearg ip from table(1) to any Hi, Julian. When I looked this PR I found another bug. There are several issues with `ipfw -n `. For example: # ipfw -n table 1 list # ifpw -n nat 1 show and probably others command which didn't use `test_only` flag. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Syntax base IP
budsz wrote:
ipunlimit="192.168.0.100/32,10.35.4.1/32,202.129.189.42/32,\
202.129.189.45/32,125.163.77.180/32,202.43.167.70/32,\
202.43.167.72/32,202.43.161.119/32,202.10.32.10/32,202.93.20.22/32,\
202.93.20.23/32,202.93.20.24/32,122.102.49.132/32,\
202.43.161.124/32,202.93.247.26/32,202.93.247.28/32"
${fwcmd} add 100 pipe 1 ip from ${ippriviix} to { not ${ipunlimit} }
${portlim} via ${ifint0}
${fwcmd} add 101 pipe 1 ip from { not ${ipunlimit} } ${portlim} to
${ippriviix} via ${ifint0}
Executing firewall I got error message like this:
#sh /etc/rc.firewall
ipfw: opcode 6 size 33 wrong
ipfw: getsockopt(IP_FW_ADD): Invalid argument
ipfw: opcode 2 size 33 wrong
ipfw: getsockopt(IP_FW_ADD): Invalid argument
It means that your src and dst addresses are too long.
Any clue or suggestion about this syntax?
Try to use lookup tables.
--
WBR, Andrey V. Elsukov
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: issues : FreeBSD kernel compile for ipfw support
Madan Thapa wrote: 1) I compiled bsd kernel for ipfw support using the doc at http://www.cyberciti.biz/faq/howto-setup-freebsd-ipfw-firewall/ and upon I prefer an official documentation: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html reboot, the system did not allow connections from outside. Yes, the default configuration blocks any packets. I could login to the server remotely via IPMI but not via ssh, although, ipfw entries were not setup in /etc/rc.conf to start on boot. You compiled ipfw(9) into kernel and it works by default. on subsequent reboots. Like in linux we do it in grub.conf You can install grub on the FreeBSD too. 2) Can you also let me know the steps to add ipfw support in kernel? Read the Handbook's article. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how much memory does increasing max rules for IPFW take up?
Vivek Khera wrote: I had a box run out of dynamic state space yesterday. I found I can increase the number of dynamic rules by increasing the sysctl parameter net.inet.ip.fw.dyn_max. I can't find, however, how this affects memory usage on the system. Is it dyanamically allocated and de-allocated, or is it a static memory buffer? Each dynamic rule allocated dynamically. Be careful, too many dynamic rules will work very slow. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how much memory does increasing max rules for IPFW take up?
Bruce M. Simpson wrote: Got any figures for this? I took a quick glance and it looks like it just uses a hash over dst/src/dport/sport. If there are a lot of raw IP or ICMP flows then that's going to result in hash collisions. It's my guess, i haven't any figures.. Yes, hash collisions will trigger many searching in buckets lists. And increasing only dyn_max without increasing dyn_buckets will grow collisions. It might be a good project for someone to optimize if it isn't scaling for folk. "Bloomier" filters are probably worth a look -- bloom filters are a class of probabilistic hash which may return a false positive, "bloomier" filters are a refinement which tries to limit the false positives. There were some ideas from Vadim Goncharov about rewriting dynamic rules implementation.. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tablearg q'n
rihad wrote: ipfw add pipe tablearg ip from 'table(0)' to 'table(1)' Which of the two tables will tablearg come from? Last 'table' argument will be used for tablearg. Any way to make the choice explicit? Patches are welcome =) -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION
Paolo Pisati wrote: >> add packet counter as well. That's all possible with one opcode, though... > > if anyone post an updated patch, i'll commit it. Hi, Paolo. Any progress in this? I updated patch: http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: svn commit: r200855 - in head/sys: net netgraph netinet netinet/ipfw
On 22.12.2009 22:01, Luigi Rizzo wrote: Author: luigi Date: Tue Dec 22 19:01:47 2009 New Revision: 200855 URL: http://svn.freebsd.org/changeset/base/200855 Log: merge code from ipfw3-head to reduce contention on the ipfw lock and remove all O(N) sequences from kernel critical sections in ipfw. In detail: 1. introduce a IPFW_UH_LOCK to arbitrate requests from the upper half of the kernel. Some things, such as 'ipfw show', can be done holding this lock in read mode, whereas insert and delete require IPFW_UH_WLOCK. The only (very small) regression is on dynamic rule lookup and this will be fixed in a day or two, without changing the userland/kernel ABI Supported by: Valeria Paoli MFC after: 1 month Modified: head/sys/netinet/ipfw/ip_fw_sockopt.c Hi, Luigi. This commit also broke `ipfw set show` operation. It always show all sets enabled, because IP_FW_GET command gets small buffer and after calculating wanted size it returns back without copying anything. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: kern/144869: [ipfw] [panic] Instant kernel panic when adding NAT rules using ipfw on em interfaces
The following reply was made to PR kern/144869; it has been noted by GNATS. From: "Andrey V. Elsukov" To: Ildar Hizbulin Cc: bug-follo...@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: kern/144869: [ipfw] [panic] Instant kernel panic when adding NAT rules using ipfw on em interfaces Date: Tue, 17 Aug 2010 15:21:08 +0400 On 17.08.2010 14:31, Ildar Hizbulin wrote: > i reproduce this bug in virtualbox ose 3.2.8 with Intel PRO/1000 MT > Desktop (Bridged adapter, eth1) emulation in the gentoo linux host system > and ifconfig em0 -rxcsum solves the problem Hi, Ildar. This bug was fixed with r209959 and i think it was merged to stable/8 with r211241. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: kern/144869: [ipfw] [panic] Instant kernel panic when adding NAT rules using ipfw on em interfaces
On 17.08.2010 14:31, Ildar Hizbulin wrote: > i reproduce this bug in virtualbox ose 3.2.8 with Intel PRO/1000 MT > Desktop (Bridged adapter, eth1) emulation in the gentoo linux host system > and ifconfig em0 -rxcsum solves the problem Hi, Ildar. This bug was fixed with r209959 and i think it was merged to stable/8 with r211241. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: bin/156653: ipfw(8) reports missing file as parameter problem
The following reply was made to PR bin/156653; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-follo...@freebsd.org, jcl...@speakeasy.net Cc: Subject: Re: bin/156653: ipfw(8) reports missing file as parameter problem Date: Mon, 02 May 2011 15:59:16 +0400 Hi, It seems it never worked in the way you are trying. You should use absolute path name for the last argument, e.g. # ipfw -n -p cpp /etc/new.rules -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: kern/147720: [ipfw] ipfw dynamic rules and fwd
The following reply was made to PR kern/147720; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-follo...@freebsd.org, dima_...@inbox.lv Cc: Subject: Re: kern/147720: [ipfw] ipfw dynamic rules and fwd Date: Sun, 29 May 2011 14:41:03 +0400 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig6179B1AC85A77AA253EA07DD Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hi, are you sure that this patch works? Do you have working configuration? --=20 WBR, Andrey V. Elsukov --enig6179B1AC85A77AA253EA07DD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJN4iK/AAoJEAHF6gQQyKF62RwH/iuvANPzSdAvCSTKeNtC5jv3 eBPgjbubEhv3/MMppzyd0FNM1/uRq9Rzk5XflozChhVOn00MXLc43TJ0Ow2wBUYJ K85rUnbeFnjmoEipXnqwtF+z8wj6YMKFM26k83MTm01IIZpN7N813AH3RC0OKyVk ktgXHNcf0Kx+E/GTngIIr+HHRXpmPgFd30unz6QaoE0UNDwvgA/eJT2x4sJw9GoW ivCTFkTgPxEpUJ2YMhh6d4rK3tx3/cLUTOOPshcDoqhY+kwm9EyiVBmZm2xui9Eu pV5BgIQfi+JM8pxVso5cuuT42ri8OWrSMPyuB2q5EnTcqF4UriucFz+UnfGQFfA= =+F6w -END PGP SIGNATURE- --enig6179B1AC85A77AA253EA07DD-- ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: kern/150798: [ipfw] ipfw2 fwd rule matches packets but does not do the job in fact.
The following reply was made to PR kern/150798; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-follo...@freebsd.org, a...@holymail.biz Cc: Subject: Re: kern/150798: [ipfw] ipfw2 fwd rule matches packets but does not do the job in fact. Date: Mon, 30 May 2011 15:37:16 +0400 Hi, It seems your problem is the same as described in kern/147720. Can you test the following patch? http://people.freebsd.org/~ae/ipfw_fwd.diff -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: kern/147720: [ipfw] ipfw dynamic rules and fwd
The following reply was made to PR kern/147720; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-follo...@freebsd.org, dima_...@inbox.lv Cc: Subject: Re: kern/147720: [ipfw] ipfw dynamic rules and fwd Date: Mon, 30 May 2011 15:37:52 +0400 Hi, Can you test the following patch? http://people.freebsd.org/~ae/ipfw_fwd.diff -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: kern/148157: [ipfw] IPFW in kernel nat BUG found in FreeBSD 8.1-PRERELEASE
The following reply was made to PR kern/148157; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-follo...@freebsd.org, poo...@hotmail.com, "Vladislav Yershov" Cc: Subject: Re: kern/148157: [ipfw] IPFW in kernel nat BUG found in FreeBSD 8.1-PRERELEASE Date: Wed, 01 Jun 2011 09:36:42 +0400 Hi, do you still able reproduce this panic? As i remember there were some issues with em(4) driver and they were fixed. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat
The following reply was made to PR kern/157379; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-follo...@freebsd.org, kes-...@yandex.ru Cc: Subject: Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat Date: Mon, 06 Jun 2011 09:51:09 +0400 Hi, Can you test this patch? http://people.freebsd.org/~ae/ipfw_nat.diff -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: kern/131817: [ipfw] blocks layer2 packets that should not be blocked
The following reply was made to PR kern/131817; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-follo...@freebsd.org, eu...@grosbein.pp.ru Cc: Subject: Re: kern/131817: [ipfw] blocks layer2 packets that should not be blocked Date: Fri, 01 Jul 2011 12:56:14 +0400 This is a multi-part message in MIME format. --000306040401040406030900 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Hi, Eugene can you test this patch? -- WBR, Andrey V. Elsukov --000306040401040406030900 Content-Type: text/plain; name="arpreply.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arpreply.diff" Index: head/sys/netinet/if_ether.c === --- head/sys/netinet/if_ether.c(revision 223705) +++ head/sys/netinet/if_ether.c(working copy) @@ -857,6 +857,7 @@ reply: ah->ar_pro = htons(ETHERTYPE_IP); /* let's be sure! */ m->m_len = sizeof(*ah) + (2 * ah->ar_pln) + (2 * ah->ar_hln); m->m_pkthdr.len = m->m_len; + m->m_pkthdr.rcvif = NULL; sa.sa_family = AF_ARP; sa.sa_len = 2; (*ifp->if_output)(ifp, m, &sa, NULL); --000306040401040406030900-- ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: ipfw fwd on FreeBSD 8.1, does it work?
On 05.07.2011 21:20, Unga wrote: > Thanks for the reply. > > The 'options IPFIREWALL_FORWARD' is already built in the custom kernel. > > Both rules you suggested develop the same error: > ipfw: getsockopt(IP_FW_ADD): Invalid argument Hi, You should add 'options IPFIREWALL' in the your kernel config too. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw fwd on FreeBSD 8.1, does it work?
On 05.07.2011 22:46, Fabian Wenk wrote: >> ipfw(8) man page for 'fwd' shows to add only the IPFIREWALL_FORWARD. > > I guess the manpage implies that 'options IPFIREWALL' is already there, > or the module is loaded, can be done with: > kldload ipfw > > So you do not need to rebuild the kernel. fwd does not work when ipfw loaded as module. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: fwd in ipfw module
On 03.08.2011 14:28, timp wrote: > Do you know solution (for GENERIC kernel) that can port forwarding? I found > /usr/ports/net/rinetd You can use pf(4). -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: ipfw nat drops icmp packets from localhost
On 06.10.2011 12:29, Oleg Strizhak wrote: > After an investigation I've found out a very strange situation - it seems to > me, that ipfw nat drops > some (type 11?) icmp reply packets, whose udp request packets it hasn't > rewritten/seen before, e.g: > > So, I wonder whether someone else has seen the same case under the similar > circumstances? Isn't it a > bug within ipfw nat module and is there any work-around/patch for that? I've > surely googled, but in > vain =( The only thing, that seems alike to my problem, is > http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch > didn't cure anything =( Can you describe how you did apply and test this patch? -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: ipfw features
On 25.10.2011 17:19, Серега Гончаров wrote: > Hi all. Is there some plans to make ipfw can change ip header fields of > going throught packets, like TTL, DF flag etc. pf and iptables can, so maybe > in freebsd 9 it will be implemented? thanks. You can use ng_patch(4) for that. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW tables trouble
On 16.05.2012 16:07, Daniel Kalchev wrote: > (module) > FreeBSD router7 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Sep 30 16:17:47 EEST > 2011 > root@localhost:/usr/obj/usr/src/sys/GENERIC amd64 > FreeBSD router6x 9.0-STABLE FreeBSD 9.0-STABLE #1: Wed Apr 18 20:19:12 EEST > 2012 > root@localhost:/usr/obj/usr/src/sys/GENERIC amd64 Hi, Can you try update your 9.0-STABLE and test it again? There were some changes related to tables. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
[RFC] Enabling IPFIREWALL_FORWARD in run-time
Hi All, Many years ago i have already proposed this feature, but at that time several people were against, because as they said, it could affect performance. Now, when we have high speed network adapters, SMP kernel and network stack, several locks acquired in the path of each packet, and i have an ability to test this in the lab. So, i prepared the patch, that removes IPFIREWALL_FORWARD option from the kernel and makes this functionality always build-in, but it is turned off by default and can be enabled via the sysctl(8) variable net.pfil.forward=1. http://people.freebsd.org/~ae/pfil_forward.diff Also we have done some tests with the ixia traffic generator connected via 10G network adapter. Tests have show that there is no visible difference, and there is no visible performance degradation. Any objections? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time
On 19.10.2012 16:02, Andre Oppermann wrote:>> http://people.freebsd.org/~ae/pfil_forward.diff >> >> Also we have done some tests with the ixia traffic generator connected >> via 10G network adapter. Tests have show that there is no visible >> difference, and there is no visible performance degradation. >> >> Any objections? > > No objection as such. However I don't entirely agree with the > naming of pfil_forward. The functionality is specific to IPFW > and TCP, it's doing transparent interjected termination of tcp > connections on the local host while keeping the original IP > addresses and port numbers visible in netstat output. > > So it's a feature of IPFW/IP and should be fitted in there for > sysctl name and .h files instead of pfil. Actually it can be used not only by ipfw. We already have net.inet.ip.forwarding and net.inet6.ip6.forwarding variables, and placing it into net.inet.ip.fw is undesirable, because we can have kernel without ipfw. So, i decided to choose pfil, because it could not work without pfil. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: recompiling ipfw source-code
On 23.10.2012 12:46, M. V. wrote: > hi everybody, > > I'm trying to make some changes in ipfw code. but my problem is, when > i make a change in ipfw code in "/usr/src/sys/netinet/ipfw" , this > folder doesn't have any Makefile, and i have to compile "/usr/src" > instead, which takes a lot of time (almost 20 minutes everytime i try > to compile), and this makes what i'm trying to do almost impossible. > > > so i wanted to ask, does anyone know an easier or quicker way to > compile ipfw (/usr/src/sys/netinet/ipfw), or maybe a simpler Makefile > or a shell to do this. You can build only ipfw kernel module from the /usr/src/sys/modules/ipfw. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
[RFC] IPv6 ifaddr hash
Hi All, We have discovered that ipfw(4) shows very low performance results with our rules. One of the biggest problems is rules with O_IP6_XXX_ME opcode. They checks match or not match packet's addresses with locally configured IPv6 addresses. For IPv4 we have an in_ifaddr hash for the quick search an address, but not for the IPv6. So, I have implemented the first patch based on the code for the IPv4, but there are several questions I want to discuss. The patch is here: http://people.freebsd.org/~ae/in6_ifaddrhash.diff 1. The hash size. I made it the same what IPv4 has. But I think 512 buckets is too many. 2. What hash function is better to use? 3. Using the whole 128 bit of address to hash seems like overkill. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW fwd not working after upgrade from 9.2 to 10.0
On 06.02.2014 04:08, John Nielsen wrote: > I have been using IPFW FWD to do per-interface routing on a VM > instance. The default gateway is on interface vtnet0, but there is a > second interface, vtnet1, on a different network with its own public > IP address. The second network has its own gateway, which I'd like to > use for responses to connections coming on on vtnet1. Under 9.2, the > below worked fine: Hi, you can apply this patch: http://svnweb.freebsd.org/base?view=revision&revision=260702 -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW fwd not working after upgrade from 9.2 to 10.0
On 06.02.2014 12:31, Andrey V. Elsukov wrote: > On 06.02.2014 04:08, John Nielsen wrote: >> I have been using IPFW FWD to do per-interface routing on a VM >> instance. The default gateway is on interface vtnet0, but there is a >> second interface, vtnet1, on a different network with its own public >> IP address. The second network has its own gateway, which I'd like to >> use for responses to connections coming on on vtnet1. Under 9.2, the >> below worked fine: > > Hi, > > you can apply this patch: > http://svnweb.freebsd.org/base?view=revision&revision=260702 JFYI, I merged the fix from head/. You can update your system to 10-STABLE and it should work. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: how does it pass in the rule sets
On 19.04.2014 11:45, bycn82 wrote: > Hi, > can someone help to explain how does the user land command `ipfw` pass > the rule set into the hook function in the kernel? I assume that it must > be hardcoded in somewhere, but I did not find it yet. ipfw(8) uses raw socket and setsockopt(2)/getsockopt(2) functions to interact with kernel. In particular, do_cmd() function from ipfw2.c does it. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: how does it pass in the rule sets
On 21.04.2014 19:14, bycn82 wrote: > On 4/21/14 22:34, Andrey V. Elsukov wrote: >> On 19.04.2014 11:45, bycn82 wrote: >>> Hi, >>> can someone help to explain how does the user land command `ipfw` pass >>> the rule set into the hook function in the kernel? I assume that it must >>> be hardcoded in somewhere, but I did not find it yet. >> ipfw(8) uses raw socket and setsockopt(2)/getsockopt(2) functions to >> interact with kernel. In particular, do_cmd() function from ipfw2.c does it. >> > Thanks very much, > Actually I saw the source already, the ipfw_ctl() method. I would like > to call it as "an event handler" > But why it will triggered? where are the code to register this method > as listener? > Sorry for using Java terminologies ;) You need to improve your grep-fu :) When you load ipfw.ko kernel module, vnet_ipfw_init() initializes V_ip_fw_ctl_ptr = ipfw_ctl. When you call setsockopt() for raw socket, it invokes ctloutput method for RAW IP - rip_ctloutput() (netinet/raw_ip.c). It calls ipfw_ctl() via V_ip_fw_ctl_ptr pointer. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: net.inet{,6}.fw.enable in /etc/rc
On 21.09.2014 09:58, Hiroki Sato wrote:
> Hi,
>
> I would like your comments about the attached patch to /etc/rc.
>
> The problem I want to fix by this patch is as follows.
> net.inet{,6}.fw.enable are set to 1 by default at boot time if IPFW
> kernel module is loaded or statically compiled into a kernel. And by
> default IPFW has only a "deny ip from any to any" rule if it is
> compiled without IPFIREWALL_DEFAULT_TO_ACCEPT option. In this case,
> the default-deny rule can prevent rc.d scripts before rc.d/ipfw from
> working as described in the patch.
>
> To fix this, the patch turns IPFW off before running rc.d scripts at
> boot time, and enables it again in rc.d/ipfw script.
Hi,
I think this should be configurable, the change can be an unexpected for
someone.
--
WBR, Andrey V. Elsukov
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: "reass all from any to any" kills IPv6 packets
On 05.03.2015 18:26, Emil Muratov wrote: > On 03.02.2015 13:42, Lev Serebryakov wrote: >> >> Recommended "reass all from any to any in" kills all incoming IPv6 >> packets (at least, packets from 6in4 tunnel). "reass ip4 from any to >> any in" works as expected. >> >> Is it documentation bug or implementation bug? > > Both :) Hit this bug several years ago, seems it is still here AFAIR, I made the patch for such PR, but nobody wanted to test it :) https://people.freebsd.org/~ae/ipfw_ip6reass.diff Probably now I can test it myself a bit later. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: chnage source of IPFW
On 01.06.2015 12:44, samira wrote: > Hello every one, > I want to add a parameter in commands for ipfw, like " ipfw add allow udp > from any to any *udpdatalen 10 * ". > > I changes in /usr/src/sbin/ipfw/ipfw2.c like tcpdatalen option and now i > have udpdatalen command correctly in cli, but when i add argument(10) this > error occurred. > " *ipfw: getsockopt(IP_FW_ADD): Invalid argument* " > > also I define variables in /usr/src/sys/netinet/ip_fw.h and change .c files > in /usr/src/sys/net pfil/ and build kernel and did not changed that error. > > Thank you for all of your comments and help. Probably, you need to modify ip_fw_sockopt.c:check_ipfw_rule_body() function. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: proxy_rule is missing in kernel nat?
On 28.09.2015 05:34, lsrz2...@sina.com wrote: > I had using natd for a proxy for a while time, using > the command: > natd -p -proxy_only -proxy_rule "server 192.168.6.6 proto tcp" > > but when I use this in kernel nat config, I get a error infomation: > > # ipfw nat 20 config proxy_only proxy_rule server 192.168.6.6ipfw: > unrecognised option ``proxy_rule'' > I'd readed the src code in /usr/src/sbin/ipfw and can't find the > LibAliasProxyRule() function which is in the natd.c. > Does I have a mistake? Hi, it looks like proxy_rule was forgotten when it was ported. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panic: refcount inconsistency: found: 0 total: 1
On 04.11.2015 00:10, David Wolfskill wrote: > So... with the change from r290334, what's the point of the KASSERT? Yes, you are right. We changed this code and use it some time, but without INVARIANTS. I just removed this KASSERT in r290345. Can you try this revision? Sorry for the breakage. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPv6 NAT
On 30.04.16 20:34, Georgios Amanakis via freebsd-ipfw wrote: > Does anyone know if someone works on implementing IPv6 NAT (like IPv4 > NAT, not prefix translation only) in IPFW? As far as I can tell > FreeBSD's pf has this functionality. Linux implemented this since > kernel 3.9, too. Hi, we have implemented IPv6 NPT (RFC 6296) and basic NAT64 (stateless and statefull) for ipfw. Currently we are preparing to commit them into FreeBSD head/. I hope I'll do this in several weeks before 11.0 freeze. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
[RFC] ipfw named states support
Hi All,
We have the patch that adds named states support to ipfw.
The idea is that we add a symbolic name-label to each dynamic state in
addition to IP addresses, protocol and ports.
This introduces new syntax for check-state and keep-state rules:
check-state { token | default | any }
keep-state { token | default }
The @token can contain symbols from the following mask:
[a-zA-Z0-9\-_\.]{1,63}
How it works
"keep-state NAME" opcode creates state with assigned name NAME. This
state can be matched only by 'keep-state NAME' or 'check-state NAME', or
'check-state any' opcodes. The "default" name used for compatibility
with old rules. It is assigned to states when you omit the name on rule
creating. So,
# ipfw add check-state
# ipfw add allow ip from any to any keep-state
will produce:
check-state default
allow ip from any to any keep-state default
But there is one problem, when your rule has some opcodes after
'keep-state' opcode (e.g. "keep-state in"). Such opcodes can be treated
as state name.
'check-state any' matches states independently from the name.
Why we need this
This expands flexibility and functionality.
Imagine the situation:
[ LAN1 ] <---> [ FW ] <---> [ LAN2 ]
add skipto 1 ip from any to any via lan1
add skipto 2 ip from any to any via lan2
add deny ip from any to any
add 1 count ip from any to any
...
add allow ip from to any keep-state in
add deny ip from any to any
add 2 count ip from any to any
...
add allow ip from to any keep-state in
add deny ip from any to any
The problem is that a state created by first keep-state rule will act on
second keep-state rule and allow traffic to go into (out from router's
point of view) lan2 without any rules actually allowing that.
With named states we can create separate states for each interface and
they will not match when we don't want this.
What I want to discuss
--
1. Is this feature useful?
2. How to commit it? Due to changed syntax it can break existing
rulesets. Probably, we can add some mandatory prefix to state name, e.g.
':'.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: [RFC] ipfw named states support
On 30.05.16 07:56, Julian Elischer wrote: > On 18/05/2016 10:46 PM, Andrey V. Elsukov wrote: >> Hi All, >> >> We have the patch that adds named states support to ipfw. > > like it and have wished for this for along time > this allows per-interface state. Can state name be set to a variable we > can set or something? > then we could have subroutines that can be used for multiple interfaces. > (I guess we need variables first) You are specifying the name when adding rule. E.g. # ipfw add allow tcp from me to any out igb1 keep-state igb1 # ipfw -d show 100 00100 317 36316 allow tcp from me to any out via igb1 keep-state igb1 ## Dynamic rules: 00100 5 317 (246s) STATE tcp A.B.C.144 21131 <-> C.D.E.93 22 igb1 00100 0 0 (1s) STATE tcp A.B.C.144 22 <-> F.G.35.120 30876 igb1 # ipfw -d show 200 300 00200 440 42779 allow ip from table(1) to me in keep-state SOME_NET 00300 119 17416 allow tcp from me to any out keep-state MY_OUTGOUING ## Dynamic rules (3 424): 003004254 (286s) STATE tcp A.B.C.144 41280 <-> X.Y.178.135 22 MY_OUTGOUING 003003244 (1s) STATE tcp A.B.C.144 22 <-> C.D.E.93 26951 MY_OUTGOUING 00200 343 33995 (286s) STATE tcp F.G.35.120 62486 <-> A.B.C.144 22 SOME_NET >> With named states we can create separate states for each interface and >> they will not match when we don't want this. > what does the ipfw -d list output look like? The output is the same, just state name is added to the end of line. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 06.06.16 22:41, Lev Serebryakov wrote: > > I still hope to see https://reviews.freebsd.org/D1776 committed before > 11-RELEASE. > > It seems to me, that I does everything what was requested by reviewers. Hi Lev, looking at provided description and examples, seems the main task you want to solve is problem with NAT. But from my point of view, you are trying to solve it in a easy way wrongly using existing methods. As you described in patch to ipfw(8) "Problem is, you need to create dynamic rule before NAT and check it after NAT actions (or vice versa) to have consistent addresses and ports." In terms of ipfw(4) a state is represented by ipfw_flow_id structure. To solve your task you just needs two states - one for not translated flow and second - for translated. Due to limits of implementation this looks impossible to solve. But proposed patch with deferred action looks too hackish to me. With the following patch you will be able create two different states, I think, and solve your task with NAT and dynamic rules: https://reviews.freebsd.org/D6674 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 07.06.16 09:31, wishmaster wrote: >> With the following patch you will be able create two different states, I >> think, and solve your task with NAT and dynamic rules: >> https://reviews.freebsd.org/D6674 > > Will there be the patch in the 11-RELEASE? Hi, there are three patches for ipfw, that I want to commit: https://reviews.freebsd.org/D6420 https://reviews.freebsd.org/D6434 https://reviews.freebsd.org/D6674 But we are in code slush and there aren't any positive review yet. So, I guess they will be committed only after 11.0 would be branched. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 07.06.16 17:31, Ian Smith wrote:
> If your patch does what Lev wanted to achieve with (I thought too many)
> new dynamic rule actions, then I think your simpler solution is better,
> not least because it's far easier to understand for non-Julians :)
>
> Looking from a useability and documentation perspective only - I won't
> even be looking at this code - I have a few thoughts:
>
> Thus far, keep-state and limit seem to be interchangeable options; limit
> rules will need to work the same with respect to named dynamic flows; do
> I assume that you've just started with only keep-state for testing?
We don't use limit rules at all, so it wasn't implemented. I think it
will not so hard to implement.
> I think flow names should be specified as an _optional_ parameter, thus:
>
> check-state [name]
>
> keep-state [name]
>
> limit {src-addr | src-port | dst-addr | dst-port} N [name]
>
> where name (maybe flowname, for easier comprehension by man readers?) is
> optional, assigned as 'default' whenever omitted - as well as being for
> backwards ruleset compatibility, which then only needs mentioning once,
> and maybe also put another way in the STATEFUL FIREWALL section.
>
> So a few of the existing example rules with no name could stand, while
> others (see below) append names of OUTBOUND and INBOUND or whatever.
>
> As is, you have
>
> 740 .It Cm check-state Op Ar name | Cm any | Cm default
>
> which in other contexts would mean you have to supply one of 'name' or
> 'any' or 'default' when you don't have to provide one, 'default' being
> assigned otherwise. Otherwise I think this is fairly well described.
>
> Will 'ipfw -[e]d list|show' show the flow names? or the indices?
It will show the flow name at the end of line.
> As I pestered Lev about last year, we still need a small example ruleset
> section that actually deals with potentially problematic stateful issues
> with NAT - which I still don't fully understand - beyond descriptions in
> the abstract case; ie an actual working dual- or multi-flow example.
>
> I know these are "just doc" issues of little importance while testing
> working code, and I haven't supplied any patches, so are just FWIW ..
Will try to implement support for limit rules and update man. Thanks.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 10.06.16 00:11, Lev Serebryakov wrote: >> In terms of ipfw(4) a state is represented by ipfw_flow_id >> structure. To solve your task you just needs two states - one for >> not translated flow and second - for translated. > For what?! Logically it is one flow. NAT is kludge itself, of > course, but, IMHO, logically it doesn't create new flow, or > connection, whatever your name it. It hacks existing one. Your patch does exactly what I said - it creates state for untranslated flow when you call record-state with deferred action. Then after translation this flow has new addresses and ports, so ipfw_install_or_update_state() will create new state, old state will not updated (don't know for what purpose you have renamed it). Then when check-state/probe-state will be checked, both states can be updated by lookup_dyn_rule_locked() depending from flow that triggers this opcode. So, you introduced new implicit behavior while thinking that resolve old wrong behavior. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 15.06.16 17:49, Ian Smith wrote: > Ok, but you're regularly referring to multiple state _tables_, but I > think that what is proposed is one table with name added to protocol, > addresses and ports as a parameter rather than as distinct tables? > > Is that right, Andrey? As I said, I'm not looking at the code now. Internally it is implemented as one unsigned integer in addition to addresses and ports in flow structure. So, in general, there is still one hash table. > > I think flowname is a bad name.. it's a state table name. > > I don't think so. That was just a suggestion in place of generic 'name' > but the more I read your following message, which I'll respond to next, > the more I think you've made a good case for 'flowname', which Andrey > has used in latest review in ipfw(8). Onwards .. I updated the patch in https://reviews.freebsd.org/D6674 Also I reworked Lev's patch on top of my patch and made it simpler: https://reviews.freebsd.org/D1776#143557 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
