[Bug 212384] pfsync(4) bulk update fail

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212384 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

Problem reports for freebsd-pf@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 --- Comment #14 from Olivier Cochard --- Patch proposed here: https://reviews.freebsd.org/D7780 -- You are receiving this mail because: You are the assignee for the bug.

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 --- Comment #13 from Olivier Cochard --- funny, after lot's of printf() for debuging, it seems it's the first suspicious function that was source of the panic that is corrupting my mbuf/packet: in bridge_fragment():

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 --- Comment #12 from Olivier Cochard --- I've added some lines like: if_printf(ifp,"[DEBUG] bridge_fragment() exiting, m_len: %d\n",m->m_len); in the sys/net/if_bridge.c code. Now, here is the behavior with

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 --- Comment #11 from Olivier Cochard --- I've generated a core dump (with a DEBUG kernel) and looked into it: Unread portion of the kernel message buffer: panic: vtnet_txq_encap: no mbuf packet

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 --- Comment #10 from Olivier Cochard --- I've rebuild a kernel with all DEBUG enabled. And generating only first one fragmented ICMP (ping -c 1 -s 1500 10.0.0.3) generate this kassert panic: [root@router]~# panic:

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 --- Comment #8 from Olivier Cochard --- Created attachment 174241 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=174241=edit pcaps file I've added as attachment these 2 tcpdump files (done on real

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 --- Comment #7 from Olivier Cochard --- Created attachment 174240 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=174240=edit wireshark analysis Here is my wireshark analysis between a trace with scrub and a

[Bug 207080] pfctl crash when load pf.conf, libc/resolv problem ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207080 --- Comment #12 from fabrice.br...@orange.com --- Created attachment 174193 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=174193=edit Truss output with a burning pfctl in background -- You are receiving this mail because: You

[Bug 207080] pfctl crash when load pf.conf, libc/resolv problem ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207080 --- Comment #11 from fabrice.br...@orange.com --- Hello, Ok, if I run truss pfctl.conf.anon, the output seems to be normal for me newbie level. Si in a first time, I run a script that call a lot of pfctl and I have a pfctl that burn cpu.

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 --- Comment #6 from Olivier Cochard --- I've generated a core dump and start kgdb on it: There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 Olivier Cochard changed: What|Removed |Added CC|

[Bug 207080] pfctl crash when load pf.conf, libc/resolv problem ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207080 --- Comment #10 from Kristof Provost --- Valgrind is not really producing anything useful here. It's be interesting to see what pfctl is doing when it gets stuck using a lot of CPU time. Did truss show anything

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 --- Comment #4 from Kristof Provost --- (In reply to Jerome Toutee from comment #3) Hi Jerome, I'm not able to reproduce this on CURRENT. Can you confirm that you can still reproduce it there? -- You are receiving this

[Bug 212115] kldunload pf causes panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212115 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

[Bug 207080] pfctl crash when load pf.conf, libc/resolv problem ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207080 fabrice.br...@orange.com changed: What|Removed |Added Attachment #174090|0 |1 is obsolete|

[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633 Jerome Toutee changed: What|Removed |Added CC|

[Bug 207080] pfctl crash when load pf.conf, libc/resolv problem ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207080 --- Comment #8 from fabrice.br...@orange.com --- Sorry, I've forgot DEBUG_FLAGS, the new valgrind ouputin a few minutes ! -- You are receiving this mail because: You are the assignee for the bug.

[Bug 207080] pfctl crash when load pf.conf, libc/resolv problem ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207080 fabrice.br...@orange.com changed: What|Removed |Added CC||fabrice.br...@orange.com

[Bug 207080] pfctl crash when load pf.conf, libc/resolv problem ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207080 fabrice.br...@orange.com changed: What|Removed |Added Version|9.3-STABLE |10.3-STABLE --- Comment

[Bug 203735] Transparent interception of ipv6 with squid and pf causes panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203735 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable10?,

[Bug 203735] Transparent interception of ipv6 with squid and pf causes panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203735 Bjoern A. Zeeb changed: What|Removed |Added Depends on|212105 | Referenced

[Bug 203735] Transparent interception of ipv6 with squid and pf causes panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203735 Bjoern A. Zeeb changed: What|Removed |Added Depends on||212105

[Bug 203735] Transparent interception of ipv6 with squid and pf causes panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203735 Andrey V. Elsukov changed: What|Removed |Added CC|

[Bug 203735] Transparent interception of ipv6 with squid and pf causes panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203735 Kurt Jaeger changed: What|Removed |Added Status|New |Closed

[Bug 211796] missing htonl calls in pf range check

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211796 --- Comment #4 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Fri Aug 19 11:36:00 UTC 2016 New revision: 304463 URL: https://svnweb.freebsd.org/changeset/base/304463 Log: MFC r304152: pf: Add missing

[Bug 211796] missing htonl calls in pf range check

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211796 --- Comment #3 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Fri Aug 19 11:31:30 UTC 2016 New revision: 304462 URL: https://svnweb.freebsd.org/changeset/base/304462 Log: MFC r304152: pf: Add missing

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #39 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Wed Aug 17 09:24:46 UTC 2016 New revision: 304283 URL: https://svnweb.freebsd.org/changeset/base/304283 Log: MFC r302497: pf: Map hook

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #38 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Wed Aug 17 09:23:41 UTC 2016 New revision: 304282 URL: https://svnweb.freebsd.org/changeset/base/304282 Log: MFC r302497: pf: Map hook

[Bug 211796] missing htonl calls in pf range check

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211796 --- Comment #2 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Mon Aug 15 12:13:14 UTC 2016 New revision: 304152 URL: https://svnweb.freebsd.org/changeset/base/304152 Log: pf: Add missing byte-order swap

[Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475 --- Comment #6 from fehmi noyan isi --- Hi, Somehow, I missed the notification for the latest comment! Sorry for the late reply It is possible to add a log warning message by using printf(9) or log(9), but I have

[Bug 211796] missing htonl calls in pf range check

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211796 Mark Linimon changed: What|Removed |Added CC|

[Bug 211796] missing htonl calls in pf range check

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211796 Mahdi Mokhtari changed: What|Removed |Added CC|

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 --- Comment #11 from Mahdi Mokhtari --- (In reply to rk from comment #10) Hi. Thanks for feedback on this patch. > Interessant thing: The result you saw makes sense, cause (as kristof pointed too) I have to change some

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 --- Comment #10 from r...@starnet.cz --- (In reply to Mahdi Mokhtari from comment #2) Hello Mahdi, I have recompiled kernel, but still the same: in pf.conf: altq on em0 cbq bandwidth 10Gb queue { default_nat,. queue default_nat

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 Mark Linimon changed: What|Removed |Added Keywords||patch

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 --- Comment #9 from Kristof Provost --- That's a good question. I'd have to find a decent example somewhere myself. The ioctl codes actually encode the size of the struct, so perhaps there's an alternate approach. A

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 --- Comment #8 from Mahdi Mokhtari --- (In reply to Mahdi Mokhtari from comment #7) Also, What about structs? Should we use Macros around/inside them of old/new versions? Or we should redefine new structs too ? -- You

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 --- Comment #7 from Mahdi Mokhtari --- (In reply to Kristof Provost from comment #6) Aha :) I see. So you suggest we solve it by adding new IOCTL command. Okay, lemme do a try. When i did it, I'll upload a patch for

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 --- Comment #6 from Kristof Provost --- (In reply to Mahdi Mokhtari from comment #4) The problem with the ABI is that we can't rely on user space and kernel space running the same code versions. If someone were to update

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 --- Comment #5 from r...@starnet.cz --- (In reply to Mahdi Mokhtari from comment #4) Hello, I have hardware but its production box - so when you say that you have working patch, I can test it. Radek -- You are receiving this mail

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 --- Comment #4 from Mahdi Mokhtari --- (In reply to Kristof Provost from comment #3) Ah, yes i see most of pf_altq.h is int32. And i guess we should change it too. About your point on kernel ABI and ioctl(), i didn't

[Bug 211730] pf uses 32bit value for bandwith with altq

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730 Kristof Provost changed: What|Removed |Added CC|

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 Kristof Provost changed: What|Removed |Added Version|9.3-RELEASE |10.3-STABLE

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 Franco Fichtner changed: What|Removed |Added CC|

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 --- Comment #14 from Kristof Provost --- (In reply to Vladislav V. Prodan from comment #13) I've been talking to clbuis...@orange.fr in private, and it looks like there is indeed something wrong in 10.3, but not in 11 or

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 Vladislav V. Prodan changed: What|Removed |Added CC|

[Bug 210924] 10.3-STABLE - PF - possible regression in pf.conf set timeout interval

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210924 --- Comment #9 from commit-h...@freebsd.org --- A commit references this bug: Author: loos Date: Tue Aug 9 03:47:38 UTC 2016 New revision: 303865 URL: https://svnweb.freebsd.org/changeset/base/303865 Log: MFC r303760: Fix a

[Bug 210924] 10.3-STABLE - PF - possible regression in pf.conf set timeout interval

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210924 Oliver Peter changed: What|Removed |Added Resolution|--- |FIXED

[Bug 208140] panic: page fault in pf

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208140 Mark Linimon changed: What|Removed |Added Keywords||patch

[Bug 210924] 10.3-STABLE - PF - possible regression in pf.conf set timeout interval

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210924 --- Comment #6 from commit-h...@freebsd.org --- A commit references this bug: Author: loos Date: Fri Aug 5 02:19:03 UTC 2016 New revision: 303760 URL: https://svnweb.freebsd.org/changeset/base/303760 Log: Fix a regression in pf.conf

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 --- Comment #12 from Kristof Provost --- (In reply to clbuisson from comment #11) I'm unable to reproduce the described behaviour on my system. Please make a network capture so we can look in detail at what's going wrong.

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 --- Comment #11 from clbuis...@orange.fr --- There is nothing complicated in my setup ! 1. An Internal network with "private" IPv4 addresses 2. A Gateway/Router/Firewall connected to this internal network, and to the Internet (ADSL), and

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 --- Comment #10 from Kristof Provost --- (In reply to clbuisson from comment #9) I'm afraid I don't understand what the problem is. Can you add a description of your network setup, the trace route output and a network

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 clbuis...@orange.fr changed: What|Removed |Added CC||clbuis...@orange.fr ---

[Bug 210924] 10.3-STABLE - PF - possible regression in pf.conf set timeout interval

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210924 --- Comment #5 from Kristof Provost --- Unfortunately the patch to add CODEL doesn't seem to have included any documentation changes. I'm not familiar with it myself. -- You are receiving this mail because: You are the

[Bug 210924] 10.3-STABLE - PF - possible regression in pf.conf set timeout interval

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210924 --- Comment #4 from Oliver Peter --- (In reply to Kristof Provost from comment #3) Thanks, of course this is the better approach. Looks good so far for me: oliver@wayne pfctl % cat /etc/pf.conf set timeout interval 5

[Bug 210924] 10.3-STABLE - PF - possible regression in pf.conf set timeout interval

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210924 --- Comment #3 from Kristof Provost --- It's probably a little too late to get away with changing the altq keywords. This has hit 10.3 (and soon 11.0). It should be possible to teach pfctl that both 'set timeout interval

[Bug 210860] [pf] [ip6] Incorrect TCP checksums after rdr

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210860 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

[Bug 210924] 10.3-STABLE - PF - possible regression in pf.conf set timeout interval

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210924 Mark Linimon changed: What|Removed |Added Keywords||patch,

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 Kristof Provost changed: What|Removed |Added Resolution|--- |FIXED

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #37 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Sat Jul 9 12:17:01 UTC 2016 New revision: 302497 URL: https://svnweb.freebsd.org/changeset/base/302497 Log: pf: Map hook returns onto the

[Bug 204248] PF Does not work nat in FreeBSD 10.2

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204248 Kristof Provost changed: What|Removed |Added Resolution|--- |FIXED

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #36 from Kristof Provost --- (In reply to Max from comment #35) Yeah, we may want to clarify the man page somewhat, and explicitly state that there are no ICMP error messages for ICMP packets. -- You are

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #35 from Max --- (In reply to Kristof Provost from comment #33) Now I see that... } else if (pd->proto != IPPROTO_ICMP && af == AF_INET && r->return_icmp)

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #34 from Max --- (In reply to Kristof Provost from comment #33) Yeah, that's my fault... It is ICMP. But man pf.conf says return This causes a TCP RST to be returned for tcp(4) packets and

[Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475 --- Comment #4 from fehmi noyan isi --- Hi, In this forum post [1] from David, there is a bit of discussion about this PR (apart from the original question). Would checking the requested amount of memory by malloc(9)

[Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475 --- Comment #3 from fehmi noyan isi --- Created attachment 170810 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=170810=edit Patch for the proposed fix. Patch file is created with $ diff -u pf.c pf.c.fni >

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #28 from Max --- (In reply to Kristof Provost from comment #27) Hello, Kristof. Thank you for your reply. I understand the logic of current implementation of pf_reassemble(). But it does not return a value

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #27 from Kristof Provost --- (In reply to Max from comment #26) I think what we need to do is very carefully go through all the return paths in pf. There's basically three scenarios: * Accept packet

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #26 from Max --- Does it look reasonable? We should use consistent return values in pf_reassemble(), I think. --- pf_norm.c.orig 2016-05-28 23:40:52.171196000 +0300 +++ pf_norm.c 2016-05-28

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #25 from Max --- (In reply to Kristof Provost from comment #24) That's why I've reviewed ip_input.c and ip_output.c. It's not just a routing issue... Can you discuss this problem with responsible

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #24 from Kristof Provost --- (In reply to Max from comment #23) Yeah, that's certainly a valid point. Arguably the network stack shouldn't send errors if the firewall drops a packet, instead leaving it to the

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #23 from Max --- (In reply to Kristof Provost from comment #22) I agree. But should we send any ICMP if we have "block drop ..." rule, not "block return ..."? -- You are receiving this mail because: You

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #22 from Kristof Provost --- (In reply to Max from comment #21) Yeah, I guess that makes sense. After all, the rules tell PF to drop the ICMP packet, which it does. It tells the network stack that the packet

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #21 from Max --- (In reply to Kristof Provost from comment #20) Hello, Kristof. This patch works. But there is another problem: pass log (all) all block drop out log (all) on gre1 proto icmp In this case

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #20 from Kristof Provost --- Created attachment 170747 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=170747=edit pf_frag_pass patch (In reply to Max from comment #19) You may be on to something

[Bug 205743] null pointer dereference in PF running a vimage jail

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205743 Bjoern A. Zeeb changed: What|Removed |Added Status|New |Open

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #19 from Max --- I've never read FreeBSD sources, except pf's last week... probably I'm wrong. ip_input()->ip_forward()->ip_output()->ip_output_pfil()->pfil_run_hooks()->pf_test(). If ip_output() returns

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #18 from Max --- no scrub on gre1 proto icmp scrub on gre1 There is no "host unreachable". 14:58:34.741461 rule 0..16777216/0(match): pass in on em0: 192.168.10.1 > 192.168.10.254: GREv0, proto IPv4

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #17 from Max --- (In reply to Kristof Provost from comment #16) Absolutely. ICMP-unreach generated when the first fragment of echo request is dropped by pf, I think. -- You are receiving this mail

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #16 from Kristof Provost --- So if I understand this correctly the problem is still there with only 'scrub on gre1' (so without the MSS clamping), but it's not there if scrubbing is done on both interfaces?

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #15 from Max --- scrub on gre0 scrub on gre1 14:39:39.127649 rule 0..16777216/0(match): pass in on em0: 192.168.10.1 > 192.168.10.254: GREv0, proto IPv4 (0x0800), length 1480: 10.10.1.1 > 10.10.3.1: ICMP

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #14 from Max --- scrub on gre1 14:35:43.641169 rule 0..16777216/0(match): pass in on em0: 192.168.10.1 > 192.168.10.254: GREv0, proto IPv4 (0x0800), length 1480: 10.10.1.1 > 10.10.3.1: ICMP echo request,

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #13 from Kristof Provost --- I'm wondering if the 'max-mss' thing isn't a red herring. Can you try 'scrub on gre0', 'scrub on gre1' (so without the max-mss)? -- You are receiving this mail because: You are

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #12 from Max --- And the last one... I'm sorry for these listings... scrub on gre0 max-mss 1360 scrub on gre1 max-mss 1360 (there is no "host unreachable") 22:22:56.728057 rule 0..16777216/0(match): pass

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #10 from Max --- scrub on gre1 proto tcp max-mss 1360 (there is no "host unreachable" message). 21:28:54.220629 rule 0..16777216/0(match): pass in on em0: 192.168.10.1 > 192.168.10.254: GREv0, proto IPv4

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #9 from Max --- pflog output: 21:20:52.521232 rule 0..16777216/0(match): pass in on em0: 192.168.10.1 > 192.168.10.254: GREv0, proto IPv4 (0x0800), length 1480: 10.10.1.1 > 10.10.3.1: ICMP echo request, id

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #8 from Max --- (In reply to emz from comment #7) fragment reassemble Using scrub rules, fragments can be reassembled by normalization. In this case, fragments are buffered until they

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #7 from e...@norma.perm.ru --- I confirm, adding "in" on scrubbing for TCP MSS fixes the issue. Although the relation between TCP MSS fixing and the ICMP still seems bogus to me. -- You are receiving this mail because: You are

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #6 from Max --- Created attachment 170591 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=170591=edit dumps (In reply to Kristof Provost from comment #5) Host "A" config:

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #5 from Kristof Provost --- (In reply to Max from comment #3) Scrubbing in both directions should be safe, even with fragment reassemble. In IPv4 it's OK for a frame to not fit in the MTU. The router will

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 --- Comment #4 from Max --- It seems that scrubbing on both tunnels eliminates the problem. scrub on gre0 max-mss 1360 scrub on gre1 max-mss 1360 -- You are receiving this mail because: You are the assignee for the

[Bug 207598] pf adds icmp unreach on gre/ipsec somehow

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207598 Max changed: What|Removed |Added CC||maxi...@als.nnov.ru

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 --- Comment #7 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Mon May 23 13:59:49 UTC 2016 New revision: 300508 URL: https://svnweb.freebsd.org/changeset/base/300508 Log: pf: Fix more ICMP mistranslation

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 --- Comment #6 from Max --- (In reply to Kristof Provost from comment #5) https://svnweb.freebsd.org/base/head/sys/netpfil/pf/pf.c?annotate=300501=300501#l5017 should be "pf_change_icmp(pd2.dst, NULL, saddr,", not

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 Kristof Provost changed: What|Removed |Added CC|

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 --- Comment #4 from commit-h...@freebsd.org --- A commit references this bug: Author: kp Date: Mon May 23 12:41:29 UTC 2016 New revision: 300501 URL: https://svnweb.freebsd.org/changeset/base/300501 Log: pf: Fix ICMP translation Fix

[Bug 201519] pf NAT translates ICMP type 3 packects incorrectly

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519 Max changed: What|Removed |Added CC||maxi...@als.nnov.ru

<    2   3   4   5   6   7   8   9   >