Re: Redundant Bridging Firewall
On Fri, 2005-01-21 at 12:48 -0800, Dylan Martin wrote: > My redundant bridging firewall don't work no more with 3.6! > > As background, the bridge interfaces have 'learn' disabled. That means, > they never cache information about which interface a packet came from. > (The inactive bridge would think all external hosts were attached to > the internal interface.) > > Internal Host A sends a packet for Internal Host B > Switch receives packet and records which port Host A is connected to. > Switch's mac address list doesn't contain Host B's Mac address Switch > floods the packet out all it's interfaces > Packet arrives at Bridge > Bridge doesn't know where Host B is, and because 'learn' is disabled, it > also doesn't know where Host A is. It floods the same packet out > all interfaces, including the one the packet came in on. > Packet arrives at Switch > Switch thinks Host A has moved to the port the Bridge is attached to > and starts sending all packets intended for Host A to the Bridge > instead. This continues until Host A sends out a packet that > corrects the Switch's idea of where Host A is. > Ahh!! so that's what is going on! We just moved our (very similar set up) to 3.6 and had similar problems. The the chief network guru went on holiday so we simply disabled one of the firewalls and waited until he gets back. We had not got to the stage of tracing individual packets through the network to figure out what was happening. > > If anyone has any ideas, please let me know. Me too :) Russell.
Redundant Bridging Firewall
My redundant bridging firewall don't work no more with 3.6! Hi folks, a while back I set up a redundant bridging firewall and I wrote up a web page describing how it works. Well, now that I've upgraded to 3.6, I've discovered it doesn't work any more. So! If you were going to follow the directions in my web page to build a redundant bridging firewall, DON'T! At least not yet. My page of LOUSY advice is at http://www.seattlecentral.edu/~dmartin/docs/bridge.html If you're interested in what isn't working and how you might be able to help me figure it out, read on. It looks like (and I stress 'looks like') the following scenario is giving the internal switch a headache. As background, the bridge interfaces have 'learn' disabled. That means, they never cache information about which interface a packet came from. (The inactive bridge would think all external hosts were attached to the internal interface.) Internal Host A sends a packet for Internal Host B Switch receives packet and records which port Host A is connected to. Switch's mac address list doesn't contain Host B's Mac address Switch floods the packet out all it's interfaces Packet arrives at Bridge Bridge doesn't know where Host B is, and because 'learn' is disabled, it also doesn't know where Host A is. It floods the same packet out all interfaces, including the one the packet came in on. Packet arrives at Switch Switch thinks Host A has moved to the port the Bridge is attached to and starts sending all packets intended for Host A to the Bridge instead. This continues until Host A sends out a packet that corrects the Switch's idea of where Host A is. Right now, I'm playing around with static mac address tables in the switch. If that fixes it, it will support my theory, but it won't really be a workable solution. Maybe I could turn off 'learn' on the switch port attached to the bridge somehow. Maybe I could write a pf rule of some kind that would make the bridge only pass packets out of interfaces they didn't arrive on. If anyone has any ideas, please let me know. Thanks -Dylan Martin Unix Admin Seattle Central Community College
Re: Using DNS names in pf.conf?
Henning Brauer wrote: * Kevin <[EMAIL PROTECTED]> [2005-01-19 21:41]: Are there any "gotchas" I should know about when using dns names in pf.conf, specifically in tables used as destinations for permit rules? well, if DNS is not available by the time pfctl tries to load your pf.conf you're pretty much screwed. and pf is enabled very early at boot. try it out, and most importantly, get clear about the external dependencies you introduce and their consequences. I've set my home router up like this and at least on older versions of obsd (I'm currently 2 versions behind) the initial pfctl load comes before named starts so if you run a local name server it will hang. The fix for my system was to reorder startup slightly although this would not work universally. I'd suggest: a) keeping names out of pf.conf or b) large blocks of names (for blacklisting/whitelisting) should go into tables as you explained. for cases where tables are overkill, add those host names to /etc/hosts and refresh it from dns when you reboot. if the names go stale between reboots you'll need to manually (or though cron) refresh but if you used dns directly you'd still have to refresh your pf rules when the addr translations go stale so this should not be too much of a problem.
Re: pf: messages /bsd: pf_map_addr: selected
I do the same test on a FreeBSD 4.8-p17, IP Filter: v3.4.31.
There is no lost of packets.
I change my perl script to send more slowly the snmp packets.
With 100 000 packets in 31 seconds, 82599 are received.
With 100 000 packets in 89 seconds, 5 are received !!!
Some help ?
Here my perl script:
# script de generation de trafic
# auteur: Marc GAUTHIER
#
# pseudo package, juste pour faciliter le debug
package _Net::RawIP;
use strict;
sub new {
my($class, $name) = @_;
my $self = {
ip => {
saddr => '',
daddr => '',
},
udp => {
dest => '',
source => ''
}
};
bless($self, $class);
return $self;
}
sub set {
my $self = shift;
my $data = shift;
while( my ($k,$v ) = each(%$data) ) {
$self->{$k} = $v;
}
}
sub send {
my $self = shift;
printf("%-20s:%5s
=>%-20s:%5s\n",$self->{ip}->{saddr},$self->{udp}->{source},$self->{ip}->{daddr},$self->{udp}->{dest});
}
package main;
use strict;
use Getopt::Long;
my ( $sint,$dint,$dest,$source );
my $saddr = '192.168.3.1';
my $sport = '1024';
my $daddr = '192.168.13.5';
my $dport = '161';
my $sa_iter = '0';
my $sp_iter = '0';
my $da_iter = '0';
my $dp_iter = '0';
my $count = 0;
my $max = 20;
my $sleep = 0;
my $boucle = 5000;
my $debug = 0;
my $hostname = (gethostbyname ("localhost"))[0];
my @ifconfig = `/sbin/ifconfig -a`;
my $interface = '';
my $ip = '';
foreach my $line (@ifconfig) {
#print "line:$line";
$interface = $1 if ( $line =~/(^\w+(?:\d)?(?:\:\d)?)/ );
if ( ($ip) = ($line =~/inet (?:addr\:)?(\d+\.\d+\.\d+\.\d+)/)) {
last;
}
}
print "interface:$interface ip:$ip\n";
$saddr = $ip;
GetOptions(
"saddr=s"=> \$saddr,
"sport=s"=> \$sport,
"daddr=s"=> \$daddr,
"dport=s"=> \$dport,
"da_iter=s" => \$da_iter,
"dp_iter=s" => \$dp_iter,
"sa_iter=s" => \$sa_iter,
"sp_iter=s" => \$sp_iter,
"sleep=s"=> \$sleep,
"boucle=s" => \$boucle,
"max=s" => \$max,
"debug=s"=> \$debug,
);
my $scenario = shift if ( @ARGV );
if ( $scenario =~ /intra/i ) {
$sa_iter = '19';
$saddr = '10.0.0.1';
}
if ( $scenario =~ /extra/i ) {
$da_iter = '19';
$daddr = '10.128.0.1';
}
if ( $scenario =~ /big/i ) {
if ( $da_iter > 0 ) { $da_iter = 20 };
if ( $sa_iter > 0 ) { $sa_iter = 20 };
}
print "max:$max boucle:$boucle\n";
my $data =
'302902010004067075626c6963a01c0204094b6a71020100020100300e300c06082b060102010101000500';
my $pdata= pack('H*',$data);
use Net::RawIP qw();
my $a = new Net::RawIP ({udp =>{}});
$dint = ip2int($daddr);
$sint = ip2int($saddr);
my $start = time;
for ( my $daddr_offset = 0; $daddr_offset <= $da_iter; $daddr_offset++ ) {
for ( my $saddr_offset = 0; $saddr_offset <= $sa_iter; $saddr_offset++ ) {
$dest= int2ip($dint+$daddr_offset);
$source = int2ip($sint+$saddr_offset);
$a->set({ip => {saddr => $source, daddr => $dest} });
for ( my $sport_offset = 0; $sport_offset <= $sp_iter; $sport_offset++ ) {
for ( my $dport_offset = 0; $dport_offset <= $dp_iter; $dport_offset++ ) {
$a->set({ udp => {
dest => $dport,
source => $sport_offset+$sport,
data => $pdata,
}} );
$a->send($sleep);
# pour ralentir
for(1..$boucle) { };
$count++;
last if ( $count >= $max );
}
last if ( $count >= $max );
}
last if ( $count >= $max );
}
last if ( $count >= $max );
}
my $stop = time;
print "count:$count duree:".($stop-$start)."\n";
sub usage {
warn "$0: @_\n" if @_;
die < 0 ) && ( $int < 4294967295 ) ) {
my $w=($int/16777216)%256;
my $x=($int/65536)%256;
my $y=($int/256)%256;
my $z=$int%256;
my $ip = $w . "." . $x . "." . $y . "." . $z;
return $ip;
} else {
return 0;
}
}
Re: First time user comments
On Thu, 2005-01-20 at 17:05, Peter Fraser wrote:
> The very broad: I don't understand why there is separate configuration
> files for bridges and routing and packet filtering.
routing and bridging are two separate things.
> Now for the picky ones.
>
> Could the "syntax error" message, give the position in the line that the
> error occurred, or at least the token that caused it. When you are a
> first time user you syntax errors are not obvious.
>
> I could find no where in the documentation that says what happens when
> you omit the "on " clause. The documentation implies that it
> must always be given, and grammar in "man pf.conf" shows it as being
> required, but several examples don't supply one.
the GRAMMAR section in pf.conf show this:
pf-rule= action [ ( "in" | "out" ) ]
[ "log" | "log-all" ] [ "quick" ]
[ "on" ifspec ] [ route ] [ af ] [ protospec ]
hosts [ filteropt-list ]
where "on ifspec" is in [] denoting that it's optional. in the intro
paragraph of the PARAMETERS section it also states "Most parameters are
optional." from the above--the only required parameters are "action"
and "hosts" making the simplest rule possibilities:
block all
pass all
> I believe that not
> supplying a "on " means the statement applies to all
> interfaces.
correct. just like not specifying in|out means the packet can match in
either direction.
> What needs to be quoted in a macro is not documented. One of my first
> mistakes was to write
> Internal_net = 192.168.200/24
> I could not find any documentation that said it had to be written as
> Internal_net = "192.168.200/24"
> with quotes. I also tried
> DebugLog = log
> and got a similar error.
i have never seen an example where the value of a macro was not quoted.
the exception to this is macros inside of macros, which is pointed out
in the MACROS section of the man page:
Macros are not expanded inside quotes.
For example,
ext_if = "kue0"
all_ifs = "{" $ext_if lo0 "}"
> I have several (actually three) segments, each of which have their own
> set of IP address. I wanted each segment to be only allowed to send in
> from IP addresses belonging to the segment, (and for good message stop
> the
> firewall from putting out packets onto a segment that they did not
> belong on). I expected an option on the antispoof directive to implement
> this effect, but it was not there so I wrote:
> InternalInterfaces = "{" ste1 ste2 ste3 "}"
> block in quick on $InternalInterfaces from !$id:network
> block out quick on $InternalInterfaces to !$id:network
> and was surprised to get "macro id is not defined". I believe the $id is
> only defined in certain contexts. Now I can get the same effect by
> writing the six statements which is what I did, but I was surprised.
um--that's what "antispoof" is for--source address verification inbound
on a given interface. as for your good measure(?) of blocking packets
outbound from the firewall...that's what the routing table is for...IMHO
i don't see the "good" in that measure(?).
as for pf not magically knowing what $id is supposed to mean; i'm not
sure why you think it would--also not sure why you'd be surprised that
it would tell you that the macro isn't defined, as you clearly didn't
define it. the macro $magic_miss_cleo_psychic_logic isn't defined
either--so it doesn't surprise me when my rules fail to load when i
reference it. computers do what you tell them to do--they're funny that
way.
<--snip dns resolving in rules comments-->
> It would be nice if there was a predefined macro for the unrouteable
> address.
all IP address are routeable, as IP is a routed protocol; unlike say,
NetBEUI for example... i could be so bold as to assume you mean the RFC
1918 address spaces reserved for private networks, but i would just be
assuming. maybe you mean the RFC 3330 special-use addresses, sans the
cable modem 24/8 network. maybe you mean all the network blocks listed
on http://www.iana.org/assignments/ipv4-address-space as
Reserved|Private Use|Returned. ah--but this list is a moving target
that can be modified at any time--last update was 02Aug2004, fyi... the
pf developers; much like the parsing engine, are not
mind-readers--firewalling is a personal thing: say what you mean and
mean what you say. how hard is it to define what *you* actually mean by
"unrouteable" in a template file that you create your firewall configs
from?
> It would be nice if there is only one interface type on the computer to
> define a macro automatically for them, I suggest $id0 $id1 etc. That way
> pf config files could be more portable, particularly in the case of a
> server machine that only has one interface.
not 100% sure what you mean here, but if you mean being able to refer to
hme0, hme1, hme2, hme3, and hme4 simply as hme--then it's already there.
> I could not find a documentat
Re: Using DNS names in pf.conf?
On Thu, 20 Jan 2005 14:33:00 +0100, Henning Brauer <[EMAIL PROTECTED]> wrote: > * Kevin <[EMAIL PROTECTED]> [2005-01-19 21:41]: > > Are there any "gotchas" I should know about when using dns names in > > pf.conf, specifically in tables used as destinations for permit rules? > > well, if DNS is not available by the time pfctl tries to load your > pf.conf you're pretty much screwed. and pf is enabled very early at > boot. > may be this is the reason my "SQUID" fails during startup!! I get a few error message that squid exits due to repeated freequent failures and after the login prompt appears I get this messages once more but by that time SQUID is up and running. A person not used to this might think that SQUID failed to startup looking at the conslole. :))) Thankyou henning for the reply Kind Regards Siju
Re: First time user comments
* Peter Fraser <[EMAIL PROTECTED]> [2005-01-21 00:54]: > Could the "syntax error" message, give the position in the line that the > error occurred, or at least the token that caused it. no - that is not how parsers work. syntax error actually says it didn't match any production from the grammar. if we don't know what production it should have matches, how should we tell which part didn't? that is just not how parsers work, sorry. > I believe that not > supplying a "on " means the statement applies to all > interfaces. yes. > It would be nice if there is only one interface type on the computer to > define a macro automatically for them, I suggest $id0 $id1 etc. That way > pf config files could be more portable, particularly in the case of a > server machine that only has one interface. that will be solved by interface groups. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
