[Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #28 from WHR --- This testing OS is installed from the latest 13.0-CURRENT snapshot built image that I downloaded today, specifically, http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20190718-r350103-disc1.iso.xz The source code is installed along with other parts from the installer, in /usr/src/ > Do you have INVARIANTS and WITNESS enabled in your kernel? Yes, the prebuilt snapshot images have those enabled. > Send me a copy of your ipf.conf and ipnat.conf, please. Since this is a fresh installation for testing, no rules exist in ipfilter config files. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #27 from Cy Schubert --- I'm having no such problems as you are. Do you have INVARIANTS and WITNESS enabled in your kernel? Send me a copy of your ipf.conf and ipnat.conf, please. If you use ippool, that too, please. Except for rules with arguments out of order I cannot reproduce your problem on any of my four firewalls. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #26 from WHR --- (In reply to Cy Schubert from comment #23) This patch seems break adding rules: [root@ipfilter-test /usr/obj]# kldload usr/src/amd64.amd64/sys/modules/ipfilter/ipl.ko [root@ipfilter-test /usr/obj]# kldstat Id Refs AddressSize Name 17 0x8020 24ffe50 kernel 21 0x82819000 2538 intpm.ko 31 0x8281c000 a50 smbus.ko 41 0x8281d0003b468 ipl.ko [root@ipfilter-test /usr/obj]# echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - 8:1:ioctl(add/insert rule): no data provided with filter rule [root@ipfilter-test /usr/obj]# echo "pass in quick reply-to tun1:10.1.2.1 on tun1 proto tcp from any to 10.1.2.11 port = 22 flags S/FSRPAU keep state" | ipf -f - 8:1:ioctl(add/insert rule): no data provided with filter rule [root@ipfilter-test /usr/obj]# echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - 8:1:ioctl(add/insert rule): no data provided with filter rule [root@ipfilter-test /usr/obj]# ipfstat -Rion # empty list for ipfilter(out) # empty list for ipfilter(in) Kernel version is 13.0-CURRENT r350103. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 Cy Schubert changed: What|Removed |Added Summary|ipfilter: fix unremovable |ipfilter: failure to detect |rules and rules checksum|the same rules when |for comparison |arguments ordered ||differently -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #25 from Cy Schubert --- Rearranging input arguments breaks checksum. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re[2]: Issues with TCP Timestamps allocation
Thanks for following through and making the patch! Kudos!
17 July 2019, 21:23:33, by "Michael Tuexen" :
> > On 17. Jul 2019, at 09:42, Vitalij Satanivskij wrote:
> >
> >
> >
> > Hello.
> >
> > Is there any changes about this problem
> Please find a patch in https://reviews.freebsd.org/D20980
>
> If possible, please test and report.
>
> Best regards
> Michael
> >
> >
> > I'm using FreeBSD 12 on my desktop and can confirm problem occur with some
> > hosts.
> >
> >
> >
> > Michael Tuexen wrote:
> > MT>
> > MT>
> > MT> > On 9. Jul 2019, at 14:58, Paul wrote:
> > MT> >
> > MT> > Hi Michael,
> > MT> >
> > MT> > 9 July 2019, 15:34:29, by "Michael Tuexen" :
> > MT> >
> > MT> >>
> > MT> >>
> > MT> >>> On 8. Jul 2019, at 17:22, Paul wrote:
> > MT> >>>
> > MT> >>>
> > MT> >>>
> > MT> >>> 8 July 2019, 17:12:21, by "Michael Tuexen" :
> > MT> >>>
> > MT> > On 8. Jul 2019, at 15:24, Paul wrote:
> > MT> >
> > MT> > Hi Michael,
> > MT> >
> > MT> > 8 July 2019, 15:53:15, by "Michael Tuexen" :
> > MT> >
> > MT> >>> On 8. Jul 2019, at 12:37, Paul wrote:
> > MT> >>>
> > MT> >>> Hi team,
> > MT> >>>
> > MT> >>> Recently we had an upgrade to 12 Stable. Immediately after, we
> > have started
> > MT> >>> seeing some strange connection establishment timeouts to some
> > fixed number
> > MT> >>> of external (world) hosts. The issue was persistent and easy to
> > reproduce.
> > MT> >>> Thanks to a patience and dedication of our system engineer we
> > have tracked
> > MT> >>> this issue down to a specific commit:
> > MT> >>>
> > MT> >>> https://svnweb.freebsd.org/base?view=revision=338053
> > MT> >>>
> > MT> >>> This patch was also back-ported into 11 Stable:
> > MT> >>>
> > MT> >>> https://svnweb.freebsd.org/base?view=revision=348435
> > MT> >>>
> > MT> >>> Among other things this patch changes the timestamp allocation
> > strategy,
> > MT> >>> by introducing a deterministic randomness via a hash function
> > that takes
> > MT> >>> into account a random key as well as source address, source
> > port, dest
> > MT> >>> address and dest port. As the result, timestamp offsets of
> > different
> > MT> >>> tuples (SA,SP,DA,DP) will be wildly different and will jump
> > from small
> > MT> >>> to large numbers and back, as long as something in the tuple
> > changes.
> > MT> >> Hi Paul,
> > MT> >>
> > MT> >> this is correct.
> > MT> >>
> > MT> >> Please note that the same happens with the old method, if two
> > hosts with
> > MT> >> different uptimes are bind a consumer grade NAT.
> > MT> >
> > MT> > If NAT does not replace timestamps then yes, it should be the
> > case.
> > MT> >
> > MT> >>>
> > MT> >>> After performing various tests of hosts that produce the above
> > mentioned
> > MT> >>> issue we came to conclusion that there are some interesting
> > implementations
> > MT> >>> that drop SYN packets with timestamps smaller than the largest
> > timestamp
> > MT> >>> value from streams of all recent or current connections from a
> > specific
> > MT> >>> address. This looks as some kind of SYN flood protection.
> > MT> >> This also breaks multiple hosts with different uptimes behind a
> > consumer
> > MT> >> level NAT talking to such a server.
> > MT> >>>
> > MT> >>> To ensure that each external host is not going to see a wild
> > jumps of
> > MT> >>> timestamp values I propose a patch that removes ports from the
> > equation
> > MT> >>> all together, when calculating the timestamp offset:
> > MT> >>>
> > MT> >>> Index: sys/netinet/tcp_subr.c
> > MT> >>>
> > ===
> > MT> >>> --- sys/netinet/tcp_subr.c (revision 348435)
> > MT> >>> +++ sys/netinet/tcp_subr.c (working copy)
> > MT> >>> @@ -2224,7 +2224,22 @@
> > MT> >>> uint32_t
> > MT> >>> tcp_new_ts_offset(struct in_conninfo *inc)
> > MT> >>> {
> > MT> >>> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> > MT> >>> +/*
> > MT> >>> + * Some implementations show a strange behaviour when
> > a wildly random
> > MT> >>> + * timestamps allocated for different streams. It
> > seems that only the
> > MT> >>> + * SYN packets are affected. Observed implementations
> > drop SYN packets
> > MT> >>> + * with timestamps smaller than the largest timestamp
> > value of all
> > MT> >>> + * recent or current connections from specific a
> > address. To mitigate
> > MT> >>> + * this we are going to ensure that each host will
> > always observe
> > MT> >>> + * timestamps as increasing no matter the stream: by
> > dropping ports
> > MT> >>> + * from the equation.
> > MT> >>> + */
> > MT>
Re: Issues with TCP Timestamps allocation
> On 18. Jul 2019, at 09:35, Vitalij Satanivskij wrote:
>
>
> Yep. Patch work.
Thanks for testing and reporting.
Best regards
Michael
>
>
> Michael Tuexen wrote:
> MT> > On 17. Jul 2019, at 09:42, Vitalij Satanivskij wrote:
> MT> >
> MT> >
> MT> >
> MT> > Hello.
> MT> >
> MT> > Is there any changes about this problem
> MT> Please find a patch in https://reviews.freebsd.org/D20980
> MT>
> MT> If possible, please test and report.
> MT>
> MT> Best regards
> MT> Michael
> MT> >
> MT> >
> MT> > I'm using FreeBSD 12 on my desktop and can confirm problem occur with
> some hosts.
> MT> >
> MT> >
> MT> >
> MT> > Michael Tuexen wrote:
> MT> > MT>
> MT> > MT>
> MT> > MT> > On 9. Jul 2019, at 14:58, Paul wrote:
> MT> > MT> >
> MT> > MT> > Hi Michael,
> MT> > MT> >
> MT> > MT> > 9 July 2019, 15:34:29, by "Michael Tuexen" :
> MT> > MT> >
> MT> > MT> >>
> MT> > MT> >>
> MT> > MT> >>> On 8. Jul 2019, at 17:22, Paul wrote:
> MT> > MT> >>>
> MT> > MT> >>>
> MT> > MT> >>>
> MT> > MT> >>> 8 July 2019, 17:12:21, by "Michael Tuexen" :
> MT> > MT> >>>
> MT> > MT> > On 8. Jul 2019, at 15:24, Paul wrote:
> MT> > MT> >
> MT> > MT> > Hi Michael,
> MT> > MT> >
> MT> > MT> > 8 July 2019, 15:53:15, by "Michael Tuexen"
> :
> MT> > MT> >
> MT> > MT> >>> On 8. Jul 2019, at 12:37, Paul wrote:
> MT> > MT> >>>
> MT> > MT> >>> Hi team,
> MT> > MT> >>>
> MT> > MT> >>> Recently we had an upgrade to 12 Stable. Immediately after,
> we have started
> MT> > MT> >>> seeing some strange connection establishment timeouts to
> some fixed number
> MT> > MT> >>> of external (world) hosts. The issue was persistent and
> easy to reproduce.
> MT> > MT> >>> Thanks to a patience and dedication of our system engineer
> we have tracked
> MT> > MT> >>> this issue down to a specific commit:
> MT> > MT> >>>
> MT> > MT> >>>
> https://svnweb.freebsd.org/base?view=revision=338053
> MT> > MT> >>>
> MT> > MT> >>> This patch was also back-ported into 11 Stable:
> MT> > MT> >>>
> MT> > MT> >>>
> https://svnweb.freebsd.org/base?view=revision=348435
> MT> > MT> >>>
> MT> > MT> >>> Among other things this patch changes the timestamp
> allocation strategy,
> MT> > MT> >>> by introducing a deterministic randomness via a hash
> function that takes
> MT> > MT> >>> into account a random key as well as source address, source
> port, dest
> MT> > MT> >>> address and dest port. As the result, timestamp offsets of
> different
> MT> > MT> >>> tuples (SA,SP,DA,DP) will be wildly different and will jump
> from small
> MT> > MT> >>> to large numbers and back, as long as something in the
> tuple changes.
> MT> > MT> >> Hi Paul,
> MT> > MT> >>
> MT> > MT> >> this is correct.
> MT> > MT> >>
> MT> > MT> >> Please note that the same happens with the old method, if
> two hosts with
> MT> > MT> >> different uptimes are bind a consumer grade NAT.
> MT> > MT> >
> MT> > MT> > If NAT does not replace timestamps then yes, it should be the
> case.
> MT> > MT> >
> MT> > MT> >>>
> MT> > MT> >>> After performing various tests of hosts that produce the
> above mentioned
> MT> > MT> >>> issue we came to conclusion that there are some interesting
> implementations
> MT> > MT> >>> that drop SYN packets with timestamps smaller than the
> largest timestamp
> MT> > MT> >>> value from streams of all recent or current connections
> from a specific
> MT> > MT> >>> address. This looks as some kind of SYN flood protection.
> MT> > MT> >> This also breaks multiple hosts with different uptimes
> behind a consumer
> MT> > MT> >> level NAT talking to such a server.
> MT> > MT> >>>
> MT> > MT> >>> To ensure that each external host is not going to see a
> wild jumps of
> MT> > MT> >>> timestamp values I propose a patch that removes ports from
> the equation
> MT> > MT> >>> all together, when calculating the timestamp offset:
> MT> > MT> >>>
> MT> > MT> >>> Index: sys/netinet/tcp_subr.c
> MT> > MT> >>>
> ===
> MT> > MT> >>> --- sys/netinet/tcp_subr.c (revision 348435)
> MT> > MT> >>> +++ sys/netinet/tcp_subr.c (working copy)
> MT> > MT> >>> @@ -2224,7 +2224,22 @@
> MT> > MT> >>> uint32_t
> MT> > MT> >>> tcp_new_ts_offset(struct in_conninfo *inc)
> MT> > MT> >>> {
> MT> > MT> >>> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> MT> > MT> >>> +/*
> MT> > MT> >>> + * Some implementations show a strange behaviour
> when a wildly random
> MT> > MT> >>> + * timestamps allocated for different streams. It
> seems that only the
> MT> > MT> >>> + * SYN packets are affected. Observed
> implementations drop SYN packets
> MT> > MT> >>> + * with timestamps smaller than the largest
>
Re: Issues with TCP Timestamps allocation
Yep. Patch work.
Michael Tuexen wrote:
MT> > On 17. Jul 2019, at 09:42, Vitalij Satanivskij wrote:
MT> >
MT> >
MT> >
MT> > Hello.
MT> >
MT> > Is there any changes about this problem
MT> Please find a patch in https://reviews.freebsd.org/D20980
MT>
MT> If possible, please test and report.
MT>
MT> Best regards
MT> Michael
MT> >
MT> >
MT> > I'm using FreeBSD 12 on my desktop and can confirm problem occur with
some hosts.
MT> >
MT> >
MT> >
MT> > Michael Tuexen wrote:
MT> > MT>
MT> > MT>
MT> > MT> > On 9. Jul 2019, at 14:58, Paul wrote:
MT> > MT> >
MT> > MT> > Hi Michael,
MT> > MT> >
MT> > MT> > 9 July 2019, 15:34:29, by "Michael Tuexen" :
MT> > MT> >
MT> > MT> >>
MT> > MT> >>
MT> > MT> >>> On 8. Jul 2019, at 17:22, Paul wrote:
MT> > MT> >>>
MT> > MT> >>>
MT> > MT> >>>
MT> > MT> >>> 8 July 2019, 17:12:21, by "Michael Tuexen" :
MT> > MT> >>>
MT> > MT> > On 8. Jul 2019, at 15:24, Paul wrote:
MT> > MT> >
MT> > MT> > Hi Michael,
MT> > MT> >
MT> > MT> > 8 July 2019, 15:53:15, by "Michael Tuexen" :
MT> > MT> >
MT> > MT> >>> On 8. Jul 2019, at 12:37, Paul wrote:
MT> > MT> >>>
MT> > MT> >>> Hi team,
MT> > MT> >>>
MT> > MT> >>> Recently we had an upgrade to 12 Stable. Immediately after,
we have started
MT> > MT> >>> seeing some strange connection establishment timeouts to some
fixed number
MT> > MT> >>> of external (world) hosts. The issue was persistent and easy
to reproduce.
MT> > MT> >>> Thanks to a patience and dedication of our system engineer we
have tracked
MT> > MT> >>> this issue down to a specific commit:
MT> > MT> >>>
MT> > MT> >>> https://svnweb.freebsd.org/base?view=revision=338053
MT> > MT> >>>
MT> > MT> >>> This patch was also back-ported into 11 Stable:
MT> > MT> >>>
MT> > MT> >>> https://svnweb.freebsd.org/base?view=revision=348435
MT> > MT> >>>
MT> > MT> >>> Among other things this patch changes the timestamp
allocation strategy,
MT> > MT> >>> by introducing a deterministic randomness via a hash function
that takes
MT> > MT> >>> into account a random key as well as source address, source
port, dest
MT> > MT> >>> address and dest port. As the result, timestamp offsets of
different
MT> > MT> >>> tuples (SA,SP,DA,DP) will be wildly different and will jump
from small
MT> > MT> >>> to large numbers and back, as long as something in the tuple
changes.
MT> > MT> >> Hi Paul,
MT> > MT> >>
MT> > MT> >> this is correct.
MT> > MT> >>
MT> > MT> >> Please note that the same happens with the old method, if two
hosts with
MT> > MT> >> different uptimes are bind a consumer grade NAT.
MT> > MT> >
MT> > MT> > If NAT does not replace timestamps then yes, it should be the
case.
MT> > MT> >
MT> > MT> >>>
MT> > MT> >>> After performing various tests of hosts that produce the
above mentioned
MT> > MT> >>> issue we came to conclusion that there are some interesting
implementations
MT> > MT> >>> that drop SYN packets with timestamps smaller than the
largest timestamp
MT> > MT> >>> value from streams of all recent or current connections from
a specific
MT> > MT> >>> address. This looks as some kind of SYN flood protection.
MT> > MT> >> This also breaks multiple hosts with different uptimes behind
a consumer
MT> > MT> >> level NAT talking to such a server.
MT> > MT> >>>
MT> > MT> >>> To ensure that each external host is not going to see a wild
jumps of
MT> > MT> >>> timestamp values I propose a patch that removes ports from
the equation
MT> > MT> >>> all together, when calculating the timestamp offset:
MT> > MT> >>>
MT> > MT> >>> Index: sys/netinet/tcp_subr.c
MT> > MT> >>>
===
MT> > MT> >>> --- sys/netinet/tcp_subr.c(revision 348435)
MT> > MT> >>> +++ sys/netinet/tcp_subr.c(working copy)
MT> > MT> >>> @@ -2224,7 +2224,22 @@
MT> > MT> >>> uint32_t
MT> > MT> >>> tcp_new_ts_offset(struct in_conninfo *inc)
MT> > MT> >>> {
MT> > MT> >>> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
MT> > MT> >>> +/*
MT> > MT> >>> + * Some implementations show a strange behaviour
when a wildly random
MT> > MT> >>> + * timestamps allocated for different streams. It
seems that only the
MT> > MT> >>> + * SYN packets are affected. Observed
implementations drop SYN packets
MT> > MT> >>> + * with timestamps smaller than the largest
timestamp value of all
MT> > MT> >>> + * recent or current connections from specific a
address. To mitigate
MT> > MT> >>> + * this we are going to ensure that each host will
always observe
MT> > MT> >>> + * timestamps as increasing no matter the stream: by
dropping ports
MT> > MT> >>> + * from the equation.
MT> > MT>
