Am Mon, 17 Mar 2025 13:37:40 +0100 (CET)
Ronald Klop schrieb:
> Hi,
>
> When running 14.2-RELEASE VNET jails on 15-CURRENT ipfw does not work anymore
> in the jail.
>
> Can this commit be involved?
> https://cgit.freebsd.org/src/commit/?id=4a77657cbc01
>
> Copying
Hi,
When running 14.2-RELEASE VNET jails on 15-CURRENT ipfw does not work anymore
in the jail.
Can this commit be involved?
https://cgit.freebsd.org/src/commit/?id=4a77657cbc01
Copying the /sbin/ipfw binary from 15-CURRENT to /sbin in the 14.2 jail
resolves the issue for me.
Example errors
Hi Andrey,
With your patch applied I don't have the symptoms of 'hanging' tcp connections
anymore.
Thanks for looking into it.
Regards,
Ronald.
*Van:* "Andrey V. Elsukov"
*Datum:* donderdag, 12 december 2024 09:53
*Aan:* freebsd-current@freebsd.org
*Onderwerp:* R
0fc7bdc978) works fine.
I cc'ed the author of the commit.
(for context: start of the thread is here:
https://lists.freebsd.org/archives/freebsd-current/2024-December/006778.html, it looks like the commit breaks a statefull ipfw firewall)
Hi,
thanks for bisecting. I think this patch sho
gt;>
> >> My apology for topposting.
> >>
> >> The host I first realised the problems is updated on an almost daily basis
> >> and the issue
> >> reported started last weekend.
> >>
> >> A possible candidate could be
> >>
>
gt;>
> >> My apology for topposting.
> >>
> >> The host I first realised the problems is updated on an almost daily basis
> >> and the issue
> >> reported started last weekend.
> >>
> >> A possible candidate could be
> >
weekend.
A possible candidate could be
https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw?id=0fc7bdc978366abb4351b0b76b50a5848cc5d982
since the other, younger, seem innocent. I try to revert the patch mentioned
and see ...
Try to only revert the ip_fw_nat.c part at first.
—
Juraj Lutter
o
last weekend.
>
> A possible candidate could be
>
> https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw?id=0fc7bdc978366abb4351b0b76b50a5848cc5d982
>
> since the other, younger, seem innocent. I try to revert the patch mentioned
> and see ...
Try to only revert the ip_fw_nat.c part at first.
—
Juraj Lutter
o...@freebsd.org
>
> > > > Hi,
> > > >
> > > > I can reproduce your error.
> > > >
> > > > A cronjob which does a scp to another server didn't work anymore. When
> > > > I go back to the
> > > > previous BE it works fine aga
> > > A cronjob which does a scp to another server didn't work anymore. When I
> > > go back to the
> > > previous BE it works fine again. Ipfw disable firewall also makes the scp
> > > work.
> > >
> > > Scp also seems to work fine if I
On Mon, 9 Dec 2024 11:09:14 +0100
Juraj Lutter wrote:
> > On 8 Dec 2024, at 20:30, Ronald Klop wrote:
> >
> > Hi,
> >
> > I can reproduce your error.
> >
> > A cronjob which does a scp to another server didn't work anymore. When I go
> >
> On 8 Dec 2024, at 20:30, Ronald Klop wrote:
>
> Hi,
>
> I can reproduce your error.
>
> A cronjob which does a scp to another server didn't work anymore. When I go
> back to the previous BE it works fine again.
> Ipfw disable firewall also makes the scp w
/freebsd/obj/data/ronald/freebsd/src/main/arm64.aarch64/sys/GENERIC-NODEBUG
arm64
A cronjob which does a scp to another server didn't work anymore. When I go
back to the previous BE it works fine again.
Ipfw disable firewall also makes the scp work.
Scp also seems to work fine if I replac
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
> >
> >
> On Jan 8, 2024, at 1:50 AM, FreeBSD User wrote:
>
> 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 op
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,
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
Thanx very much
Цитирую "Alexander V. Chernikov" :
On 12 Sep 2021, at 11:51, Yuri Tcherkasov wrote:
ipfw nat 1 config ip XXX.XXX.XXX.xx reset unreg_only same_ports
Looks pretty close to https://reviews.freebsd.org/D23450
<https://reviews.freebsd.org/D23450>
I gues
> On 12 Sep 2021, at 11:51, Yuri Tcherkasov wrote:
>
> ipfw nat 1 config ip XXX.XXX.XXX.xx reset unreg_only same_ports
Looks pretty close to https://reviews.freebsd.org/D23450
<https://reviews.freebsd.org/D23450>
I guess rebuilding the ipfw(8) binary should help.
The command is
root@gw:/home/tyv # ipfw nat 1 config ip XXX.XXX.XXX.xx reset
unreg_only same_ports
ipfw nat 1 config ip 195.138.73.206 same_ports unreg_only reset
root@gw:/home/tyv #
Цитирую "Alexander V. Chernikov" :
On 12 Sep 2021, at 06:52, Yuri Tcherkasov wrote:
Hi
' in the loader.conf, there is no need to
recompile the kernel.
You can also set in runtime via sysctl.
options ROUTETABLES=2
and recompile it.
After normaly recompile can't configure ipfw nat with error
ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument
Could yo
' in the loader.conf, there is no need to
recompile the kernel.
You can also set in runtime via sysctl.
options ROUTETABLES=2
and recompile it.
After normaly recompile can't configure ipfw nat with error
ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument
Could yo
er.conf, there is no need to recompile the
kernel.
You can also set in runtime via sysctl.
>
> options ROUTETABLES=2
>
> and recompile it.
> After normaly recompile can't configure ipfw nat with error
>
> ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument
Coul
Hi
I'm binary upgrade FreeBSD from 10.2 to 13.0
After upgrate all workin well, but I need add one more routing table.
So add to
GENERIC kernel
options ROUTETABLES=2
and recompile it.
After normaly recompile can't configure ipfw nat with error
ipfw: setsockopt(IP_FW_NAT
After upgrading to r358858, CURRENT boxes secured by IPFW failed to handle
keyword "any" as source and destination and rc script fails to init the filter
correctly:
[...]
ipfw: bad destination address any
[...]
This renders any box running CURRENT and ipfw startig filter rules via
Got it, thanks!
Rodney W. Grimes 于2018年8月28日周二
下午9:40写道：
> > hi, I see the AMQ function is there but there is no usage info.
> > And find this review marked accepted:
> > Dummynet AQM usage documentation for ipfw man page ?
> > https://reviews.freebsd.org/D12507
>
&
> hi, I see the AMQ function is there but there is no usage info.
> And find this review marked accepted:
> Dummynet AQM usage documentation for ipfw man page ?
> https://reviews.freebsd.org/D12507
That review is accepted by manpages, it has not been
reviewed outside of that,
hi, I see the AMQ function is there but there is no usage info.
And find this review marked accepted:
Dummynet AQM usage documentation for ipfw man page ：
https://reviews.freebsd.org/D12507
___
freebsd-current@freebsd.org mailing list
https
On 13.07.2018 14:10, Lev Serebryakov wrote:
> when system is unresponsive I see this in `top -SH`
>
> 100083 root -76 - 0K 272K - 1 291.8H 95.31% kernel{if_io_tqg_1}
> 100082 root -76 - 0K 272K - 0 297.7H 95.20% kernel{if_io_tqg_0}
>
> And it is new to me.
Oh, this MoBo has
I have "SOHO" router on Atom D2500 with FreeBSD CURRENT. It runs
CURRENT for very long time (from 11-CURRENT times), and recently it
start to consume much more CPU on same traffic — to the point when it
becomes unresponsive in shell (via ssh, not local console).
I have rather co
On Tue, 9 Jan 2018 21:23:54 +0300
"Andrey V. Elsukov" wrote:
> On 09.01.2018 12:28, O. Hartmann wrote:
> > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is
> > also an example:
> >
> > ipfw add deny ip from any to any out recv ed0
> On 09.01.2018 12:28, O. Hartmann wrote:
> > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is
> > also an example:
> >
> > ipfw add deny ip from any to any out recv ed0 xmit ed1
> >
> > Can someone explain a bit mor
On 09.01.2018 12:28, O. Hartmann wrote:
> In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is
> also an example:
>
> ipfw add deny ip from any to any out recv ed0 xmit ed1
>
> Can someone explain a bit more what the semantics of these is? I get
> esp
I feel confused by the ipfw manpage, while trying to setup a set of filtering
rules on a small router project with in-kernel NAT.
It is a kind of hard based on the ipfw man page to figure out, what the meaning
is of the receive and xmit interface. Maybe it is only me that has problems,
but I
:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > trying to build a FreeBSD based router/PBX (Asterisk 13)
> > appliance, I
> > > > ran
> > > > > > into
> > > > > >
ter/PBX (Asterisk 13)
> appliance, I
> > > ran
> > > > > into
> > > > > several problems. My questions might have a "noobish" character,
> so my
> > > > > apology,
> > > > > my experiences with IPFW are not as thorough as the
On Tue, Sep 26, 2017 at 11:27 AM, Guido Falsi wrote:
> On 09/26/2017 10:35, O. Hartmann wrote:
>
> > of the RTP connection doesn't make it through IPFW/NAT. As often I
> search the
> > net, I always get informed this is a typical problem and solutions are
> > pr
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I
> > ran
> > > > into
> > > > several problems. My questions might have a "noobish" charact
his little box has only 1GB RAM as far as I know. Why should FreeBSD
> fail?
What do you mean by fail? Having said I don't have such hardware, does
asterisk crash on that hardware? Does calls get lost?
If the only problem that you mean by "fail" are NAT problems with the
me
might have a "noobish" character, so my
> > apology,
> > my experiences with IPFW are not as thorough as they should be.
> >
> > Before I'll got into medias res, aquestion about Pine64/AARCH64:
> >
> > - port net/asterisk13 is supposed to build only
router/PBX (Asterisk 13) appliance, I
> ran
> > > into
> > > several problems. My questions might have a "noobish" character, so my
> > > apology,
> > > my experiences with IPFW are not as thorough as they should be.
> > >
> > > Bef
uot; character, so my
> > apology, my experiences with IPFW are not as thorough as they should be.
> >
> > Before I'll got into medias res, aquestion about Pine64/AARCH64:
> >
> > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about
> > coming
Hello,
trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran into
several problems. My questions might have a "noobish" character, so my apology,
my experiences with IPFW are not as thorough as they should be.
Before I'll got into medias res, aquestion about
On 09/26/2017 10:35, O. Hartmann wrote:
> Hello,
>
> trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran into
> several problems. My questions might have a "noobish" character, so my
> apology,
> my experiences with IPFW are not as thorough as
On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann
wrote:
> Hello,
>
> trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran
> into
> several problems. My questions might have a "noobish" character, so my
> apology,
> my experiences with IPFW are no
Hello,
trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran into
several problems. My questions might have a "noobish" character, so my apology,
my experiences with IPFW are not as thorough as they should be.
Before I'll got into medias res, aquestion about
>>>>> On Aug 11, 2017, at 10:36, Bob Willcox wrote:
> >>>>>
> >>>>> When I rebuild my kernel on Jun 13th none of the previous ipfw kernel
> >>>>> modules were built:
> >>>>>
> >>>>> ip
t;>>> When I rebuild my kernel on Jun 13th none of the previous ipfw kernel
>>>>> modules were built:
>>>>>
>>>>> ipfw.ko
>>>>> ipfw_nat.ko
>>>>> ipfw_nat64.ko
>>>>> ipfw_nptv6.ko
>>>>
On Fri, Aug 11, 2017 at 12:21:49PM -0700, Mark Johnston wrote:
> On Fri, Aug 11, 2017 at 02:06:02PM -0500, Bob Willcox wrote:
> > > > On Aug 11, 2017, at 10:36, Bob Willcox wrote:
> > > >
> > > > When I rebuild my kernel on Jun 13th none of the previous
On Fri, Aug 11, 2017 at 02:06:02PM -0500, Bob Willcox wrote:
> > > On Aug 11, 2017, at 10:36, Bob Willcox wrote:
> > >
> > > When I rebuild my kernel on Jun 13th none of the previous ipfw kernel
> > > modules were built:
> > >
> &
On Fri, Aug 11, 2017 at 12:55:14PM -0600, Ngie Cooper wrote:
>
> > On Aug 11, 2017, at 10:36, Bob Willcox wrote:
> >
> > When I rebuild my kernel on Jun 13th none of the previous ipfw kernel
> > modules were built:
> >
> > ipfw.ko
> > ip
> On Aug 11, 2017, at 10:36, Bob Willcox wrote:
>
> When I rebuild my kernel on Jun 13th none of the previous ipfw kernel modules
> were built:
>
> ipfw.ko
> ipfw_nat.ko
> ipfw_nat64.ko
> ipfw_nptv6.ko
> ng_ipfw.ko
>
> and only this ipfw module was buil
When I rebuild my kernel on Jun 13th none of the previous ipfw kernel modules
were built:
ipfw.ko
ipfw_nat.ko
ipfw_nat64.ko
ipfw_nptv6.ko
ng_ipfw.ko
and only this ipfw module was built:
ng_ipfw.ko
However, the verson of /etc/rc.d/ipfw that I'm running (from the
freebsd-base-graphics b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am Thu, 29 Sep 2016 21:02:16 +0200
"O. Hartmann" schrieb:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Since a couple of months now, I use IPFW on several projects. I use IPFW
> again after a
> long t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Since a couple of months now, I use IPFW on several projects. I use IPFW again
after a
long term hiatus since ~ 2003. Before I used pf. The reasons are mannyfold and
one reason
is very dogmatic - it is the FreeBSD's native firewall and se
> it thinks is it’s ServerName. Don’t think NAT has anything to do with it.
>
> Daniel
>
> > On 29.09.2016 г., at 15:47, O. Hartmann wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> >
> > Despite other problems wit
;
> Despite other problems with IPFW and its documentation regarding NAT, I face
> a serious
> and disturbing problem.
>
> I run a NanoBSD based router/firewall project of my own, running CURRENT
> (FreeBSD
> 12.0-CURRENT #1 r306333: Mon Sep 26 08:36:02 CEST 2016). IPFW is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Despite other problems with IPFW and its documentation regarding NAT, I face a
serious
and disturbing problem.
I run a NanoBSD based router/firewall project of my own, running CURRENT
(FreeBSD
12.0-CURRENT #1 r306333: Mon Sep 26 08:36:02 CEST
Hi,
I have filed the PR in the subject [1], I'd like to ask if someone could
have a look, it's a bug I noticed on head which is also going to affect
11.0 if not corrected in time.
Since r270424, the output of certain ipfw show commands is mangled, due
to buffers not being cleaned be
While testing the new firewall functionality on head I stumbled in this:
root@sensei:~ [0]# ipfw table foo create type number
ipfw: Table creation failed: Operation not supported
root@sensei:~ [71]#
The ipfw man page states this should work, am I missing something?
--
Guido Falsi
; opt=, ro=, flags= optimized out>, im6o=0x0, ifpp=0x0, inp=)
> at /usr/src/sys/netinet6/ip6_output.c:1060
> #11 0x82661fd2 in dummynet_send (m=) at
> /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800
> #12 0x82661890 in dummynet_task (context=,
> pending=
/usr/src/sys/amd64/amd64/trap.c:442
> #9 0x80e97f91 in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:236
> #10 0x80c57ebc in ip6_output (m0=,
> opt=, ro=, flags= optimized out>, im6o=0x0, ifpp=0x0, inp=)
> at /usr/src/sys/netinet6/ip6_output.c:1060
> #11 0x
p6_output.c:1060
#11 0x82661fd2 in dummynet_send (m=) at
/usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800
#12 0x82661890 in dummynet_task (context=,
pending=) at
/usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:746
#13 0x80a9a1ac in taskqueue_run_loc
Am Sat, 21 May 2016 12:28:42 +0200
"O. Hartmann" schrieb:
> Am Fri, 20 May 2016 17:41:39 +0300
> "Andrey V. Elsukov" schrieb:
>
> > On 20.05.16 17:23, O. Hartmann wrote:
> > > The problem is simpel to trigger: have firewall type "WORKSTATION&q
Am Fri, 20 May 2016 17:41:39 +0300
"Andrey V. Elsukov" schrieb:
> On 20.05.16 17:23, O. Hartmann wrote:
> > The problem is simpel to trigger: have firewall type "WORKSTATION"
> > configured, IPFW
> > active (I have IPFW statically in-kernel-compile
Am Fri, 20 May 2016 17:41:39 +0300
"Andrey V. Elsukov" schrieb:
> On 20.05.16 17:23, O. Hartmann wrote:
> > The problem is simpel to trigger: have firewall type "WORKSTATION"
> > configured, IPFW
> > active (I have IPFW statically in-kernel-compile
Am Fri, 20 May 2016 17:59:17 +0300
"Andrey V. Elsukov" schrieb:
> On 20.05.16 17:23, O. Hartmann wrote:
> > I haven't checked so far whether the problem occurs also with non-SSL
> > connections
> > since all connections I see the suffering are somehow encrypted.
>
> Can you try to update up t
On 20.05.16 17:23, O. Hartmann wrote:
> I haven't checked so far whether the problem occurs also with non-SSL
> connections since
> all connections I see the suffering are somehow encrypted.
Can you try to update up to r300302?
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP dig
On 20.05.16 17:23, O. Hartmann wrote:
> The problem is simpel to trigger: have firewall type "WORKSTATION"
> configured, IPFW
> active (I have IPFW statically in-kernel-compiled, no modules so far). Have
> /usr/src as a
> svn+https repository and try a svn update of
wrote:
> >>>> I reported earlier about broken pipes in ssh sessions to remote hosts,
> >>>> which occur on an erratic basis. i'm investigating this problem now and
> >>>> it seems that it is also ipfw-related, but I'm not sure. This prob
, 2016, O. Hartmann wrote:
> >>>> I reported earlier about broken pipes in ssh sessions to remote hosts,
> >>>> which occur on an erratic basis. i'm investigating this problem now and
> >>>> it seems that it is also ipfw-related, but I
on an erratic basis. i'm investigating this problem now and
> >> it seems that it is also ipfw-related, but I'm not sure. This problem
> >> is present since a couple of weeks now.
> >
> > Maybe this could help...
> >
> > I've also
x27;m investigating this problem now and
it seems that it is also ipfw-related, but I'm not sure. This problem
is present since a couple of weeks now.
Maybe this could help...
I've also experienced problems with broken pipes in ssh sessions some
time ago. Setting
sis. i'm investigating this problem now and
> >> it seems that it is also ipfw-related, but I'm not sure. This problem
> >> is present since a couple of weeks now.
> >
> > Maybe this could help...
> >
> > I've also
On 20/05/16 14:54, Vladimir Zakharov wrote:
Hello
On Fri, May 20, 2016, O. Hartmann wrote:
I reported earlier about broken pipes in ssh sessions to remote hosts,
which occur on an erratic basis. i'm investigating this problem now and
it seems that it is also ipfw-related, but I'
Hello
On Fri, May 20, 2016, O. Hartmann wrote:
> I reported earlier about broken pipes in ssh sessions to remote hosts,
> which occur on an erratic basis. i'm investigating this problem now and
> it seems that it is also ipfw-related, but I'm not sure. This problem
> is pre
With most recent CURRENT (r300295) I face a very strange behaviour on
all systems running CURRENT with IPFW enabled.
I realize massive network problems, especially when services like
claws-mail, pgadmin3, OpenLDAP clients, drill or even svn try to
connect to their servers. In most cases, the
On Tue, Nov 3, 2015, at 21:29, David Wolfskill wrote:
> On Tue, Nov 03, 2015 at 09:08:28PM -0600, Mark Felder wrote:
> > Recent ipfw commits now cause my firewall to panic on boot. I had to
> > revert them and only pull in Adrian's ath fix which was to fix yet a
>
On Tue, Nov 03, 2015 at 09:08:28PM -0600, Mark Felder wrote:
> Recent ipfw commits now cause my firewall to panic on boot. I had to
> revert them and only pull in Adrian's ath fix which was to fix yet a
> different panic I was encountering... :-)
>
> KDB: stack backtrace:
>
Recent ipfw commits now cause my firewall to panic on boot. I had to
revert them and only pull in Adrian's ath fix which was to fix yet a
different panic I was encountering... :-)
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe01226a33e0
vpanic
firewall?
if not then you should start by adding two rules.
ipfw add 350 allow ip from any to any in recv {LAN interface}
ipfw add 351 allow ip from any to any out xmit {LAN interface}
as you do not want to block that traffic..
you should only be looking at traffic on the internet interface..
In your
On 8/24/15 9:05 PM, Petr Chocholáč wrote:
Hello,
I would like to ask you for advice. I can not connect to
imap.gmail.com on port 993 from my local network. My LAN is behind
freeBSD server with IPFW. Server has two network cards rl0=Internet
and re0=LAN(10.0.0.0/16). Tcpdump on re0 shows
Hello,
I would like to ask you for advice. I can not connect to imap.gmail.com
on port 993 from my local network. My LAN is behind freeBSD server with
IPFW. Server has two network cards rl0=Internet and
re0=LAN(10.0.0.0/16). Tcpdump on re0 shows three SYN packets without
answers. What rules should i
On 2015-08-24 09:05, Petr Chocholáč wrote:
> Hello,
>
> I would like to ask you for advice. I can not connect to imap.gmail.com
> on port 993 from my local network. My LAN is behind freeBSD server with
> IPFW. Server has two network cards rl0=Internet and
> re0=LAN(10.0.0.0/1
Hello,
I would like to ask you for advice. I can not connect to imap.gmail.com
on port 993 from my local network. My LAN is behind freeBSD server with
IPFW. Server has two network cards rl0=Internet and
re0=LAN(10.0.0.0/16). Tcpdump on re0 shows three SYN packets without
answers. What rules
"O. Hartmann" wrote
in <20141020052804.7a5e1d50.ohart...@zedat.fu-berlin.de>:
oh> Having simply a number (the port) in rc.conf: firewall_myservices defined,
I receive
oh> during startup the message
oh>
oh> Consider using tcp/31982 in firewall_myservices.
oh>
oh> Doing so, ends up in a misconfi
Having simply a number (the port) in rc.conf: firewall_myservices defined, I
receive
during startup the message
Consider using tcp/31982 in firewall_myservices.
Doing so, ends up in a misconfiguration, because the rc.firewall script in
/etc/ is
looking for 31982/tcp instead of the recommended
On Sat, Oct 11, 2014 at 07:05:12PM +0400, Alexander V. Chernikov wrote:
> ...
> Whoops. My bad.
> It should be fixed in r272940.
> ...
Confirmed: I'm not running:
FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1393
r272938M/272938:1100037: Sat Oct 11 08:45:34 PDT 2014
root@localhost:
On 11.10.2014 18:15, David Wolfskill wrote:
On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote:
Hi,
I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
OK; I was able to build & install head @r272938 this morning on my
laptop; on rebo
On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote:
> Hi,
>
> I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
>
OK; I was able to build & install head @r272938 this morning on my
laptop; on reboot, I was greeted by a p
On 04 Oct 2014, at 16:35, Alexander V. Chernikov wrote:
> Hi,
>
> I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
Merged in r 272840.
>
> What has changed:
>
> Main user-visible changes are related to tables:
>
> * Tables are now
Hey Alexander,
Very nice work, thank you so much to bring these stuff to us.
Best Regards,
2014-10-04 20:35 GMT+08:00 Alexander V. Chernikov :
> Hi,
>
> I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
>
> What has changed:
>
> Main user-v
On 10/4/14 20:35, Alexander V. Chernikov wrote:
Hi,
I'm going to merge projects/ipfw branch to HEAD in the middle of next
week.
What has changed:
Main user-visible changes are related to tables:
* Tables are now identified by names, not numbers. There can be up to
65k tables with up
Hi,
I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
What has changed:
Main user-visible changes are related to tables:
* Tables are now identified by names, not numbers. There can be up to
65k tables with up to 63-byte long names.
* Tables are now set-
On Tue, May 06, 2014 at 06:26:28PM +0200, O. Hartmann wrote:
O> A while ago some performance graphs were floating around here showing the net
O> performance of ipfw and pf. pf was, as far as I can remember, the single
threaded
O> version. Are there more recent performance benchmarks
On 2014-05-06 12:26, O. Hartmann wrote:
>
> A while ago some performance graphs were floating around here showing the net
> performance of ipfw and pf. pf was, as far as I can remember, the single
> threaded
> version. Are there more recent performance benchmarks available? E
A while ago some performance graphs were floating around here showing the net
performance of ipfw and pf. pf was, as far as I can remember, the single
threaded
version. Are there more recent performance benchmarks available? Even if pf in
FreeBSD is
still behind pf in recent OpenBSD, FreeBSD
On Fri, 07 Mar 2014 17:51:11 -0500
Allan Jude wrote:
> On 2014-03-07 16:55, O. Hartmann wrote:
> > On Fri, 07 Mar 2014 15:33:39 -0500
> > Allan Jude wrote:
> >
> >> On 2014-03-07 13:57, O. Hartmann wrote:
> >>>
> >>> Recently I s
1 - 100 of 373 matches
Mail list logo
