On Thursday 11 August 2005 17:35, Sergey Lapin wrote:
> >
> > * Bug#3 (critical) *
> >
> >
> > Because route-to for "out" rules did not work well, we decided to
> Here's more proper description of the problem:
>
> Hi.
>
> While trying to configure pf on our freebsd 5.4 router we have
> encountered three bugs, one of which is minor, second is more serious.
> And the worst of all, because of the second bug we have to use
> workaround and that workaround tr
> > What version of FreeBSD are you running? Do you have a SMP/PREEMPTION
> > kernel?
> > Does setting debug.mpsafenet=0 in loader.conf change the situation? Do you
> > have a chance to attach a remote debugger or can you try to break into the
> > debugger from the console?
> Status update:
> It
On 8/6/05, Max Laier <[EMAIL PROTECTED]> wrote:
> Sergey,
>
> On Friday 05 August 2005 13:29, Sergey Lapin wrote:
> > Hi, all:
> <...>
> > Test case:
> > (done from Linix machine from 1.1.1.128/25)
> >
> > tcpreplay -e 1.1.1.133:255.255.255.255 -i eth0 packet
> > (where packet is random captured U
On Mon, Aug 08, 2005 at 06:18:28PM +0400, Sergey Lapin wrote:
> It does not help. Actually, it looks like pf does not have control
> over outgoing packets produced by pf itself. I can not neither block
> nor reroute these packets. I checked this very easily - I created a
> rule
>
> block out log
> I've the same situation here and we use route-to to route everything
> from ISP1's network to their gateway and vice-versa.
>
> route-to re-routes a packet from 1.0.0.0/24 when it's trying to leave
> through the ISP2 interface and everything then gets NAT'ed properly.
>
> pass out on $ext
Sergey Lapin wrote:
When pf blocks incoming packet with "block return" rule, it does not
return RST or ICMP packet to the interface from which original packet
came from but always use default gateway instead. This way if we have
default gateway set to ISP2's 2.0.0.1 and packet destined to 1.0.0.2
> What version of FreeBSD are you running?
5.4-RELEASE
> Do you have a SMP/PREEMPTION kernel?
No
> Does setting debug.mpsafenet=0 in loader.conf change the situation? Do you
> have a chance to attach a remote debugger or can you try to break into the
> debugger from the console?
Will try it, than
Sergey,
On Friday 05 August 2005 13:29, Sergey Lapin wrote:
> Hi, all:
<...>
> Test case:
> (done from Linix machine from 1.1.1.128/25)
>
> tcpreplay -e 1.1.1.133:255.255.255.255 -i eth0 packet
> (where packet is random captured UDP packet using tcpdump -peni)
>
> or
>
> tcpreplay -e 1.1.1.133:10.
Hi, all:
Configuration:
(all addresses fake, 1.1.1.x - from ISP1, 2.2.2 - from ISP2)
# grep ifconfig /etc/rc.conf
ifconfig_xl0="inet 1.1.1.254 netmask 255.255.255.128"
ifconfig_xl0_alias0="inet 2.2.2.2 netmask 255.255.255.128"
ifconfig_xl1="inet 192.168.255.1 netmask 255.255.255.255"
ifconfig_vlan0
10 matches
Mail list logo
