Possible Bug in PF with round robin sticky address

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible Bug in PF with round robin sticky address

Arjan Schrijver
Hello OpenBSD bugs list,

I'm having big problems getting my
firewall to work. I'm on OpenBSD 5.2 (amd64) and have the exact problem
described
here:
http://openbsd.7691.n7.nabble.com/Possible-Bug-in-PF-with-round-robin-sticky-address-td184731.html


Now I can't find anything online about a possible solution or
workaround for this bug, or even a confirmation message from the OpenBSD
team.
Can anyone please tell me if this is really a bug, or just a user
error?

Kind regards,

Arjan Schrijver

Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in PF with round robin sticky address

Mike Belopuhov-5
On Wed, Nov 21, 2012 at 3:42 PM, Arjan Schrijver <[hidden email]> wrote:

> Hello OpenBSD bugs list,
>
> I'm having big problems getting my
> firewall to work. I'm on OpenBSD 5.2 (amd64) and have the exact problem
> described
> here:
> http://openbsd.7691.n7.nabble.com/Possible-Bug-in-PF-with-round-robin-sticky-address-td184731.html
>
>
> Now I can't find anything online about a possible solution or
> workaround for this bug, or even a confirmation message from the OpenBSD
> team.
> Can anyone please tell me if this is really a bug, or just a user
> error?
>
> Kind regards,
>
> Arjan Schrijver
>

Can you provide a trace from current?

Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in PF with round robin sticky address

Arjan Schrijver
Mike Belopuhov schreef op 2012-11-21 17:49:

> On Wed, Nov 21, 2012
at 3:42 PM, Arjan Schrijver <[hidden email]> wrote:
>
>> Hello
OpenBSD bugs list, I'm having big problems getting my firewall to work.
I'm on OpenBSD 5.2 (amd64) and have the exact problem described here:
http://openbsd.7691.n7.nabble.com/Possible-Bug-in-PF-with-round-robin-sticky-address-td184731.html
[1] Now I can't find anything online about a possible solution or
workaround for this bug, or even a confirmation message from the OpenBSD
team. Can anyone please tell me if this is really a bug, or just a user
error? Kind regards, Arjan Schrijver
>
> Can you provide a trace from
current?

Hello, thank you for the quick answer!
Sadly, I'm unable to
request a full trace. This is what I get on the display:


uvm_fault(0xfffffe832dd908c8, 0x0, 0, 1) -> e
kernel: page fault trap,
code=0
Stopped at pf_test_rule+0x16e3: movzbl 0xd(%rdx),%eax
ddb{2}>


But, I think because it's a USB keyboard, it's not possible to type
anything on the ddb prompt, so I'm not able to get a trace or registers
dump or core dump.

Maybe it helps if I give some information about
what I'm doing and what pf rule triggers the panic.
What I'm trying to
achieve needs the following PF rule (I faked the addresses for privacy):


pass in quick on tun0 proto tcp from 192.168.0.0/24 to !(tun0)
route-to { (em0 10.0.0.1), (em1 10.1.0.1) } round-robin sticky-address
flags S/SAFR modulate state

Even when simplifying the rule to the
following, the box still crashes at the first packet that matches the
rule:

pass in quick on tun0 proto tcp from 192.168.0.0/24 to !(tun0)
route-to (em0 10.0.0.1) round-robin sticky-address

As you can see,
this is a VPN box that has two different ISP's connected that I want to
use in a load-balanced way. Because it needs to function in a 'normal'
way, it's important to have sticky-address included in the rule. When I
remove sticky-address from the rule, it works fine.

Is there a way to
get a trace without working ddb prompt? Please tell me how to get the
required information for debugging, if at all possible.

Kind
regards,
Arjan

Links:
------
[1]
http://openbsd.7691.n7.nabble.com/Possible-Bug-in-PF-with-round-robin-sticky-address-td184731.html

Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in PF with round robin sticky address

Arjan Schrijver
Arjan Schrijver schreef op 2012-11-22 10:18:

> But, I think because it's a USB keyboard, it's not possible to type
> anything on the ddb prompt, so I'm not able to get a trace or
> registers
> dump or core dump.

Finally I've been able to get to the ddb prompt by using a serial
console. The output of several commands are below:

uvm_fault(0xfffffe832dd88a88, 0x20a000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at      pf_test_rule+0x16e3:    movzbl  0xd(%rdx),%eax
ddb{0}> trace
pf_test_rule() at pf_test_rule+0x16e3
end trace frame: 0x0, count: -1
ddb{0}> ps
    PID   PPID   PGRP    UID  S       FLAGS  WAIT          COMMAND
  26516  17630  26516      0  3        0x80  kqread        tail
  17630  12992  17630      0  3        0x80  wait          bash
  12992  20202  12992   1000  3        0x80  wait          bash
  20202  25635  25635   1000  3        0x80  select        sshd
  25635   5327  25635      0  3        0x80  poll          sshd
   9490  16229  16229     70  3        0x80  select        named
  16229      1  16229      0  3        0x80  netio         named
   2064      1   2064      0  3        0x80  poll          openvpn
*31763      1  31763      0  7           0                openvpn
  28633      1      1      0  3        0x80  ttyopn        getty
  17970      1  17970      0  3        0x80  ttyin         getty
  17096      1  17096      0  3        0x80  ttyin         getty
  22040      1  22040      0  3        0x80  ttyin         getty
   2709      1   2709      0  3        0x80  ttyin         getty
  22336      1  22336      0  3        0x80  ttyin         getty
  14023      1  14023      0  3        0x80  ttyin         getty
  14615      1  14615      0  3        0x80  select        cron
  12624      1  12624     99  3        0x80  poll          sndiod
  10189      1  10189      0  3        0x80  select        inetd
   5327      1   5327      0  3        0x80  select        sshd
   4770      1   4770      0  3        0x80  poll          ntpd
   4678  22626   4678     83  3        0x80  poll          ntpd
  22626      1  22626     83  3        0x80  poll          ntpd
    422  19131  19131     74  3        0x80  bpf           pflogd
  19131      1  19131      0  3        0x80  netio         pflogd
   9666  27059  27059     73  7        0x80                syslogd
  27059      1  27059      0  3        0x80  netio         syslogd
     20      0      0      0  3    0x100200  aiodoned      aiodoned
     19      0      0      0  3    0x100200  syncer        update
     18      0      0      0  3    0x100200  cleaner       cleaner
     17      0      0      0  3    0x100200  reaper        reaper
     16      0      0      0  3    0x100200  pgdaemon      pagedaemon
     15      0      0      0  3    0x100200  bored         crypto
     14      0      0      0  3    0x100200  pftm          pfpurge
     13      0      0      0  3    0x100200  usbtsk        usbtask
     12      0      0      0  3    0x100200  usbatsk       usbatsk
     11      0      0      0  3    0x100200  acpi0         acpi0
     10      0      0      0  7  0x40100200                idle7
      9      0      0      0  7  0x40100200                idle6
      8      0      0      0  7  0x40100200                idle5
      7      0      0      0  7  0x40100200                idle4
      6      0      0      0  7  0x40100200                idle3
      5      0      0      0  7  0x40100200                idle2
      4      0      0      0  3  0x40100200                idle1
      3      0      0      0  3    0x100200  bored         syswq
      2      0      0      0  3  0x40100200                idle0
      1      0      1      0  3        0x80  wait          init
      0     -1      0      0  3       0x200  scheduler     swapper
ddb{0}> show registers
ds                            0xe3b0    acpi_pdirpa+0x9fb8
es                            0xda07    acpi_pdirpa+0x960f
fs                            0x2790    mp_pdirpa+0x6a9
gs                            0x2860    mp_pdirpa+0x779
rdi               0xffffffff80d3bab8    tree_src_tracking
rsi               0xfffffe832d432000
rbp               0xfffffe832d432000
rbx               0xffff80002a242860
rdx                         0x20a018    acpi_pdirpa+0x205c20
rcx                                0
rax               0xffff800000403500
r8                                 0
r9                0xfffffe832d432000
r10                                0
r11               0xfffffe832d432000
r12               0xfffffe832d51e058
r13               0xffff80002a242970
r14               0xfffffe832ea445f8
r15               0xffff80002a242860
rip               0xffffffff80256333    pf_test_rule+0x16e3
cs                               0x8
rflags                       0x10246    acpi_pdirpa+0xbe4e
rsp               0xffff80002a2427a0
ss                              0x10
pf_test_rule+0x16e3:    movzbl  0xd(%rdx),%eax
ddb{0}>

Please let me know if there is any other information I can provide for
debugging this issue.

Thanks,
Arjan

Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in PF with round robin sticky address

Mike Belopuhov-5
On Thu, Nov 22, 2012 at 11:40 AM, Arjan Schrijver <[hidden email]> wrote:

> Arjan Schrijver schreef op 2012-11-22 10:18:
>
>
>> But, I think because it's a USB keyboard, it's not possible to type
>> anything on the ddb prompt, so I'm not able to get a trace or registers
>> dump or core dump.
>
>
> Finally I've been able to get to the ddb prompt by using a serial console.
> The output of several commands are below:
>
> uvm_fault(0xfffffe832dd88a88, 0x20a000, 0, 1) -> e
>
-----8<-----
> Please let me know if there is any other information I can provide for
> debugging this issue.
>

yes, please run "trace".

> Thanks,
> Arjan

Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in PF with round robin sticky address

Arjan Schrijver
Mike Belopuhov schreef op 2012-11-22 11:46:
> On Thu, Nov 22, 2012 at 11:40 AM, Arjan Schrijver <[hidden email]>
> wrote:
>> Please let me know if there is any other information I can provide
>> for
>> debugging this issue.
>>
>
> yes, please run "trace".


That was already in my last mail :)
But here it is again:

ddb{0}> trace
pf_test_rule() at pf_test_rule+0x16e3
end trace frame: 0x0, count: -1
ddb{0}>

Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in PF with round robin sticky address

julf
In reply to this post by Arjan Schrijver
I have exactly the same bug on i386,  OpenBSD 5.2-stable

If round-robin statement is in pf.conf, I get kernel panic, but only if network is actually connected. Commenting out round-robin statement, or disconnecting network cable allows system to boot. Reconnecting cable, with statements uncommented, results in panic.
Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in PF with round robin sticky address

Mike Belopuhov-5
Please try current.
On Jan 11, 2013 5:59 PM, "julf" <[hidden email]> wrote:

> I have exactly the same bug on i386,  OpenBSD 5.2-stable
>
> If round-robin statement is in pf.conf, I get kernel panic, but only if
> network is actually connected. Commenting out round-robin statement, or
> disconnecting network cable allows system to boot. Reconnecting cable, with
> statements uncommented, results in panic.
>
>
>
> --
> View this message in context:
> http://openbsd.7691.n7.nabble.com/Possible-Bug-in-PF-with-round-robin-sticky-address-tp219322p221787.html
> Sent from the openbsd dev - bugs mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in PF with round robin sticky address

julf
Seems to be fixed in OpenBSD 5.2-current (GENERIC) #14