Re: flow table format specifier rules (14.0)
On 04.12.2023 12:52, adrian-ilarion ciobanu wrote: --- table(t4), set(0) --- kindex: 10, type: flow:proto,dst-port references: 0, valtype: legacy algorithm: flow:hash items: 0, size: 296 algorithm hash info size: 512 items: 0 itemsize4: 32 itemsize6: 56 #can't add a ipfw table t4 add 6,2 0 ignored: 6,2 0 ipfw: Adding record failed: Invalid argument Hi, this is due to implementation. Internally a flow table depends from address family and thus you need to specify an address. -- WBR, Andrey V. Elsukov
Re: ipfw + bridge + epair + tags for vnet jails after upgrade to 13.1
20.12.2022 13:50, Markus Graf пишет: I upgraded a host from 13.0 to 13.1 I can't have a physical interface as member of the jailbridge, because this leaks virtual mac addresses of epair interfaces to the outside world where my hoster looks unkindly on mac-addresses not belonging to the nic of my server. So I have vnet jails behind a common ifbridge. All jails have their default routes point to the bridge-interface of the host. The host works as a router. Tags stopped working across vnet and bridge --- On a long running host that is still currently running 13.0 I have this line in a vnet jail with an epair interface acme_j: allow tag 128 tcp from me to any 80,443 via acme_j setup uid root keep-state On the host I see the tags: # ipfw -a list 570 00570 112 11276 count tagged 128 On the updated 13.1 machine the host does not see the tags, or I can't get the host to count them. with epair0a being a member of the bridge. If I fetch a file in the vnet jail containing epair0b the counters of em0 and bridge0 increment, but the counter of epair0a does not increment. Tcpdump -i epair0a does show the traffic though. Hi, probably this commit caused your problem https://reviews.freebsd.org/D32663 -- WBR, Andrey V. Elsukov OpenPGP_signature Description: OpenPGP digital signature
Re: NPTv6: prefix doesn't change in IPFW when prefix changes on dynamic interface
24.11.2022 18:27, FreeBSD User пишет: Hello, running a small routing/firewall applicance based on 13-STABLE and IPFW, I face a problem with NPTv6. The external IPv6 is changing dynamically. While ipfw in-kernel NAT catch up with dynamical changes of the IPv4, NPTv6 doesn't seem so. I'm neither an expert in networking nor IPFW. After a couple of days tun0 (the exterior PPP interface, uplink connection managed via mpd5) has a lot of IPV6 addresses, all but one are marked "deprecated". In case nor mpd5 is restarted or the exterior interface is assigned with several IPv6 addresses of which all but one are marked deprecated, pinging the outside world via IPv6 will take the wrong IPv6 - IPFW doesn't seem to catch up with the changes. How to fix this? Hi, probably the easiest way to solve your problem is periodically running some script that will find and delete deprecated addresses from an interface. Then NPTv6 module will use first global prefix on the interface. -- WBR, Andrey V. Elsukov OpenPGP_signature Description: OpenPGP digital signature
Re: Throughput extremely decreases when IPFW 7000 mac based rules activated
10.08.2021 08:08, Eugene Grosbein пишет: > Such ruleset could decrease filtering overhead several times but I'm > afraid that ipfw is not right tool for this task at the moment. > > ipfw has "tables" to optimize large list matching and they perform > great but for layer3 IP matching, not for layer2 MAC matching. We have a patch that adds ability to keep MAC addresses in the tables. I hope we will push it into upstreem soon. -- WBR, Andrey V. Elsukov OpenPGP_signature Description: OpenPGP digital signature
Re: is there a way to Port DragonflyBSD's IPFW3 to FreeBSD
28.07.2021 16:05, alfadev via freebsd-hackers пишет: > These are some hard problems to me when i try to completely move on > IPFW. So is there a way to port IPFW3 to FreeBSD. Thanks for any help > and suggestions.. I think it is much easier just implement needed functional in the FreeBSD's ipfw, than doing porting ipfw from DragonFly. But you can try :) -- WBR, Andrey V. Elsukov OpenPGP_signature Description: OpenPGP digital signature
Re: Lookup tables with dst-port as argument
On 20.01.2021 18:26, Patrick Tracanelli wrote: > Hello FreeBSD community, > > I need to dynamically allocate filtering ports on a tuplet, table > would do the job, can I lookup the port argument from a table? > Something like: > > ipfw add count all from “table(blist)” to any dst-port tablearg in > > In the above example table blist was created as “ipfw table blist > create type number”. > > It certainly won’t work as above written since tablearg is not > supported for dst-port. > > Is there any other approach possible to reach this desired behavior? Hi, it seems you need to take alook at the 'lookup dst-port tablename' opcode. -- WBR, Andrey V. Elsukov ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Rule optimization
On 20.03.2020 21:12, driesm.michi...@gmail.com wrote: > What would be more efficient, theoretically? Below the two cases I'm > thinking about. > > Note that the first 4 commands of case 2 are not really action rules and are > just setting up the table which for the sake of example I included. Hi, I think for 3 interfaces you will not see some noticeable difference, but when number of interfaces in the table will grow to tens or hundreds, it will work much better than the plain list of the rules. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: nat64lsn first hop in traceroute has a source ip of the final host
On 26.11.2019 11:31, Marco van Tol wrote: > Did you find the time to look further into this? > If not I understand, no problem. > > Let me know if there's anything I can do to help. Hi, I'm sorry for the delay, I'll try to finish the patch at this weekend :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: nat64lsn first hop in traceroute has a source ip of the final host
On 25.10.2019 17:57, Marco van Tol wrote: > This all works great in that the guests have no IPv4 any more, and in > their point of view the entire world has migrated to IPv6-only. > > Is there a way to change this behaviour so that traceroutes to > synthesized addresses also report to be coming from the router IP on > the first hop? > > Thank you very much in advance! Hi, I think I know where is the problem, I'll try to make the patch at the weekend. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Look for an ipfw example using NPTv6
On 20.06.2019 17:35, Michael Sierchio wrote: > Oh, the problem is simply that my ISP assigns me a ::/64 but there is no > guarantee that it's mine for the duration. > > I'm in the process of securing my own IPv6 block, but was hoping for an > interim solution. > > One that occurred to me is to use a public ::/56 that's allocated (but > unused) to me in an AWS VPC. Route advertisements from them would make > them unusable directly, but then NPTv6 would work. > > Open to any suggestions ;-) You can use some own prefix with global IPv6 addresses in the internal network, and use NPTv6 with "ext_if external_ifname" option. It will automatically use configured on the external interface prefix. This feature is available in stable/12+. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Look for an ipfw example using NPTv6
On 19.06.2019 20:03, Michael Sierchio wrote: > On 18.06.2019 23:00, Michael Sierchio wrote: > > I'm looking for a simple firewall example using nptv6 to translate > > link-local addresses to match the prefix assigned by my ISP. I'll > be using > > stateful rules and allowing only outbound traffic. > > > > If you have a snippet, I'l be grateful. Thanks. > > NPTv6 module is targeted to translate routed traffic. IPv6 link-local > addresses are not forward-able. Thus you can not configure nptv6 > instance with such prefix. > Are you saying NPTv6 cannot rewrite a LL prefix to a public prefix, such > as the one held on the external interface? Yes. Link-local address must belong to the single "link", IPv6 scoped addresses architecture doesn't allow forward packets with link-local addresses from one link to another. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Look for an ipfw example using NPTv6
On 18.06.2019 23:00, Michael Sierchio wrote: > I'm looking for a simple firewall example using nptv6 to translate > link-local addresses to match the prefix assigned by my ISP. I'll be using > stateful rules and allowing only outbound traffic. > > If you have a snippet, I'l be grateful. Thanks. NPTv6 module is targeted to translate routed traffic. IPv6 link-local addresses are not forward-able. Thus you can not configure nptv6 instance with such prefix. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw: switching sets does stall the machine
On 14.06.2019 23:13, Peter wrote: > 2. There are dynamic rules involved. These do not disappear on a >"set disable". They stay and continue to function - somehow. > > 3. When a packet successfully matches a check-state, it does NOT >continue to be processed at the rule following that check-state. >Instead, it does continue to be processed at the place after >the parent keep-state rule that was originally matched! > >But what if that keep-state rule is now disabled, and the new >rules do not line up in their numbering in the exact same way? >Then this packet appears at some arbitrary place in the rule >list and may go to whereever. Dynamic rules use only "action" part of parent rule, so when dynamic state is "applied" to a packet, it just executes action of parent rule without checking the set to which belongs the rule. But then, if a packet processing is continued, the next rule checked from the beginning, and thus its set is checked. >Obviousely this is not an issue if you do keep-state with simple >Allow or Deny rules - then the packets leave the system after >matching. >But such simple keep-state do not work with NAT. For NAT one needs >a more elaborate approach, like tagging and branching and >subroutine calling. > > So the outcome is: > >When switching sets with such a configuration that introduces >branches and subroutines, the old and new rules need to precisely >line up to each other, so that the old dynamic rules (which should >be kept for the network sessions to persist) can reinsert their >matched packets at places where correct further processing happens. > >Doesn't seem like an easy task... You may try 11.3-BETA where new implementation of dyn_keep_states was committed. When you set net.inet.ip.fw.dyn_keep_states=1, the dynamic states aren't deleted with their parents rules. They are kept until expiring or explicit deletion (with -D flag). But the next rule for states that don't stop packet processing is the last rule. This is probably will not fit your requirements. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Patch to have ipfw0 work properly in jails
On 12.02.2019 10:24, Rudy (bulk address) wrote: > > Never submitted a patch... is this good enough? > > Problem: ipfw logs in a way that is confusing in jails (it logs to the > host syslogd) > Solution: use ipfw0 and make sure to fix up syslog and launch tcpdump if > firewall_logif is set in rc.conf Hi, for what purpose do you use ipfw0? Running tcpdump and logger looks very ugly. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Dummynet + PF
On 09.02.2019 13:22, Goran Mekić wrote: > Hello, > > Couple of us hackers talked to Kristof about adding Dummynet support to > PF. The inspiration comes from Apple having implemented the same: > https://github.com/apple/darwin-xnu/blob/master/bsd/net/pf.c#L126 > > What would be required to make dummynet work with PF? Currently, > dummynet depends on IPFW, so I guess decoupling is one of the tasks? Hi, I think it doesn't really depend from ipfw, you can just remove this dependency from ip_dummynet.c. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw -N show
On 11.12.2018 19:55, Claudio Eichenberger wrote: > I didn't install anything. I applied the patches to this file > /usr/src/sbin/ipfw/ipfw2.c compiled the kernel & booted These patches are not for kernel, you need to rebuild only sbin/ipfw utility. You can do this: # make -C /usr/src/sbin/ipfw all install -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw -N show
On 11.12.2018 16:01, Claudio Eichenberger wrote:
> Hello Andrey,
>
> I applied both patches:
>
>
> sigma# diff -u ipfw2.c-000 ipfw2.c
> --- ipfw2.c-000 2018-12-11 13:01:01.370594000 +0100
> +++ ipfw2.c 2018-12-11 13:04:25.132233000 +0100
> @@ -1251,7 +1251,8 @@
> (cmd->o.opcode == O_IP_SRC || cmd->o.opcode == O_IP_DST) ?
> 32 : contigmask((uint8_t *)&(a[1]), 32);
> if (mb == 32 && co.do_resolv)
> - he = gethostbyaddr((char *)&(a[0]), sizeof(u_long),
> AF_INET);
> + he = gethostbyaddr((char *)&(a[0]), sizeof(in_addr_t),
> + AF_INET);
> if (he != NULL) /* resolved to name */
> bprintf(bp, "%s", he->h_name);
> else if (mb == 0) /* any */
> @@ -1492,6 +1493,7 @@
> bprintf(bp, " %s", pe->p_name);
> else
> bprintf(bp, " %u", cmd->arg1);
> + state->proto = cmd->arg1;
> break;
> case O_MACADDR2:
> print_mac(bp, insntod(cmd, mac));
> @@ -1963,10 +1965,10 @@
>struct show_state *state)
>{
> ipfw_insn *cmd;
> - int l, proto, ip4, ip6, tmp;
> + int l, proto, ip4, ip6;
>
> /* Count all O_PROTO, O_IP4, O_IP6 instructions. */
> - proto = tmp = ip4 = ip6 = 0;
> + proto = ip4 = ip6 = 0;
> for (l = state->rule->act_ofs, cmd = state->rule->cmd;
> l > 0; l -= F_LEN(cmd), cmd += F_LEN(cmd)) {
> switch (cmd->opcode) {
> @@ -2002,18 +2004,13 @@
> if (cmd == NULL || (cmd->len & F_OR))
> for (l = proto; l > 0; l--) {
> cmd = print_opcode(bp, fo, state, O_PROTO);
> - if (cmd != NULL && (cmd->len & F_OR) == 0)
> + if (cmd == NULL || (cmd->len & F_OR) == 0)
> break;
> - tmp = cmd->arg1;
> }
> /* Initialize proto, it is used by print_newports() */
> - if (tmp != 0)
> - state->proto = tmp;
> - else if (ip6 != 0)
> - state->proto = IPPROTO_IPV6;
> - else
> - state->proto = IPPROTO_IP;
> state->flags |= HAVE_PROTO;
> + if (state->proto == 0 && ip6 != 0)
> + state->proto = IPPROTO_IPV6;
>}
>
>static int
>
>
> unfortunately, ipfw -N show still doesn't print the protocols:
>
> 00800 0 0 allow tcp from any to x.x.x.x 443 in recv bce0
>
Did you reinstall the patched version of ipfw(8)?
# ipfw add count tcp from any to ya.ru 443 out xmit lagg0
00100 count tcp from any to 87.250.250.242 443 out xmit lagg0
# ipfw -N show 100
00100 0 0 count tcp from any to ya.ru https out xmit lagg0
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: ipfw -N show
On 10.12.2018 17:27, Claudio Eichenberger wrote: > Hello, > > ipfw -N show > FreeBSD 11.1 was like this: > 00600 712189 84865042 allow tcp from any to x.x.x.x dst-port https > in recv bce0 > FreeBSD 11.2 is like this: > 00600 712189 84865042 allow tcp from any to x.x.x.x 443 in recv bce0 > Does a flag exist to make it report the the old way? > Many thanks in advance for your answer Hi, I just committed two fixes that should solve your problem: https://svnweb.freebsd.org/base/head/sbin/ipfw/ipfw2.c?view=log You can try to apply some of latest patches from this commit log to your source code and then test. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Configuring IPv6 on jails
On 29.10.2018 20:46, Dries Michiels wrote: >>> Isn't there a way to let IPFW determine what interface to use (and >>> thus IPv6 >>> prefix) for external translation? (for IPv4 NAT there is no need to >>> specify the external IPv4 address) >> >> Hi, >> >> I think I can add this feature to ipfw_nptv6 module, but I need some spare >> time to implement it. If you are interested, I'll send the patch to you >> later. >> What version do you use? I suspect the patch will use some features, that are >> present only in head/ yet. > > Would be nice! I’m on 12-STABLE. Hi, I published the patch: https://reviews.freebsd.org/D17765 For stable/12 you need to apply patch from r339537: https://reviews.freebsd.org/D17100 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Configuring IPv6 on jails
On 29.10.2018 17:56, Dries Michiels wrote: > * Use IPFW IPv6 prefix translation for the jail /64 prefix; translate > between global routable /64 prefix and fd00::1/64 (as example). The latter > can be statically configured in jail.conf. > > My problem here is that the IPFW rule needs the external prefix as an > argument. My prefix is dynamic so this might be tricky and indicates > scripting to me. > > Isn't there a way to let IPFW determine what interface to use (and thus IPv6 > prefix) for external translation? (for IPv4 NAT there is no need to specify > the external IPv4 address) Hi, I think I can add this feature to ipfw_nptv6 module, but I need some spare time to implement it. If you are interested, I'll send the patch to you later. What version do you use? I suspect the patch will use some features, that are present only in head/ yet. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: net.inet.ip.fw.dyn_keep_states (was: ipfw managing rules - best practice?)
On 25.10.2018 12:09, Ole wrote: > So do you think the bug is only related to 'setup' and not to 'keep-state' > rules? Or is this just a coincidence? > Im reloading rules now for 1h each minute, and a ssh connection is still > stable. Hi, I think you do not quite understand how it works :) Dynamic states do not work automagically. In general words, you have two types of firewall rules - static and dynamic. Static rules are kept in an array and checked by firewall until some action will be applied, that will finish the search. Dynamic rules have special opcodes, that initiate the search in dynamic states. And if a packet doesn't have a match in these dynamic states, new dynamic state will be created for this packet. If some state matches a packet, then corresponding action will be applied for this packet. This is why usually "check-state" rule added to the beginning of rules. A packet will be checked first for match in dynamic states, and only then it will be checked by static rules. So, when you have many rules and states, doing `ipfw flush` will delete all static rules, but depending from keep_states sysctl variable, dynamic states can be kept or deleted. So, if you will do `ipfw -q flush` and do not add new dynamic rule, all dynamic states will expire after some time and will be deleted (regardless of the fact you have keep_states=1). But, when you are doing `flush` and then reload new rules, that have some dynamic rules (those that have "keep-state" or "limit" opcodes), this means that new rules will initiate the search in dynamic states, and for existing connection the state will be updated and because of this, the connection is still work. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw managing rules - best practice?
On 24.10.2018 19:22, Ole wrote: > # ipfw -d list > (...) > 01510 allow tcp from any to xx.xx.xx.xx 6514 out via epair0b setup keep-state > :default > (...) > ## Dynamic rules (1 152): > 01510 STATE tcp yy.yy.yy.yy 54451 <-> xx.xx.xx.xx 6514 :default > > # ipfw -q flush > > # ipfw -d list > 65535 allow ip from any to any > ## Dynamic rules (2 288): > Segmentation fault (core dumped) This problem is related to named states, the kernel doesn't dump list of known states names, and this is the cause of SIGSEGV. I have the WIP patch https://people.freebsd.org/~ae/keep_states.diff It fixes this problem and also add support for all rule actions. Also it adds new -D flag, that allows to show only states and delete only states. I have tested it basically, but it probably needs some work related to "limit" dynamic states. So if you want to test some patches, you can try :) I tried to apply the patch and observed that stable/11 has a small difference in UMA code, so you need to use this patch: https://people.freebsd.org/~ae/keep_states11.diff Again, I did not yet teseted it widely, and on stable/11 did not tested at all. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw managing rules - best practice?
On 05.09.2018 12:28, Ole wrote: > I understand, that this connections get broken because the dynamic > rules get flushed with the `ipfw -q -f flush` command. But commenting > this command out results in a continuously growing rules table. > > With the `ipfw -d list` command I can see the dynamic rules. > Is there a way to flush the rules but not the dynamic ones? > Or to add them again after flush? There is net.inet.ip.fw.dyn_keep_states sysctl variable. It allows to keep dynamic state when parent rule is deleted. But you need to use default_to_accept firewall to make it working. I plan to reimplement this feature to be more useful and work with any rules, and not only with "allow" rules. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw uid/gid debugging, tcpdump relation with ipfw and how to block direct access to port 25
On 04.07.2018 15:28, supportsobaka--- via freebsd-ipfw wrote:
> Could you please explain whether tcpdum should see a packet dropped
> on ipfw?
tcpdump is not related to ipfw. ipfw(4) has ability to send packets,
that are matched by rules with "log" opcode to special ipfw0 pseudo
interface. This interface can be created at run-time. Then, you can add
"log" keyword to the deny rule and see such packets in `tcpdump -ni
ipfw0` output.
Simple example:
# ifconfig ipfw0 create
# ipfw add 1 deny log icmp from me to any
# ping 127.1
# tcpdump -ni ipfw0
12:21:19.222133 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151,
seq 0, length 64
12:21:20.230762 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151,
seq 1, length 64
> Does it look before or after ipfw? tcpdump -vvv port 25
> shows nothing when port is blocked on ipfw (security log shows droped
tcpdump works at layer2 level. The kernel sends packets to BPF when it
goes through ethernet handling routines.
ipfw(4) usually works at layer3 level, i.e. when Ethernet layer already
did, or not yet did its work. Anyway, you can not see dropped packets if
you did not prepared to this like I described.
> packets). Also, is there a way to to see uid/gid on the packet in
> ipfw log? Alternatively, can tcpdump show uid/gid of the packet
> (before ipfw)? I don't see uid/gid when use tcpdump -vvv port 25. Is
> there a way to understand if packet does't have uid/gid or it just
> not shown? I can't figure out a good rule to protect access to port
tcpdump has not such ability or knowledge.
> 25 for other than sendmail (yep, native sendmail). The obvious
> ${ipfw} add allow tcp from me to any 25 out gid smmsp setup
> keep-state :emailfromme doesn't work (email is not sent out,but
> dropped on the ipfw by the last deny rule). Seems like the packet
how do you test this?
> sent by sendmail doesn't belong to snmmsp group. I have tried gid
> operator gid mail gid smmsp gid wheel - won't help. How to debug?
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: In-kernel NAT [ipfw] dropping large UDP return packets
On 13.06.2018 23:04, Jeff Kletsky wrote:
>> The kernel version of libalias uses m_megapullup() function to make
>> single contiguous buffer. m_megapullup() uses m_get2() function to
>> allocate mbuf of appropriate size. If size of packet greater than 4k it
>> will fail. So, if you use MTU greater than 4k or if after fragments
>> reassembly you get a packet with length greater than 4k, ipfw_nat()
>> function will drop this packet.
>>
> Thanks!!
>
> Mystery solved...
>
> /usr/src/sys/netinet/libalias/alias.c
>
> #ifdef _KERNEL
> /*
> * m_megapullup() - this function is a big hack.
> * Thankfully, it's only used in ng_nat and ipfw+nat.
>
> suggests that the "old school" approach of natd might resolve this. I'll
> give it a try when I'm close enough to the box to resolve it when I make
> a configuration error.
I didn't look at the rest of libalias, but you, probably, can improve
this hack to use 9k or 16k mbufs. You can replace m_get2() call in
m_megapullup() with the following code:
if (len <= MJUMPAGESIZE)
mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
else if (len <= MJUM9BYTES)
mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES);
else if (len <= MJUM16BYTES)
mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM16BYTES);
else
goto bad;
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: In-kernel NAT [ipfw] dropping large UDP return packets
On 13.06.2018 20:16, Jeff Kletsky wrote: > When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC > tunnel to the T-Mobile provisioning servers, the reassembled, 4640-byte > return packet is silently dropped by the in-kernel NAT, even though it > "matches" the outbound packet from less than 100 ms prior. > Are there known causes and/or resolutions for this behavior? > > Is there a way to be able to "monitor" the NAT table? > > (I didn't see anything obvious in the ipfw, natd, or libalias man pages.) The kernel version of libalias uses m_megapullup() function to make single contiguous buffer. m_megapullup() uses m_get2() function to allocate mbuf of appropriate size. If size of packet greater than 4k it will fail. So, if you use MTU greater than 4k or if after fragments reassembly you get a packet with length greater than 4k, ipfw_nat() function will drop this packet. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Matching rules on ip4/ip6 with udp/tcp
On 06.06.2018 20:36, Dries Michiels wrote: > Dear Mailing List, > > Is there are way to match packets specifying both network generation ip4 or > ip6 together with the protocol such as tcp or udp? > > Currently the following rules are possible (examples): > > ipfw add 1 allow udp from any to me 22 in recv em0 > > The following rule is not possible (example): > > ipfw add 1 allow ip4 udp from any to me 22 in recv em0 You can use "proto" option: ipfw add 1 allow ip4 from any to me 22 in recv em0 proto tcp ipfw add 1 allow tcp from any to me 22 in recv em0 not proto ip6 ipfw add 1 allow ip6 from any to me 22 in recv em0 proto tcp -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Missing sysctl net.inet.ip.fw.dyn_keep_states on FreeBSD 11.2
On 20.05.2018 11:00, 藍挺瑋 wrote: > Hello, > > I upgraded my desktop system from FreeBSD 11.2-BETA1 last week, and I found > the > sysctl 'net.inet.ip.fw.dyn_keep_states' got removed. I upgraded it again to > FreeBSD 11.2-BETA2 today, and I still could not find it. Currently I rely on > both 'net.inet.ip.fw.default_to_accept=1' and > 'net.inet.ip.fw.dyn_keep_states=1' > to be able to reload firewall rules with 'service ipfw restart' without > breaking > existing TCP connections. As this sysctl variable is still mentioned in > ipfw(8) > man page, will it be brought back in future versions, or there will be an > alternative solution for firewall rules reload? Hi, I'll try to implement this feature in this new implementation and will report back to you. Unfortunately, it will not appear in 11.2-RELEASE, but I think it can be resurrected in 11.2-STABLE and 12.0-RELEASE. I'm sorry about that. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: removing some error states
On 02.05.2018 06:31, Julian Elischer wrote: >>>> Many years ago I added code to ipfw so that if -q was set it would not >>>> complain about >>>> things that were unimportant, nor would it return an error code. >>>> Such things include removing table entries that are already gone and >>>> similar sorts of 'safe' operations. >>>> The idea is that you can write 'naive' scripts that don't need to do >>>> complicated checks to see if XXX is already present or gone.. >>>> In hte ame way that rm -f doesn't complain if the file doesn't >>>> exist..? You were going to delete it anyhow. Hi, I added melifaro@ to CC list. IMHO, ignoring errors when you configuring firewall is not a good idea. I'm agree, that some errors are noisy, and also some of them were already fixed, so you can just submit PR or patch, if you don't like some. Due to huge difference between old tables and what we have now, it is not always possible for one man to test all old features and properly merge them with new features. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW and FTP client behind NAT
On 14.02.2018 09:35, wishmaster wrote: > The issue is with the second remote server. When I transmit a very big file, > the control channel does not "recreated" and transmitting this file and all > the next is always fails. > > root@xxx: ipfw -d show|grep '111.222.0.7' > 03200 2985778 2299927348 (300s) STATE tcp 111.222.0.253 63307 <-> > 111.222.0.7 44678 :nts > 03200 594622 (6s) STATE tcp 111.222.0.253 63623 <-> 111.222.0.7 > 21 :nts > > root@xxx: ipfw -d show|grep '111.222.0.7' > 03200 3137837 2414765852 (300s) STATE tcp 111.222.0.253 63307 <-> > 111.222.0.7 44678 :nts > > The main server/router uses IPFW and in most places dynamic rules. Is > workaround I have added one rule on external interface: > > $cmd 5153 allow log tcp from any 21 to any 1024-65535 # ipfw - ftp issue > > But I want find the problem. ipfw starts send keep-alive TCP segments when dynamic state's lifetime is below than 20 seconds. If foreign host replies to keep-alive segment, the state's lifetime will be bumped up to 300 seconds (by default). Otherwise the state will be expired. In your case I guess the foreign host doesn't reply to keep-alive segments, probably due to it has lower value of state's lifetime. And when your host starts sending keep-alive requests, the foreign host has already dropped this state. You can try to decrease net.inet.ip.fw.dyn_ack_lifetime value and determine the value that will be enough for this host. For example, set it to 250, 200, 150, 100. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: FreeBSD11 ipfw sets.
On 13.02.2018 14:14, dam...@damianek.be wrote: > Now same on 11.1-RELEASE-p4 amd64 amd64 1101001 - generic kernel > with ipfw_load="YES" in /boot/loader.conf > > :~ # ipfw add count tcp from any to any 22 > 0 count tcp from any to any dst-port 22 > :~ # ipfw show > 0 19 1720 count tcp from any to any dst-port 22 > :~ # ipfw set move rule to 2 > :~ # ipfw -S set 2 show > :~ # ipfw set 2 delete > ipfw: rule not found > ~ # ipfw delete > > I'm doing some wrong, or bug? Hi, I think this should be fixed in freebsd11-stable. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224555 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces
On 09.01.2018 12:28, O. Hartmann wrote: > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > also an example: > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > Can someone explain a bit more what the semantics of these is? I get > especially > confused by the subsequent blocks of text following the line I mentioned > above. > Since not everybody using FreeBSD is capable of studying the kernel sources, I > have difficulties to put those statements in line with a visualization of the > packet flow. A local host receiving a packets destined for the local host can > not have xmit interface? If I imagine, that the recv interface might be the > interface adjacent directly to the in/out port depicted in section PACKET FLOW > it doesn't give me any idea why there is no xmit interface. When your system has two interfaces ed0 and ed1, and it acts as router, a forwarded packet can be checked by firewall two times: 1. When a packet is received on ed0 interface, mbuf associated with this packet gets a property "receiving interface". This packet is checked for inbound direction and can be matched by "in" and "recv ed0" opcodes. If it was not dropped by rules, it will go through IP stack and can be forwarded according to routing table via interface ed1. 2. When the routing decision was made (i.e. outbound interface is determined) a packet checked by firewall again, now for outbound direction. And it can be matched by "out" and "xmit ed1" opcodes. The opcode "recv ed0" still can be matched too, but "in" opcode will not matched. A packet destined for local host is consumed by local IP stack and will not forwarded. It is checked by firewall only one time (usually). Thus it can not have xmit interface. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw pipe show yields "REDZONE: Buffer overflow detected..."
On 19.12.2017 16:17, David Wolfskill wrote: > Similarly; "ipfw sched show" yields: > Dec 19 13:08:54 g1-252 kernel: REDZONE: Buffer overflow detected. 16 bytes > corrupted after 0xf80232e73748 (328 bytes allocated). > Dec 19 13:08:54 g1-252 kernel: Allocation backtrace: > Dec 19 13:08:54 g1-252 kernel: #0 0x80d49299 at redzone_setup+0xe9 > Dec 19 13:08:54 g1-252 kernel: #1 0x80a1175d at malloc+0x22d > Dec 19 13:08:54 g1-252 kernel: #2 0x80c95e07 at dummynet_get+0x337 > Dec 19 13:08:54 g1-252 kernel: #3 0x80ba4102 at rip_ctloutput+0x102 > Dec 19 13:08:54 g1-252 kernel: #4 0x80ac2d9d at sogetopt+0xcd > Dec 19 13:08:54 g1-252 kernel: #5 0x80ac756b at kern_getsockopt+0xdb > Dec 19 13:08:54 g1-252 kernel: #6 0x80ac7462 at sys_getsockopt+0x52 > Dec 19 13:08:54 g1-252 kernel: #7 0x80e3a66a at amd64_syscall+0xa6a > Dec 19 13:08:54 g1-252 kernel: #8 0x80e1cedb at Xfast_syscall+0xfb > Dec 19 13:08:54 g1-252 kernel: Free backtrace: > Dec 19 13:08:54 g1-252 kernel: #0 0x80d49604 at redzone_check+0x304 > Dec 19 13:08:54 g1-252 kernel: #1 0x80a117b6 at free+0x46 > Dec 19 13:08:54 g1-252 kernel: #2 0x80c9623d at dummynet_get+0x76d > Dec 19 13:08:54 g1-252 kernel: #3 0x80ba4102 at rip_ctloutput+0x102 > Dec 19 13:08:54 g1-252 kernel: #4 0x80ac2d9d at sogetopt+0xcd > Dec 19 13:08:54 g1-252 kernel: #5 0x80ac756b at kern_getsockopt+0xdb > Dec 19 13:08:54 g1-252 kernel: #6 0x80ac7462 at sys_getsockopt+0x52 > Dec 19 13:08:54 g1-252 kernel: #7 0x80e3a66a at amd64_syscall+0xa6a > Dec 19 13:08:54 g1-252 kernel: #8 0x80e1cedb at Xfast_syscall+0xfb > > > Yesterday was the first full day of running the laptop with FQ-CoDel > implemented, and I noticed that in the evening, things (such as > echoing charcaters in an xterm) would "pause" for a second or two, > fairly randomly. I can't say that the above were associated with the > pauses, but they are associated with the commands -- this is trivially > reproducible (for me, anyway). It would be nice if you created PR where you described steps to reproduce this. Your kernel/modules config, commands you used to get this result. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw kernel NAT performance much worse in 11-Stable than 10-Stable
On 31.08.2017 15:10, Graham Menhennitt wrote: > On 10-Stable, the interface is re1. The output of 'ifconfig re1 | grep > options' is: > options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> > > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > > On 11-Stable (the one with the problems), it's igb1 and the output of > 'ifconfig igb1 | grep options' is: > options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6> > > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > You need to disable TSO on your interface, ipfw nat is not compatible with TCP segmentation offloading (this is noted in ipfw(8) BUGS section). Try to use: ifconfig igb1 -vlanhwtso -tso4 You can add these option to "ifconfig_igb1" variable in rc.conf. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw kernel NAT performance much worse in 11-Stable than 10-Stable
On 31.08.2017 13:01, Andrey V. Elsukov wrote: >> Does anybody please have any ideas on this, please? > > Can you show the output of `ifconfig igb1 | grep flags` on stable/10 and > stable/11? Sorry, I wanted to write `ifconfig igb1 | grep options`. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw kernel NAT performance much worse in 11-Stable than 10-Stable
On 29.08.2017 12:33, Graham Menhennitt wrote: > However, the performance on the 11-Stable box is much worse. For file > transfers I get about 1/10th the speed. Incoming TLS connections often > fail to establish. Looking (from outside the box) at the interface in > Wireshark shows lots of packets being retransmitted. > > This appears to be due to the NAT rule. If I remove that, the > performance jumps up to be approximately the same as the 10-Stable box. > The rules are pretty simple: > nat 1 config if igb1 deny_in same_ports redirect_port udp > XXX.XXX.XXX.XXX: > nat 1 ip4 from any to any via igb1 > > I can provide the full set of rules if needed, but I think only those > two lines are relevant. > > Does anybody please have any ideas on this, please? Can you show the output of `ifconfig igb1 | grep flags` on stable/10 and stable/11? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Named states in ipfw (and old rulesets)
On 14.08.16 20:27, Lev Serebryakov wrote: > But looks like, that comment is lost here, here is output of "ipfw show" > after boot: > > 13050 0 0 nat 2 ip from any to any // De-NAT > 13060 0 0 check-state default > 13070 0 0 skipto 3 ip from any to any // Allowed local services > - common block > > So, yes, comment is lost! It looks it never worked due to "goto done" in the code. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: names for limit states?
On 14.08.16 15:04, Lev Serebryakov wrote: > Hello Ae, > > Looks like you didn't add names support for states with limits? Why? For me it looks like I did that. Why would you think differently? :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 04.08.16 06:58, Julian Elischer wrote: > o while thinking about states etc, it occured to me, what does THIS do > on subsequent packets in the session? > > > 10 skipto tablearg tcp from table(3) to me keep-state I think it will not work like you expected when you have created this rule :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 04.08.16 06:42, Julian Elischer wrote: > so it's a combination of #1 and #2 in my list. I think I originally > thought of having just #1. > > A combination is less useful for me as you need to do: > > 20 skipto 400 tcp from table(2) to me setup record-state > 21 skipto 400 tcp from table(2) to me setup > to make the entire session do the same thing. So, in your example what wrong with just using keep-state? "record-state without immediate action" == "keep-state without implicit check-state" needed to solve issues with NAT or something similar, that was described by Lev. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 03.08.16 22:07, Lev Serebryakov wrote: > On 03.08.2016 21:03, Andrey V. Elsukov wrote: > >>> 1/ ability to use keep-state without an implicit check-state. <--- most >>> important for me. (store-state)? >>> 2/ ability to keep-state without actually doing it < less important >>> for me. >> So, if there are nobody against, I plan to commit this part in a several >> days. > Which implementation? Just curious, I could live with any, really. This one https://people.freebsd.org/~ae/ipfw.diff but with separate opcodes, I have come to the opinion, that this will be more readable. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: your thoughts on a particualar ipfw action.
On 02.08.16 11:08, Julian Elischer wrote: > SO I was thinking how to use this, and the obvious way would be to have > a set of rules for each country, and use the "skipto tablearg" facility > to skip to the right rules for each country. But the trouble is that a > tablearg skipto is very inefficient. It's also a hard thing to set up > with a set of rules for each country (how many countries are there in > the internet allocation system?). You can build ipfw with enabled LINEAR_SKIPTO and use the same rules for most countries. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Significant missing item in 11.0 release notes
On 01.08.16 18:43, Ian Smith wrote: > Fast work Andrey, and sorry for rushing in. I ASSumed, after reading > the new tables section in 11.0-R ipfw(8), that Kevin had run into: > > Tables require explicit creation via create before use. > > but diving - not too deeply - into the log of /head/sbin/ipfw/tables.c > from your commit, I think that statement must be out of date, at least > regarding existing ruleset table configuration? Is that right? If you want to use some new specific feature you need to create table explicitly. But for old rules generic tables will be created automatically (with warning). -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Strange printing of rule with "unreach6" action
On 19.07.16 21:25, Lev Serebryakov wrote: > > ipfw add 16005 unreach6 address ipv6 from any to 2001:4de0:ac10::1:1:14 > > gives > > unreach6 address16005 ip6 from any to 2001:4de0:ac10::1:1:14 > > And "ipfw show 16005" prints (some spaces between columns are removed) > > unreach6 address16005 80 5574 ip6 from any to 2001:4de0:ac10::1:1:14 I think it should be fixed after r297981. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ALPHA3 panic with ipfw+dummynet and gif/gre tunnels
On 17.06.16 04:03, Mark Felder wrote: > #8 0x80eb7a64 in trap (frame=0xfe0122831770) at > /usr/src/sys/amd64/amd64/trap.c:442 > #9 0x80e97f91 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #10 0x80c57ebc in ip6_output (m0=, > opt=, ro=, flags= optimized out>, im6o=0x0, ifpp=0x0, inp=) > at /usr/src/sys/netinet6/ip6_output.c:1060 > #11 0x82661fd2 in dummynet_send (m=) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800 > #12 0x82661890 in dummynet_task (context=, > pending=) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:746 > #13 0x80a9a1ac in taskqueue_run_locked (queue= out>) at /usr/src/sys/kern/subr_taskqueue.c:465 > #14 0x80a9acf8 in taskqueue_thread_loop (arg= out>) at /usr/src/sys/kern/subr_taskqueue.c:719 > #15 0x80a0b3e4 in fork_exit (callout=0x80a9ac70 > , arg=0x8266c8a8, > frame=0xfe0122831c00) at /usr/src/sys/kern/kern_fork.c:1038 > #16 0x80e984ce in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:611 > #17 0x in ?? () Hi, this is known issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209466 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162558 It looks the same, but for IPv6. -- 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
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 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 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 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: [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
[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: 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
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: 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: 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: 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: 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: 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: 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=revisionrevision=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=revisionrevision=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
[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: 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
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: 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 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: 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 a...@freebsd.org 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: 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 a...@freebsd.org 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/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 a...@freebsd.org To: bug-follo...@freebsd.org, poo...@hotmail.com, Vladislav Yershov vyers...@umc.com.ua 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/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 a...@freebsd.org 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 a...@freebsd.org 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/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 bu7c...@yandex.ru 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: 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 bu7c...@yandex.ru 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/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 a...@freebsd.org To: Ildar Hizbulin hi...@vyborg.ru 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: 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/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: 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: 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: 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: 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 some_cmd`. 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: 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/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/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:
action [{modip [DF|TOS|DSCP|TTL]}] rule body
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: 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: 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: 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 size100K 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: 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 ipfw_chk (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
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: 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: 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]
[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 some command). 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: 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]
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/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: 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]
[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]
