Re: Fwd: pf problems
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 UDP packet using tcpdump -peni) or tcpreplay -e 1.1.1.133:10.2.2.2 -i eth0 packet (where packet is random captured UDP packet) kills machine. Machine hangs and doesn't react on keyboard, whatever. Only reset helps. Directly blocking addresses in pf.conf help and normal connections with UDP disabled work well. Any ideas? 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's not SMP/PREEMPTION kernel debug.mpsafenet=0 doesn't help I couldn't break into debugger - machine is locked and looped somehow. It sends that packet in loop even when we stop sending it. More than that - the situation doesn't replicate in vmware. More on that - when we set everything on VLANs and use only one physical interface (fxp), about 30 seconds passes before machine dies and if we stop sending traffic, it survives. Seems like some buffer filling... When we use several physical interfaces(fxp, xl0, xl1) without vlans system die immediately. Any ideas? ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: pf problems
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's not SMP/PREEMPTION kernel debug.mpsafenet=0 doesn't help I couldn't break into debugger - machine is locked and looped somehow. It sends that packet in loop even when we stop sending it. More than that - the situation doesn't replicate in vmware. More on that - when we set everything on VLANs and use only one physical interface (fxp), about 30 seconds passes before machine dies and if we stop sending traffic, it survives. Seems like some buffer filling... When we use several physical interfaces(fxp, xl0, xl1) without vlans system die immediately. Any ideas? Now more on that - We installed 6.0beta2 and this problem is still here, BUT I could get into debugger. Any ideas how could I localize this problem? ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: pf problems
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, thanks for idea.
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 triggers third bug which is actually
critical (because it hangs device and floods the network). I'll try to
explain these bugs briefly. Please advice where to report each fo
them. We haev no idea if they are PF global or FreeBSD specific. We
are going to repeat all the scenarios on OpenBSD.
Background: we have two ISP connections and it is the source of all
our problems - looks like work in such a mode is not debugged very
well in pf.
Setup:
Let's say ISP1 gives us 1.0.0.0/24 block with their gateway at
1.0.0.1. Our router is at 1.0.0.254.
Similarly, ISP2 gives us 2.0.0.0/24, their gateway is at 2.0.0.1
and our router is at 2.0.0.254.
ISP2 gateway (2.0.0.1) is our default gateway.
We have DMZ where hosts of both ISP network live
(dmz_net1=1.0.0.128/25 and dmz_net2=2.0.0.128/25).
+---+
1.0.0.254 | |
---+ ext_if1 |
| | dmz_net1
|dmz_if +
2.0.0.254 | | dmz_net2
---+ ext_if2 |
| |
+---+
Note that firewall rules below are oversimplified to make rule listing
compact. In our real firewall we differentiate between TCP and
UDP/ICMP traffic to make sure all outgoing TCP connections use
modulate state insted of keep state etc. Also ruleset below
loosened in terms it uses any where our real ruleset explicitly
defines networks. Again, this is only to demostrate problem with
minimum amount of rules.
** BUG#1 (minor) ***
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.254
comes from ISP1 interface (ext_if1) and this packet gets blocked with
block return, the TCP RST packet with source address 1.0.0.254 will
be sent through 2.0.0.1 gateway. Obviously, ISP2 drops packets which
source does not belong to their network so basically block return
does not work at all.
** Bug#2 (severe) **
ruleset:
#33
# nat outgoing connections on each internet interface
nat on $ext_if1 from { $dmz_net2 } to any - ($ext_if1)
nat on $ext_if2 from { $dmz_net1 } to any - ($ext_if2)
# default deny silently
block drop all
# pass in quick any packets destined for the gateway itself
pass in quick on $dmz_if from any to $dmz_if keep state
pass quick on lo0
# Classify traffic from DMZ
# Allow all outgoing connections from DMZ
pass in on $dmz_if inet from $dmz_net1 to any keep state tag DMZ_TO_EXT1
pass in on $dmz_if inet from $dmz_net2 to any keep state tag DMZ_TO_EXT2
# Allow gateway to route between different networks on the DMZ
pass in on $dmz_if inet from { $dmz_net1, $dmz_net2 } to { $dmz_net1,
$dmz_net2 } keep state tag DMZ_TO_DMZ
# Reroute OUT traffic appropriately
pass out quick on $ext_if1 route-to ($ext_if2 $ext_gw2) tagged
DMZ_TO_EXT2 keep state
pass out quick on $ext_if2 route-to ($ext_if1 $ext_gw1) tagged
DMZ_TO_EXT1 keep state
# general pass out rules for external interfaces
pass out on { $ext_if1, $ext_if2, $dmz_if } from any to any keep state
#33
Note that route-to rules should re-route all the traffic to proper
interface regardless of default gateway specified.
What happens with such a rules:
* When a host from dmz_net1 sends packets to the internet and default
gateway is ISP1 one, everything works fine and no translation is
performed.
* When we change default gateway to the ISP2 very interesting thing
happens: packet from dmz_net1 host leaves ext_if1 BUT it gets
translated like it should leave ext_if2!
I do not understand this one completely.
* Bug#3 (critical) *
Because route-to for out rules
Re: Fwd: pf problems
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_isp2_if route-to ($ext_isp1_if $ext_isp1_gw) from $isp1_net to any 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 quick from SOME_OUTSIDE_HOST/32 to any block out log quick from any to SOME_OUTSIDE_HOST/32 and made it very first rules of the firewall. Needless to say, when I tried to telnet to router port from SOME_OUTSIDE_HOST, tcpdump on the pflog0 device got incoming SYN but did not show RST. From the other hand, tcpdump on the default gateway interface shown outgoing RST. Again, from this I conclude that pf-generated packets (RST/ICMP) are not subject for ruleset processing. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: pf problems
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 quick from SOME_OUTSIDE_HOST/32 to any block out log quick from any to SOME_OUTSIDE_HOST/32 and made it very first rules of the firewall. Needless to say, when I tried to telnet to router port from SOME_OUTSIDE_HOST, tcpdump on the pflog0 device got incoming SYN but did not show RST. From the other hand, tcpdump on the default gateway interface shown outgoing RST. Again, from this I conclude that pf-generated packets (RST/ICMP) are not subject for ruleset processing. No, they are not. You can try a 6.0 RC containing a newer version of pf which sends TCP RSTs (generated by 'return-rst') back out through the interface the blocked packet came in through. Alterantively, use multiple filtering devices, one in front of each uplink. Daniel ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: pf problems
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.2.2.2 -i eth0 packet (where packet is random captured UDP packet) kills machine. Machine hangs and doesn't react on keyboard, whatever. Only reset helps. Directly blocking addresses in pf.conf help and normal connections with UDP disabled work well. Any ideas? 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? -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp2RNIQdu5VL.pgp Description: PGP signature
