Hi,
I just re-read the ipfw man page about one_pass = 0.
# sysctl -d net.inet.ip.fw.one_pass
net.inet.ip.fw.one_pass: Only do a single pass through ipfw when using
dummynet(4)
I think next to dummynet, the definition also counts for netgraph and NAT
rules, but not for every rule. So I doubt
y ceavets with this ruleset when redirects are happening for
> example? I'm also wondering if Belgian PF users have the same issue?£
> >
> > I'm hopeful to get to the bottom of this as its quite annoying needing
> to switch wifi channels to my ISP's router which doe
s quite annoying needing to
switch wifi channels to my ISP's router which does work with these applications.
Regards
Dries
Hi,
It is a while ago that I build ipfw firewalls, but doesn't rule 10 match all
internal (from LAN) traffic, preventing outgoing (to WAN) packets to get to th
or an "application" to use FIB 1 instead of the default 0, just:
# setfib 1 application
Or to get another source IP address to use FIB 1, make firewall rule to send it
there, eg.:
# ipfw add allow all from ... to any setfib 1
Is that what you need?
--
You are receiving this mail becau
Hello,
So I have a very basic ruleset, as described in the FreeBSD handbook, see
below. I have "blurred" my open ports as seen in the ruleset below.
Igc0 is my WAN port and in the table "trusted_if" are like my LAN if and
some bridges.
1 reass ip from any to any in
00010 allow ip from any to
be reassembled. so:
add allow ip from any to any frag
works pretty well. per ipfw(8), the "frag" option means non-initial fragments:
Fragmented packets which have a non-zero offset (i.e., not the
first fragment) will never match a rule which has one
Van: mike tancsa
Datum: donderdag, 29 augustus 2024 20:51
Aan: FreeBSD Net
Onderwerp: dropping udp fragments with ipfw
I was working on some firewall rules to drop large UDP fragment attacks and
noticed there is no easy way to drop fragments based on port ? e.g. if someone
sends a UDP
performing UDP/TCP port filtering.
Refer to the ipfw(4) man page on the "reass" keyword, which provides
the following example:
ipfw add reass all from any to any in
I hope this helps!
Thanks very much, it does! Under DDoS attack, how "expensive" would
this be I noticed th
?
>
>
When a packet is fragmented, only the IP header (not the UDP header that
includes the port number) is copied for all subsequent fragmented packets.
To fix this behavior, you can instruct the firewall to reassemble the
packet before performing UDP/TCP port filtering.
Refer to the ipfw(
I was working on some firewall rules to drop large UDP fragment attacks
and noticed there is no easy way to drop fragments based on port ? e.g.
if someone sends a UDP packet of 1400 bytes, I can drop it with
TARGET=192.168.1.1
ipfw add 5 deny log udp from any 53 to $TARGET
But if that packet
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=103135
Eugene Grosbein changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
Am Mon, 8 Jan 2024 01:33:53 +0100 (CET)
Felix Reichenberger schrieb:
> > Hello,
> >
> > I've got a problem with recent CURRENT, running vnet JAILs.
> > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET
> > 2024 amd64
> >
> >
> Hello,
>
> I've got a problem with recent CURRENT, running vnet JAILs.
> FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET
> 2024 amd64
>
> Main Host has IPFW configured and is open for services like OpenLDAP on
> UDP/TCP and ICMP
>
Hello,
I've got a problem with recent CURRENT, running vnet JAILs.
FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET 2024
amd64
Main Host has IPFW configured and is open for services like OpenLDAP on UDP/TCP
and ICMP
(ipfw is configured via rc.conf in this case,
t the private bridge of course does
not even have any of this. Also we do not use pf anywhere but we do use
ipfw in every single jail for our inbound SNI proxy connections.
So for a quick test I changed these rules to firewall_type="open" in rc.conf
in two of the jails but that seemed not
e with a bhyve guest
the tap interfaces are bridged with the real hardware, and so, for lack
of a better term, have more or less the same identity.
But the MAC address will be different. That's why I was looking at layer2
and ipfw.
--
vixie
On Oct 15, 2023 07:14, void wrote:
Hello,
My objective is to protect services on a bhyve host, while allowing traffic
to the bhyve guests to pass to them unprocessed, as these each have pf and
their own firewall policies. The host running an up-to-date 13-stable.
I know ipfw can pr
Hello,
My objective is to protect services on a bhyve host, while allowing traffic
to the bhyve guests to pass to them unprocessed, as these each have pf and
their own firewall policies. The host running an up-to-date 13-stable.
I know ipfw can process both layer 2 and layer 3 traffic, but
Hello all,
After an hour of googling I turned up empty so I decided to post here.
I'm running a server with a single IPv4 address and a number of VNET
jails. The jails all have RFC1918 addresses and are connected to a
bridge. Pretty standard stuff and everything works, including individual
#6 from Franco Fichtner ---
Two things here:
1. Having a netpfil facility accommodating for multiple packet filters at the
same time and saying you shouldn't mix it is not a good argument, because e.g.
the ordering between ipfw/pf is easily made deterministic with something like:
# pfc
e NIC
level hooks allow to drop packets at a much lower cost. Second, you can build
your firewall based on interfaces, very much like Cisco or Juniper do.
- Although running a stack of firewalls (pf, ipfw, ipfilter) is not something
that is supported or recommended, some people do that and some con
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272094
--- Comment #4 from Kristof Provost ---
(In reply to Alfa from comment #3)
> I am also using ip_divert with ipfw because PF divert-to not works as
> expected #260867 this bug references divert-to infinite loop problem this bug
&
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272094
--- Comment #3 from Alfa ---
(In reply to Kristof Provost from comment #1)
"you can use dummynet with pf, and can also do basic layer 2 filtering with pf.
No doubt it's also possible to implement captive portal entirely with ip
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272094
Mina Galić changed:
What|Removed |Added
CC||free...@igalic.co
Status|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272073
Andrey V. Elsukov changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272073
Andrey V. Elsukov changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272073
--- Comment #3 from Alfa ---
(In reply to Andrey V. Elsukov from comment #2)
Yes, Thank you. I applied your sysctl tunable and captive portal worked as
expected since 18 hours.
may i know is that a final solution? and can it cause an anothe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272073
--- Comment #2 from Andrey V. Elsukov ---
Hi,
Can you try to set:
sysctl kern.ipc.mb_use_ext_pgs=0
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272073
Mina Galić changed:
What|Removed |Added
Status|New |Open
Assignee|b...@freebsd.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208649
Mark Linimon changed:
What|Removed |Added
Resolution|--- |Overcome By Events
Assign
to act weird:
> >
> > - the IPv4 address is always set correct, IPFW and in-kernel NAT
> > route/filter traffic correctly - sometimes old IPv6 address is dumped
> > and only a new IPv6 address - in such a case, the old IPv6 is gone,
> > the new pair (temporary and MA
correctly, IPv6 and IPv4 networks have conection to the internet.
When the ISP rotates it IPs, the IPv6 address is configured using
SLAAC and mpd5 seems to act weird:
- the IPv4 address is always set correct, IPFW and in-kernel NAT
route/filter traffic correctly - sometimes old IPv6 address is dumped
Hello,
running a small nanoBSD firewall/router appliance, the WAN interface (tun0) is
confugred via
SLAAC when it comes to IPv6. The allpliance is running in-kernel compiled IPFW.
The OS is
FreeBSD 13-STABLE, compiled on a recuurant weekly basis.
On a 24 hour basis, the ISP changes the IPv4
Am Fri, 25 Nov 2022 10:40:31 +0300
"Andrey V. Elsukov" schrieb:
> 24.11.2022 18:27, FreeBSD User пишет:
> > Hello,
> >
> > running a small routing/firewall applicance based on 13-STABLE and IPFW, I
> > face a problem
> > with NPTv6. The external
24.11.2022 18:27, FreeBSD User пишет:
Hello,
running a small routing/firewall applicance based on 13-STABLE and IPFW, I face
a problem with
NPTv6. The external IPv6 is changing dynamically. While ipfw in-kernel NAT
catch up with
dynamical changes of the IPv4, NPTv6 doesn't seem so.
Hello,
running a small routing/firewall applicance based on 13-STABLE and IPFW, I face
a problem with
NPTv6. The external IPv6 is changing dynamically. While ipfw in-kernel NAT
catch up with
dynamical changes of the IPv4, NPTv6 doesn't seem so.
I'm neither an expert in networkin
about 200 multicast streams (200K packets / 2G multicast traffic
incoming via one vlan100)
- ipfw to allow/deny incoming/outgoing traffic on any vlanX:
-- net.link.bridge.ipfw=1 -- to enable layer2 filtering (ARP)
-- net.link.bridge.ipfw_arp=1 -- to filter ARP
-- net.link.bridge.pfil_brid
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237840
Dervish changed:
What|Removed |Added
Resolution|--- |Feedback Timeout
Status|Open
> On 27 Aug 2022, at 15:48, Michael Pounov wrote:
>
> Hello all
>
> I want to propose one new feature about IPFW. FWSync driver exchange dynamic
> state and aliase records between routers.
> If you have interest about such feature to be implemented at FreeBSD code
>
> Only a quick look ...
>
> There is no guarantee, that the ports of the UDP packets are not modified by
> libalias (NAT is designed to do exactly this modification). So some of the
> matches seems to be a bit optimistic,
>
> > - This system has net.inet.ip.fw.one
On Mon, Aug 29, 2022 at 06:36:26PM +, tt78347 wrote:
> ipfw -q nat 1 config if $extif unreg_only reset \
> redirect_port udp 192.168.21.4:500 500 \
> redirect_port udp 192.168.21.4:4500 4500
> $add 450 nat 1 udp from any to any 500,4500 in via $extif
> $add 451 nat 1 udp
failing to redirect the packets, but it's also possible that they are somehow
being dropped.
Unfortunately I do not have a working IPFW log interface on this host (such as
ipfw0). The log interface works on many other hosts, which are configured
identically as far as I can tell, but on certa
Hello all
I want to propose one new feature about IPFW. FWSync driver exchange dynamic
state and aliase records between routers.
If you have interest about such feature to be implemented at FreeBSD code base.
You are fill free to get it.
I will be glad also for dicussion about current FWSync
Hello,
see also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265532
I had several cases where an freebsd-upgrade from 13.0 -> 13.1 with an
active ipfw ruleset:
# firewall, ipfw based
firewall_enable="YES"
firewall_type="OPEN"
caused the host after reboot to loose i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129036
Eugene Grosbein changed:
What|Removed |Added
Resolution|--- |FIXED
Status|Open
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
Kubilay Kocak changed:
What|Removed |Added
Status|Open|Closed
Keywords|needs-qa
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #16 from Jack ---
So far so good here on latest 13-stable.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
--- Comment #15
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208649
Graham Perrin changed:
What|Removed |Added
CC||grahamper...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
Lutz Donnerhacke changed:
What|Removed |Added
CC||don...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #13 from Jack ---
How did this bug get into -stable? ;)
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #12 from k...@denninger.net ---
(In reply to Jack from comment #11)
Same bug.
Hotfix here will stop it (note this is 12.2-STABLE, may be slightly different
offsets in 13+); I have roughly a day on it now with no panic and prev
10 in ?? ()
No symbol table info available.
#6 0x in ?? ()
No symbol table info available.
I'm also getting instant kernel panics when I tried doing ipfw nat without natd
in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257079
Not sure if it's related.
--
You are rece
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
k...@denninger.net changed:
What|Removed |Added
CC||k...@denninger.net
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #9 from Jack ---
-try
Forgot to mention it's happening on the latest git src
13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n246228-47c5e288eee9: Sun Jul 11
01:16:08 PDT 2021
natd is also nonstop crashing after the update
https:
Jack ---
I am getting an instant kernel panic when try a machine behind the nat tries to
access the internet.
I have the following firewall rules in ipfw bge0 being the public interface and
bge1 being the private with ip 10.0.0.1
ipfw nat 1 config if bge0 same_ports
ipfw add 100 nat 1 ip4 from any
gt;> don't
> >> cut it – udp traffic here is predominantly NTP and DNS, and the dynamic
> >> rule lifetime for UDP is very short (3-6 s). And of course they don't
> >> work
> >> at all for traffic initiated by the server side.
> >>
>
S, and the
> dynamic
> > >> rule lifetime for UDP is very short (3-6 s). And of course they don't
> > >> work
> > >> at all for traffic initiated by the server side.
> > >>
> > >
> > > QUIC connections aren't initiated b
DP is very short (3-6 s). And of course they don't
>> work
>> at all for traffic initiated by the server side.
>>
>
> QUIC connections aren't initiated by the server. The browser is initiating
> these connections. I'm not an ipfw user, the best generic fir
erver side.
>
QUIC connections aren't initiated by the server. The browser is initiating
these connections. I'm not an ipfw user, the best generic firewall strategy
would be to have some sort of flow tracking for ~30s for UDP flows
associated with tuples originating on the client
Hi, all. I noticed my firewall was dropping what seemed to be unsolicited
UDP connections from Google and Facebook, but this turned out to be QUIC
traffic. The traffic can be initiated by the browser (or other supporting
software) or the server. The problem is that dynamic rules generally don't
c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #7 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=38c299fe856216d6ab38eb5e04d9ee4f8c22995d
commit 38c299fe856216d6ab38eb5e04d9ee4f8c22995d
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #6 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=6b8c65318e81a451b33ed57b84a5495284dcb20f
commit 6b8c65318e81a451b33ed57b84a5495284dcb20f
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #5 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=c80a4b76ceacc5aab322e7ac1407eea8c90cb3b1
commit c80a4b76ceacc5aab322e7ac1407eea8c90cb3b1
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #4 from Andrey V. Elsukov ---
(In reply to Daniel Kempkens from comment #3)
inp_flags2 = 16
it looks like my guess was correct, PCB has INP_FREED flag set, so its socket
is already closed and should not be used. Proposed patch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #3 from Daniel Kempkens ---
(In reply to Andrey V. Elsukov from comment #1)
> I think such problem can be reproduced if you will do open/close divert
> socket in a loop. Is it possible that your application sometimes does that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
--- Comment #2 from Andrey V. Elsukov ---
Created attachment 223546
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=223546&action=edit
proposed patch (untested)
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254478
Kubilay Kocak changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
Keyword
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072
cayen14422 changed:
What|Removed |Added
CC||cayen14...@0335g.com
--- Comment #10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072
Eugene Grosbein changed:
What|Removed |Added
Flags|mfc-stable12?, |mfc-stable12+,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072
Andrey V. Elsukov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|New
: Andrey V. Elsukov
AuthorDate: 2021-02-25 13:57:47 +
Commit: Andrey V. Elsukov
CommitDate: 2021-03-04 09:23:01 +
ipfw: make algo name argument optional for some table types
Most of table types currently supported by ipfw have only one
algorithm implementation. When
: Andrey V. Elsukov
AuthorDate: 2021-02-25 13:57:47 +
Commit: Andrey V. Elsukov
CommitDate: 2021-03-04 09:21:28 +
ipfw: make algo name argument optional for some table types
Most of table types currently supported by ipfw have only one
algorithm implementation. When
: Andrey V. Elsukov
AuthorDate: 2021-02-25 13:57:47 +
Commit: Andrey V. Elsukov
CommitDate: 2021-03-04 09:19:31 +
ipfw: make algo name argument optional for some table types
Most of table types currently supported by ipfw have only one
algorithm implementation. When
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072
Andrey V. Elsukov changed:
What|Removed |Added
Assignee|i...@freebsd.org|a...@freebsd.org
--
You are r
: Andrey V. Elsukov
AuthorDate: 2021-02-25 13:57:47 +
Commit: Andrey V. Elsukov
CommitDate: 2021-02-25 13:57:47 +
ipfw: make algo name argument optional for some table types
Most of table types currently supported by ipfw have only one
algorithm implementation. When user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072
--- Comment #4 from Eugene Grosbein ---
(In reply to Andrey V. Elsukov from comment #3)
I've just tested it with my 11.4-STABLE/amd64 workstation. The patch works just
fine, please commit.
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233072
Alexander V. Chernikov changed:
What|Removed |Added
Assignee|melif...@freebsd.org|i...@freebsd.org
--
You
FINs, etc), the software would quickly establish an
> identical
> connection by re-using the same local port and connecting to the same
> remote
> end-point.
>
> That did not work well for the application :)
> We saw problems where packets from the second connection would be
-using the same local port and connecting to the same remote
end-point.
That did not work well for the application :)
We saw problems where packets from the second connection would be dropped by
ipfw. That happened because there would be no dynamic rule to let the packets
through even though the
30.11.2020 16:10, Eugene Grosbein wrote:
> Hi!
>
> It seems I'm facing a bug in NAT44 ipfw nat/libalias implementation.
>
> Suppose we have a LAN 192.168.0.0/24 and two WAN channels with public IP
> addresses
> and internal server 192.168.0.100 that serves connection
Hi!
It seems I'm facing a bug in NAT44 ipfw nat/libalias implementation.
Suppose we have a LAN 192.168.0.0/24 and two WAN channels with public IP
addresses
and internal server 192.168.0.100 that serves connection to the port 5060, both
TCP and UDP,
so we configure redirects:
nat 1 conf
Hi freebsd-hackers@, freebsd-net@,
Could someone please commit these two patches for ipfw/libalias/RFC6598:
URL: https://reviews.freebsd.org/D23356
Title: natd: Add support for RFC 6598/Carrier Grade NAT subnets via
libalias
Description:
Add support for RFC 6598/Carrier Grade NAT address
hi!
On Fri, 3 Jul 2020 at 20:12, Neel Chauhan wrote:
> Hi freebsd-hackers@, freebsd-net@,
>
> These two patches that will be described are a continuation of r357092.
>
> r357092 added support for RFC 6598/Carrier Grade NAT (subnet:
> 100.64.0.0/10) in libalias and IPFW in-ker
Hi freebsd-hackers@, freebsd-net@,
These two patches that will be described are a continuation of r357092.
r357092 added support for RFC 6598/Carrier Grade NAT (subnet:
100.64.0.0/10) in libalias and IPFW in-kernel NAT.
These two patches add support for RFC 6598 to natd and ng_nat
> Hi freebsd-net@,
>
> I'm really sorry if I'm bothering you with emails like this.
>
> If there are any committers here, I have two patches for the ipfw(8)
> subsystem.
>
> The patches (w/ description & URL) are:
>
> ===
> ipfw(8): In fill_ip6()
Hi freebsd-net@,
I'm really sorry if I'm bothering you with emails like this.
If there are any committers here, I have two patches for the ipfw(8)
subsystem.
The patches (w/ description & URL) are:
===
ipfw(8): In fill_ip6(), use a single statement for both "me" a
Hi freebsd-net@,
I'm not sure if this mailing list is the right place to ask for code
review. If not, could you please direct me to the right mailing list?
I have three patches for ipfw(8) below:
* https://reviews.freebsd.org/D24011 (ipfw: Support {w:x:y::z}:port
(bracketed) IPv6 addr
On Thu, 19 Mar 2020 14:33:34 +0300
Lev Serebryakov wrote:
> On 19.03.2020 7:14, Neel Chauhan wrote:
>
> > However, if you know, where in the code does libalias use only 4096
> > buckets? I want to know incase I want/have to switch back to IPFW.
> 4096 is my mistake, i
On 19.03.2020 7:14, Neel Chauhan wrote:
> However, if you know, where in the code does libalias use only 4096
> buckets? I want to know incase I want/have to switch back to IPFW.
4096 is my mistake, it is 4001 and must be prime. It is here:
sys/netinet/libalias/alias_local.h:69-70:
#
19.03.2020 18:19, Lev Serebryakov wrote:
>> Don't you think that now as ipfw nat builds libalias in kernel context,
>> it could scale with maxusers (sys/systm.h) ?
>>
>> Something like (4001 + (maxusers-32)*8) so it grows with amount of physical
>> memory
On 19.03.2020 9:42, Eugene Grosbein wrote:
>>> I’d expect both ipfw and pf to happily saturate gigabit links with NAT,
>>> even on quite modest hardware.
>>> Are you sure the NAT code is the bottleneck?
>> ipfw nat is very slow, really. There are many reasons,
19.03.2020 13:42, Eugene Grosbein wrote:
> It's really 4001 that is (and sould be) prime number.
If we decide to auto-tune this, here is small table of prime numbers to stick
with:
4001
8011
12011
16001
24001
32003
48017
64007
___
freebsd-net@freebsd
once with Tor.
>>>
>> I’d expect both ipfw and pf to happily saturate gigabit links with NAT, even
>> on quite modest hardware.
>> Are you sure the NAT code is the bottleneck?
> ipfw nat is very slow, really. There are many reasons, and one of them
> (easy f
Thanks for telling me this.
I switched to PF and it performs better.
However, if you know, where in the code does libalias use only 4096
buckets? I want to know incase I want/have to switch back to IPFW.
-Neel
On 2020-03-18 07:25, Lev Serebryakov wrote:
On 18.03.2020 9:17, Kristof Provost
On 18.03.2020 9:17, Kristof Provost wrote:
>> Which firewall gives better performance, IPFW's In-Kernel NAT or PF NAT? I
>> am dealing with 1000s of concurrent connections but browsing-level-bandwidth
>> at once with Tor.
>>
> I’d expect both ipfw and pf to hap
or Tor, Coronavirus-related telecommuting or not. My Tor server is
> separate from my firewall.
>
> Which firewall gives better performance, IPFW's In-Kernel NAT or PF NAT? I am
> dealing with 1000s of concurrent connections but browsing-level-bandwidth at
> once with Tor.
>
Hi freebsd-net@ mailing list,
Right now, my firewall is a HP T730 thin client (with a Dell Broadcom
5720 PCIe NIC) running FreeBSD 12.1 and IPFW's In-Kernel NAT. My ISP is
"Wave G" in the Seattle area, and I have the Gigabit plan.
Speedtests usually give me 700 Mbps down/900 Mbps up, and 250-
1 - 100 of 2258 matches
Mail list logo
