h?
The two cluster members have a direct cross-cable between them. My PF
policy has these settings:
set skip on pfsync0
pass quick on fxp0 proto pfsync # $pfsync_syncdev
--
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I h
lied.
Note that the "set skip" is on the pfsync0 pseudo interface, while the
"pass quick" is on the actual fxp0 interface.
Is there a protocol other than pfsync that should be permitted on that
interface? I didn't expect I'd see
ine that racoon(8) would have
to take on that role, and I am curious if any work has been done to
facilitate this.
If there is any further work needed, I would like to look into
completing it, but I don't want to start from scratch unless I have
to. Please let me know what info is available.
dst mac, and 2
bytes for ethertype ipv4. 1500 + 6 + 6 + 2 = 1514.
> pf silently (no log entries) drops last packets, because they never
> reach the client:
Maybe PF does not log the packets via pflog0 interface, but does it log
anything via dmesg? Did you try setting a higher debug level via
qualifier, you would need
rules matching the inbound and outbound packets. I think you would
find, if you go ahead and tried the above, that the second rule never
sees any matches, because the first rule handles them and builds state
which causes the second rule to never be used.
- --
David DeSi
e evaluation. It will perform this state evaluation TWICE, once
for ingress, again for egress.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up because
by that time I was too f
quick on gpx0 all
pass in on asdfiawe934 from 1.2.3.4 to 4.3.2.1
PF did not complain one bit about these nonsensical interface names, and
"pfctl -sr" verifies that they do indeed remain in force, even though
they have no chance of matching anything.
- --
David DeSimone == Network Ad
interface
can affect whether a ruleset will load. However, the use of dynamic IP
syntax (which seems a "best practice" in my mind, anyway) seems to avoid
this condition nicely, among the other benefits it provides.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"I
o y.y.y.y port zz \
tag REDIRECT -> w.w.w.w
pass in log quick on $EXT_IF all tagged REDIRECT
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up becaus
the queue assignment for each packet, as described.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up because
by that time I was too famous. -- Robert Benchley
-
all of the state entries from host1 to host2:
# pfctl -k -k
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up because
by that time I was too famous. -- Robert
not
removed?
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up because
by that time I was too famous. -- Robert Benchley
-BEGIN PGP SIGNATURE-
Version: G
e and destination IP's to be removed.
There is probably a good way to integrate this into your scripts so that
you don't have to perform the state removal manually; it can be done by
the same script that is removing anchors from PF policy and such.
- --
David DeSimone == Network Admin
It should not be a problem that both firewalls
respond to any arp request since they are serving the same information.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up becau
quot;carpdev" to assign a
virtual public IP, but it seems that is not possible with FreeBSD.
If I am wrong, I hope that someone will correct my understanding.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I had no
talent for wri
r can do to prevent hosts on the
internet from sending traffic too fast.
Once you have received the packets, it is too late to limit their
arrival rate.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I had no
talent for writing, bu
ource IP of !($ext_if),
so it will end up matching ALL traffic.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up because
by that time I was too famous. -- Robert Bench
the destination port.
Use "rdr" command instead of "nat".
The documentation talks around and around this without actually saying
it, but it is as simple as this: "nat" modifies the source IP / port.
"rdr" modifies the destination IP / port.
- --
David
he
first packet that gets dropped, which reduces logging considerably.
However, you will not be alerted to the fact that millions of packets
are being sent, in this scenario, so you would have to detect that via
other means.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email mess
t on $ext_if from $server1 to any
no nat on $ext_if from $server2 to any
nat on $ext_if from $internal204 to any -> $officepublicIP
and hopefully does what you want.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the us
must do this, the only
way that comes to mind would be using a proxy of some sort, opening a
secondary connection to the external host on behalf of the client.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has
ou should more accurately diagram the current network layout
and your desired layout so that we can tell you whether it will work.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has been sent, and may contain inform
s to me it would be easier to get the PIX firewall to send traffic
to HOSTB instead of HOSTA. If that device is outside your control,
probably the easiest thing for you to do is set up a generic proxy, like
"redir" or similar, to copy traffic over secondary connection to HOSTB.
-
rections.
I realize this is a FreeBSD mailng list, but you should go for the
simplest solution, because complex solutions tend to fail in complex
ways.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has b
ser wanted
to talk to, so it does not know which certificate should be sent. This
is the reason why every SSL site must have its own unique (public) IP
address.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has
https://subversion.example.com:445/
You can have PF forward the correct port to the correct server. This
allows the servers to be more independent of one another.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it
n order to make changes to it. That is just bizarre!
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has been sent, and may contain information that is confidential
or legally protected. If you are not the intende
> state too, though I don't know if FreeBSD pf supports that (OpenBSD
> > pf does).
Of course PF supports this, but "state" on a "stateless" connection is
maintained purely with timers. When the timers expire, the state
expires.
- --
David DeSimone == Network Adm
7;t understand this question.
I think the question is asking for details on how PF state is stored in
memory. I found a very nice struct pf_state in /usr/include/net/pfvar.h.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the per
you capture a longer packet.
With recent changes to PF, the default capture size (68 bytes as seen
above) is insufficient. Try adding "-s128" to capture more of the
packets and you should see an improvement.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email messag
7;t match the rule (yet).
You have to allow the connection in on $int_if first, then when it
routes out $ext_if it will match the nat rule and set up state.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has been sent,
uot;pfctl -k"
command to kill state entries that have to do with the IP that is being
removed.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has been sent, and may contain information that is confidenti
is by running tcpdump on
both the internal and external interface, and comparing traffic.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has been sent, and may contain information that is confidential
or legally prote
atively, put these hostnames (and IP's) in your /etc/hosts file.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has been sent, and may contain information that is confidential
or legally protected.
wn, you will want "floating." Otherwise, choose
"if-bound" for security reasons.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"This email message is intended for the use of the person to whom
it has been sent, and may contain information that is confidential
; 1793916928:1793916928(0) win 16384
Since you went to the trouble of obscuring the source IP, I presume that
the source IP is your IP. So, these look like responses, i.e. outbound
traffic, not inbound, since they are sourced from your IP. You can use
tcpdump's -e flag to be sure who is se
is why PF in FreeBSD 7.0 add the "flags S/SA" and "keep state"
options by default. Since this is the default, it is surprising to me
that you would see this type of behavior, but it gives you something to
look into.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
the above, it appears that this may be
possible because PF processes the rulebase twice for forwarded traffic;
once on input, and again on output. If the inbound packet matched a
"rdr" rule, and the outbound matched a "nat" rule, this would accomplish
bidirectional NAT?
Interesti
(the source IP). In PF, you
can use "nat" to translate the source IP, and "redir" to change the dest
IP, but what if you want to change both? There is no direct way to do
this, so I am wondering if two different rules could be matched at
different times during the packet's
3034 3811 4089 59b3 c322
> 0x0010: c30e 3215 0935 0035 0023 0314 8c1d 0100
> 0x0020: 0001 0565 6d69 6c73 0363
> 0x0030: 6f6d 0100 01
Even if PF causes the packet to be dropped, it will still show up on
your inbound interface. You cannot
ite direction
to block replies, at least temporarily just to stop these state entries
from being recreated.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
"I don't like spinach, and I'm glad I don't, because if I
liked it I'd eat it, and I just h
this list (and experienced it
myself) that "modulate state" does not work. But I don't really know
why it doesn't work, and what behavior you should expect if you attempt
to use it. I would suggest you try "keep state" instead, before
proceeding further.
- --
David
ay of yours) are clean and not doing anything they
shouldn't be.
It's easy to say that you did not set up anything bad on your systems,
but can you really say with certainty that no one has broken into your
systems and installed something you don't know about?
--
David DeSimone
Eric Williams <[EMAIL PROTECTED]> wrote:
>
> David DeSimone wrote:
> > You may want to consider adding "keep state" to your "block log" rules.
>
> Doesn't seem to work, it just gives "keep state on block rules doesn't
> make sense&q
92.168.0.0/24
Also, don't you think you should put the "no nat" rule before the "nat"
rules?
--
David DeSimone == Network Admin == f...@verio.net
"I don't like spinach, and I'm glad I don't, because if I
liked it I'd eat it, and I just hate it.
rovide routing
for a firewalled connection. A device far across a WAN doesn't seem
like it would be able to provide redundant service. But that's up to
your design, I suppose.
Syncing across a LAN could make sense, but you will want to take steps
to secure the traffic.
--
David
gging considered part of the "state" that is kept
in the state table?
--
David DeSimone == Network Admin == f...@verio.net
"I don't like spinach, and I'm glad I don't, because if I
liked it I'd eat it, and I just hate it." -- Clarence Darrow
This email
wing it to update its TCP window tracking.
As a result, short TCP sessions, such as those that fit within the
default TCP window, can work okay, but longer sessions that go beyond
that window will stall out and fail.
--
David DeSimone == Network Admin == f...@verio.net
"I don't like spina
ivate. The public
interface connects only to your router, while the private interface
connects to all your firewall clients. This forces the firewall to be
the only path to and from the network, giving enhanced security.
--
David DeSimone == Network Admin == f...@verio.net
"I don't like
es to block (quick) port 548 (part of $bad_ports), so
your rules that occur later cannot allow that port.
--
David DeSimone == Network Admin == f...@verio.net
"I don't like spinach, and I'm glad I don't, because if I
liked it I'd eat it, and I just hate it." -- Cl
t ftp-data
> to $ext_IP port > 1 keep state
Are you sure you don't mean:
pass out quick on $ext_if inet proto tcp from $ext_IP port ftp-data \
to any port > 1 keep state
--
David DeSimone == Network Admin == f...@verio.net
"I don't like spinach,
Stefan wrote:
>
> Pf doesn't seem to be able to route packets on the outbound interface.
> Therefore you have to always put the route-to statements on "pass in
> on..." rules.
What you'd want to use for received traffic is "pass in" rules that m
ill never be checked, because they match the previously built state.
In order to prevent communications with these hosts, you must also add
"block out [quick]" rules which prevent you from initiating the
connection to them and thus building state entries.
--
David DeSimone == Net
y for some reason?
You may want to add "log" to the early pass rule, and then you can
compare the timestamp between when the initial SYN arrived for a
connection, and the later block occurred for a packet in the middle of
the connection.
--
David DeSimone == Network Admin == f...@v
h
> "block all"? In other words, how bad it is to have all outgoing ports
> always opened and whether someone can use this to hack the sysem?
>
> Thanks a lot for any tips!!
> Aleksej.
--
David DeSimone == Network Admin == f...@verio.net
"I don't like spinac
hat packet marking be used to mark packets arriving
via $int_if, and then apply NAT to the packets that flow to $ext_if:
nat on $ext_if tagged NAT -> $ext_if
pass in on $int_if tag NAT
pass out on $ext_if
Untested configuration idea, of course. :)
--
David DeSimone == Network
Another one, is it possible to filter in/out coming traffic according
> to the source/destination MAC address separately?
As far as I'm aware, PF is a layer-3 only filter, and has no ability to
filter on MAC.
--
David DeSimone == Network Admin == f...@verio.net
"I don't like
g PF rulesets, you should choose to
either always use quick, or never use quick, else you may end up easily
confusing yourself.
--
David DeSimone == Network Admin == f...@verio.net
"I don't like spinach, and I'm glad I don't, because if I
liked it I'd eat it, and
anchor case
> doesn't. Am I doing something wrong here?
The "anchor" directive tells PF to only evaluate filter rules from the
anchor. I would assume you also need "nat-anchor" and "rdr-anchor"
directives to force all of the anchor rules to be evaluated:
nat-
The message " pfctl: DIOCSETSTATUSIF" indicates that pfctl is bombing out
before it actually loads the rules into the kernel. It's a rather unhelpful
message, since it does not point out the source of the problem, though.
A little web searching turned up that most likely your pf.conf references
Also I should have looked further to see this line:
set loginterface egress# Can't remember what this does
I think that statement needs a real interface name, which "egress" probably
isn't.
-Original Message-
From: David DeSimone
Sent: Monday, November 03, 20
The man page makes it clear that "dup-to" acts just like "route-to", except
that the original packet still routes the way it would have. The implication
being that "dup-to" needs to determine where to route the new packet.
This means that the more useful form of this is likely to be:
pass
62 matches
Mail list logo
