Re: bin/104921: [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (another variation on PR 91245)

k, but "deny ... NOT IPv6,IPv6,..." is hard to emulate (with multiple skipto rules). -- // Black Lion AKA Lev Serebryakov ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any

Re: bin/104921: [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (another variation on PR 91245)

The following reply was made to PR bin/104921; it has been noted by GNATS. From: Lev Serebryakov To: bug-follo...@freebsd.org, seh-10l...@mail.quadrizen.com Cc: freebsd-ipfw@FreeBSD.org, freebsd-...@freebsd.org Subject: Re: bin/104921: [patch] ipfw(8) sometimes treats ipv6 input as ipv4

Re: Firewall Profiling.

understand why it should be faster than "normal" way, as it is essentially same (ipfw + dummynet) code + some additional context switches for netmap (to userland and back). What does netmap shave off from packet processing in this particular case, to compensate context switches? I -- // Bla

Re: Firewall Profiling.

AKA Lev Serebryakov ___ 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: Firewall Profiling.

e generator is probably simpler > to write (perhaps reusing sys/i386/i386/bpf_jit_machdep.c and its > amd64 counterpart) Yep, as we have BPF JIT, it could be simpler. -- // Black Lion AKA Lev Serebryakov ___ freebsd-ipfw@freebsd.org mailing

How to configure nat for interface which will be created later?

llow to use non-existing interface name! It looks like very strict limitation, as it doesn't allow to include VPN to nat config! Is here any solution for this problem? - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: Gn

Re: How to configure nat for interface which will be created later?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02.02.2015 21:12, Lev Serebryakov wrote: > It is possible to use non-existing interface name in via / xmit / > recv option. It allows to write firewall which works with, say, > VPN connection which is created AFTER firewall is loade

[RFC][patch] Two new actions: state-allow and state-deny

000 state-allow from any to any // keep-state is implied add 2010 nat NR from any to any // No "out" here! add 2020 allow all from any to any add 3000 nat NR from any to any add 3010 check-state // Use dynamic rule based on 2000 as "allow" here What do you think? - -- //

Re: How to configure nat for interface which will be created later?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02.02.2015 21:19, Lev Serebryakov wrote: >> It is possible to use non-existing interface name in via / xmit / >> recv option. It allows to write firewall which works with, say, >> VPN connection which is created AFTER fir

Re: [RFC][patch] Two new actions: state-allow and state-deny

7;t solve problem of ugliness of hacks we need use to add statefullness. > looking at my own rules I don't seem to have a problem.. You have "check-state" only once, on entrance, before all NATs, so it could work only for packets which don't need NAT. And looks like (corr

Re: [RFC][patch] Two new actions: state-allow and state-deny

so you could not have ANOTHER "keep-state" before NAT in outgoing part or you miss nat completely (sate is created in outgoing path, and then checked before nat in outgoing path with "keep-state", gr, ugly!). - -- // Lev Ser

Re: [RFC][patch] Two new actions: state-allow and state-deny

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 12:30, Lev Serebryakov wrote: > "keep-state". Problem is, it adds "if" branch for EACH action (in > kernel code). IMHO, it is very prohibitive. I've though about > that, but decide it is too expen

"reass all from any to any" kills IPv6 packets

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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? - -- // Lev S

[RFC][patch] New "keep-state-only" option

pid "skipto", no "keep-state" at "incoming from local network" parts of firewall, nothing! P.S. I HATE this "all any to any" part! - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0POaXxSAAC4AKGlzc3Vlc

Re: [RFC][patch] New "keep-state-only" option (version 2)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 19:13, Lev Serebryakov wrote: > Ok, "allow-state"/"deny-state" was very limited idea. Here is more > universal mechanism: new "keep-state-only" (aliased as > "record-only") option,

Re: [RFC][patch] Two new actions: state-allow and state-deny

ose idea that was but it's just > wrong. (if the state exists, maybe just replace it..) Update, not replace :) See my Version-3 patch for "record-state" :) - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQ

[RFC][patch] New "keep-state-only" option (version 3)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 19:55, Lev Serebryakov wrote: >> Ok, "allow-state"/"deny-state" was very limited idea. Here is >> more universal mechanism: new "keep-state-only" (aliased as >> "record-o

Re: [RFC][patch] Two new actions: state-allow and state-deny

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 14:11, Julian Elischer wrote: > On 2/4/15 5:22 PM, Lev Serebryakov wrote: On 04.02.2015 08:13, > Julian Elischer wrote: > >>>> yes I think "keep-state" should be deprecated and replaced >>>>

Re: [RFC][patch] Two new actions: state-allow and state-deny

t (3). Nothing! And if "conditional (2)" may be too much, but only possible to go to (1) is via (2) and inevitable (3) after that is too much, IMHO! It is very obscure behavior! To be honest, I want add not only "keep-state-only&quo

Re: [RFC][patch] Two new actions: state-allow and state-deny

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 16:03, Lev Serebryakov wrote: > To be honest, I want add not only "keep-state-only" (pure (1)), > but, also have "keep-state-do-action-no-check" to have (1) + (3) > without (2). Ideally, here should not

Re: [RFC][patch] Two new actions: state-allow and state-deny

again), it will work. But now, when state creation is terminal action AND state checking in one box, it is hard to implement and leads to very non-intuitive rule sets. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0jiVXxSAAC4AKGlzc3V

[Differential] [Request, 190 lines] D1776: New options for ipfw - record-state, set-limit and skip-immediate-action - for simpler rulesets

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Looks like, there is no "freebsd-ipfw" mailing list from Phabricator's point of view. Please, review & comment! https://reviews.freebsd.org/D1776 - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: Gnu

does "nat redirect_port tcp" works for you on -CURRENT?

t work. Rule 30050 (udp one) HAS counters increased, but what is REALLY strange, is that 11040 and 11050 (two NAT actions) always have SAME counters, as if 11040 never change destination address. Nut 30050 sees some packets! Is "nat redirect_port tcp" broken in -CURRENT or do I do

Re: does "nat redirect_port tcp" works for you on -CURRENT?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05.02.2015 01:16, Lev Serebryakov wrote: > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > 192.168.134.2:22 2 Also, if I add "log" to this config

Re: does "nat redirect_port tcp" works for you on -CURRENT?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05.02.2015 01:16, Lev Serebryakov wrote: > I have such rules in my firewall: > > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > 192.168.134.2:22 2 &g

Re: does "nat redirect_port tcp" works for you on -CURRENT?

e one. Global ("nat config ip ...") or redirection-specific (redirect_port tcp 192.168.134.2:22 :2). I'll try to fix it. > And does all of this really need cross-posting to net@ as well as > ipfw@? I'm not sure :) CC: removed. - -- // Lev Serebryak

Please, review my change to ipfw, I want to commit it :)

simplify my firewall. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJVbGy7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePyo0QAN40kckbK0SYrXkaQU+9hEtY

Re: Please, review my change to ipfw, I want to commit it :)

e deferred action is itself a > 'skipto'. I like "defer" idea, thank you. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJVdYytXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCN

Re: keep-state and in-kernel NAT exposes local ip on external interface

24000 > nat 123 ip from any to any in recv em0 ... > > Why is this happening? Any objections to reversing the order of the > NAT rules? ___ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebs

Re: keep-state and in-kernel NAT exposes local ip on external interface

. > Way back on Wed, 1 Jul 2015 22:02:53 +0300, Lev Serebryakov wrote: >> On 30.06.2015 22:20, Georgios Amanakis via freebsd-ipfw wrote: >> >> It is good example for my changes :) All this "skipto / >> keep-state" magic is not understandable. > > Indeed. So

Re: [RFC] ipfw named states support

ich are keywords? Like variable names in conventional programming language. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature

IPFW: more "orthogonal? state operations, push into 11?

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. Please? -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature

Re: IPFW: more "orthogonal? state operations, push into 11?

and all of them suffer from this "keep-state is check-state" problem, really, when you try to structure your firewall in "ingress / egress" per-interface sections and not one small ruleset for one interface. - -- // Lev Serebryakov AKA

Re: IPFW: more "orthogonal? state operations, push into 11?

ntroduced new implicit behavior > while thinking that resolve old wrong behavior. Sorry, I lost you here. Why untranslated flow will trigger check opcode? It will be mistake in ruleset, for sure! - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP

Strange printing of rule with "unreach6" action

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

Re: IPFW: more "orthogonal? state operations, push into 11?

state)? > 2/ ability to keep-state without actually doing it < less important > for me. > 3/ multiple state tables? this was discussed and I thought I saw patches > but I haven't seen it going in, <-- super luxurious -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature

Re: IPFW: more "orthogonal? state operations, push into 11?

nobody against, I plan to commit this part in a several > days. Which implementation? Just curious, I could live with any, really. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature

Re: IPFW: more "orthogonal? state operations, push into 11?

, I have come to the opinion, that this will > be more readable. How will it differ from my implementation, with separate opcode? -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature

Re: IPFW: more "orthogonal? state operations, push into 11?

Hello Julian, Thursday, August 4, 2016, 6:42:45 AM, you wrote: > A combination is less useful for me as you need to do: I'm against this too, as I really love orthogonality, as everybody know already, and your example is good example why. > 20 skipto 400 tcp from table(2) to me setup record-s

names for limit states?

Hello Ae, Looks like you didn't add names support for states with limits? Why? -- Best regards, Lev mailto:l...@freebsd.org pgpseuX25vqa4.pgp Description: PGP signature

Re: names for limit states?

Hello Andrey, Sunday, August 14, 2016, 4:29:50 PM, you wrote: >> 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? :) Because I need to read code better, sorry! -- Best regards, Lev

Named states in ipfw

Hello Freebsd-ipfw, I've tried new build of 12-CURRENT (with new ipfw feature of named states), with OLD ruleset and I'm disappointed by user experience. Old ruleset contains a lot "keep-state" and "check-state" statements and all this "Ambiguous state names" noise is, really, noise. It looks r

Named states in ipfw (and old rulesets)

Hello Lev, Sunday, August 14, 2016, 8:20:16 PM, you wrote: > Line 155: Ambiguous state name '//', 'default' used instead. > : No error: 0 > 0 check-state default Ok, really this one is (no rule number, I'm rely on auto-numbering): add nat 2 // De-NAT add check-state // Make things

Auto-numbered rules with state or table opcodes are printed-out as ""number 00000" on addition

Hello Lev, Sunday, August 14, 2016, 8:27:02 PM, you wrote: When auto-numbering is used, all rules with any keep-state/check-state or table opcodes is printed out as number 0 on addition, like this: add 11000 allowdst-ip MCAST // Allow incoming multicast add deny n

Re: Named states in ipfw (and old rulesets)

Hello Andrey, Sunday, August 14, 2016, 9:01:15 PM, you wrote: >> 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

Re: Named states in ipfw (and old rulesets)

Hello Andrey, Sunday, August 14, 2016, 9:01:15 PM, you wrote: I have very formal objection against "any unknown token after *-state is state name": it hides mistakes and typos very well. I've been bitten by this right now. New patch uses "defer-action", but old "record-state skip-action" passes

Re: Named states in ipfw (and old rulesets)

Hello Lev, Monday, August 15, 2016, 1:32:49 AM, you wrote: > Please, change this to some prefix to state name (:name, @name or something > like this) or to "state-action(name)" format. It will be much better: less > error-prone and will work without ugly warnings on old rulesets. Or, maybe, sta

Re: Named states in ipfw (and old rulesets)

xisting rulesets working out of the box is vital too; the last > thing needed on managed remote boxes is firewall breakage on upgrading. Existing rulesets are not broken, but could give you non-intuitive warnings now :) -- // Lev Serebryakov AKA Black Lion signature.asc Description: OpenPGP digital signature