Hi!
Is there any limit for open NAT connections?
If it is where it can be set/change?
Thanks,
-pal
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Does anyone know of a tutorial or more detailed instructions on how to use
NAT and IP masquerading in 3.4? I can configure it so that it is running
and working with IP firewall within the box no problem, but as far as
dolling out local IPs to the rest of the workstations or even building a
Did anyone make any kind of benchmarking on the NAT?
I am interested in number of connections per hour / total simultaneous
connections and any other perfomance related experience you may have had with it?
Any1?
--Ugen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe fr
achines at work. However, then I don't have access to some
servers, because I come from a foreign (and dynamic) ip-adress.
So I install pptpd on a machine at work to make a tunnel and get a
"trusted" ip-adress.
Questions: man ppp, topic nat pptp suggest, that only one machine behind
Hi Jason,
This is really a -questions question, not a -current question.
On Wed, 26 Apr 2000, Jason Mitchell wrote:
> Does anyone know of a tutorial or more detailed instructions on how to use
> NAT and IP masquerading in 3.4?
"IP masquerading" is what the linux people call N
> Did anyone make any kind of benchmarking on the NAT?
> I am interested in number of connections per hour / total simultaneous
> connections and any other perfomance related experience you may have had
> with it?
if you intend to work on this, for measurement criteria, you may wan
Hello to all,
For the first time I compile current-p3 -> current-p4 with
-march=pentium2 -O2 -mmmx -pipe and aparently everything works ok
except ppp -nat. NAT just don't work on my network. All machines are
able to ping except ftp, http, etc.
I rebuild everything with no CPUTYPE? an
I just upgrade one of my server to -current. that server connect to ADSL
and act as a gateway.
however, after I upgrade that server to -current, all other clients
(all windows 98) start acting really strange. clients was unable to
connect to more then 60% of web sites. for example, clients can
On Wed, Mar 05, 2003 at 10:00:20PM +, Nuno Teixeira wrote:
> I rebuild everything with no CPUTYPE? and CFLAGS and ppp -nat is working
> again.
>
> I know that this isn't a important issue or bug because there are lots
> of warnings about gcc optimizations because t
On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote:
> For the first time I compile current-p3 -> current-p4 with
> -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok
> except ppp -nat. NAT just don't work on my network. All machines are
> able to ping except ft
On Thu, Mar 06, 2003 at 09:22:06PM +0800, Khairil Yusof wrote:
> On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote:
>
> > For the first time I compile current-p3 -> current-p4 with
> > -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok
> > except ppp -nat
-mmmx -pipe and aparently everything works ok
> > > except ppp -nat. NAT just don't work on my network. All machines are
> > > able to ping except ftp, http, etc.
> >
> > I can confirm this. nat fails to work with -O2 for usr.sbin/ppp. It
> > compiles cleanl
For the first time I compile current-p3 -> current-p4 with
> > > > -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok
> > > > except ppp -nat. NAT just don't work on my network. All machines are
> > > > able to ping except ftp, http, et
from
192.168.7.0/24 to the rest of the world. The various epairs get added to
bridge1 and assigned to each jail. Pretty simple setup. That worked until
today. When I do tcpdump on my public-facing NIC, I see that NAT isn't
applied. When I run `ping 8.8.8.8` from the jail, the jail's 192.1
On Sat, Oct 21, 2000 at 11:08:28PM +1000, Idea Receiver wrote:
>
> I just upgrade one of my server to -current. that server connect to ADSL
> and act as a gateway.
>
> however, after I upgrade that server to -current, all other clients
> (all windows 98) start acting really strange. clients was
thx. that fix my problem ;)
the other problem i had after switch that system to -current
is that after a random time, the connection will frzzed.
the routing table still exist, connection is still up.
just cant connect to anywhere outside the network. no error
or anything been loged in ppp.log.
> the other problem i had after switch that system to -current
> is that after a random time, the connection will frzzed.
> the routing table still exist, connection is still up.
> just cant connect to anywhere outside the network. no error
> or anything been loged in ppp.log.
Interestingly enoug
On Wed, 25 Oct 2000, Josh Tiefenbach wrote:
> Interestingly enough, I've been having the same problem with PPPoE ever since
> it hit the tree 'bout a year ago. It happens infrequently enough that I tend
> to blame my provider, rather than ppp.
>
> When it happens, killing ppp and restarting it
> > When it happens, killing ppp and restarting it is usually enough.
> >
> > I have no idea what causes it.
> >
>
> kill ppp and restart it doesnt help at all.
> will it make any different if i change a network card?
I dont think so. There are times when I cant do a simple kill/restart, and
> > the other problem i had after switch that system to -current
> > is that after a random time, the connection will frzzed.
> > the routing table still exist, connection is still up.
> > just cant connect to anywhere outside the network. no error
> > or anything been loged in ppp.log.
>
> Inter
> BTW: I believe PPPoE in both Julian and Archie's cases specifically
> uses the netgraph PPP implementation, so it's an "all in the
> kernel" approach; the problem may be your use of user space code
> (i.e. killable code, since you can't kill it in the kernel, only
> unlink or unload it).
Actual
> > BTW: I believe PPPoE in both Julian and Archie's cases specifically
> > uses the netgraph PPP implementation, so it's an "all in the
> > kernel" approach; the problem may be your use of user space code
> > (i.e. killable code, since you can't kill it in the kernel, only
> > unlink or unload it
92.168.7.1. The host simply NATs outbound from
192.168.7.0/24 to the rest of the world. The various epairs get added to
bridge1 and assigned to each jail. Pretty simple setup. That worked until
today. When I do tcpdump on my public-facing NIC, I see that NAT isn't
applied. When I run `ping 8.
imple setup. That worked until
> > today. When I do tcpdump on my public-facing NIC, I see that NAT isn't
> > applied. When I run `ping 8.8.8.8` from the jail, the jail's
> > 192.168.7.0/24
> > address gets sent on the wire.
> >
> > Let me know what I can
he various epairs get added to
>>> bridge1 and assigned to each jail. Pretty simple setup. That worked until
>>> today. When I do tcpdump on my public-facing NIC, I see that NAT isn't
>>> applied. When I run `ping 8.8.8.8` from the jail, the jail's
>>> 192
; >>> their default route to 192.168.7.1. The host simply NATs outbound from
> >>> 192.168.7.0/24 to the rest of the world. The various epairs get added to
> >>> bridge1 and assigned to each jail. Pretty simple setup. That worked
> >>> until
> >&g
ed my machine and things still seem to be working.
As you said, it’s probably related to the multiple nat entries.
I’ll have to make a test setup, which’ll take a bit of time, especially
since I’m messing with the host machine at the moment.
Regards,
Kristof
__
ify NATing like that and pf would automatically figure out which
> > outgoing device to use. Seems like that's broken now.
>
> I’ve updated my machine and things still seem to be working.
> As you said, it’s probably related to the multiple nat entries.
>
> I’ll have to mak
> On 05 Nov 2015, at 17:25, Shawn Webb wrote:
> I've figured it out. I've removed all rules and went with a barebones config.
>
> Right now, the laptop I'm using for NAT has an outbound interface of wlan0
> with an IP of 129.6.251.181 (from DHCP). The following
On Thursday, 05 November 2015 11:45:25 PM Kristof Provost wrote:
> > On 05 Nov 2015, at 17:25, Shawn Webb wrote:
> > I've figured it out. I've removed all rules and went with a barebones
> > config.
> >
> > Right now, the laptop I'm using for NAT has
On Mon, Nov 09, 2015 at 08:18:32AM -0500, Shawn Webb wrote:
> I'm using iocage for jailing.
>
> It's now looking like pf is back to being broken for me. I've tried every
> combination possible, even hardcoding the values:
>
> nat on wlan0 from {192.1
On 2015-11-09 21:47:01 (-0500), Shawn Webb wrote:
> I found the problem: it seems that the new Intel Haswell graphics
> support (which I've been running with) is at odds somehow with pf NAT.
> Removing Haswell graphics support means working pf NAT.
>
That's ... very strang
On Tue, Nov 10, 2015 at 1:28 PM, Kristof Provost wrote:
> On 2015-11-09 21:47:01 (-0500), Shawn Webb wrote:
>> I found the problem: it seems that the new Intel Haswell graphics
>> support (which I've been running with) is at odds somehow with pf NAT.
>> Removing Hasw
(which I've been running with) is at odds somehow with pf NAT.
> >> Removing Haswell graphics support means working pf NAT.
> >>
> > That's ... very strange.
> >
> > I've built the drm-i915-update-38 branch of
> > http:github.com/freebsd
Hi,
There's trouble in the /etc/rc.d/ipfw script in how it changes things
versus the 4.7 /etc/rc.network script when it comes to NAT in certain
configurations.
For example, on my home gateway box, rc.conf contains:
# Network address translation:
natd_enable="YES"
stay with IPFW).
I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet IPv6.
The FreeBSD system acting as a router is supposed to have a jail soon
containing the Asterisk 13 IP PBX (at the moment running on the main system).
To provide access to the VoIP infrastructure insi
stay with IPFW).
I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet IPv6.
The FreeBSD system acting as a router is supposed to have a jail soon
containing the Asterisk 13 IP PBX (at the moment running on the main system).
To provide access to the VoIP infrastructure insi
-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
Hello,
i recently switched a router in our test-environment to FreeBSD 9.0-Beta3
(and after things didnt worked ... checked out the current RELENG_9
and recompiled kernel & world .. )
Problem:
After 5 - 15 minutes NAT stops working (normal routing still works.)
Network Utilization: a
On Thu, 6 Mar 2003, Bruce Cran wrote:
> 387 (FPU) code generation seems to be broken in gcc 3.2.1 when -O2 is used.
Would you happen to know if this is still broken in 3.2.2?
> I can compile applications with no problems when -mfpmath=sse is added so
> that the 387 unit won't be used, but witho
Mark Murray wrote:
> > How long can this remain unfixed before the code is diked out,
> > and the checksum is recalculated fully, instead?
>
> Terry, you sound rather foolish when you argue like this. This
> is semantic tomfoolery and off topic. End of thread.
This is not a argument over mere imp
atform
> (assumed
> having 2 GB of RAM)?
>
> My main concern is about IPFW (we do not use PF for some reasons, I have to
> stay with IPFW).
>
> I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet
> IPv6.
> The FreeBSD system acting as a rou
aving audio for a bunch of calls can be quite heavy on disk resources
AND could require additional transcoding.
>
> My main concern is about IPFW (we do not use PF for some reasons, I have to
> stay with IPFW).
>
> I'm a customer of two ITSPs and my SoHo network is behind NAT and no
has only 1GB RAM as far as I know. Why should FreeBSD fail?
>
> >
> > My main concern is about IPFW (we do not use PF for some reasons, I have to
> > stay with IPFW).
> >
> > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet
> > IP
X platform
> > > (assumed
> > > having 2 GB of RAM)?
> > >
> > > My main concern is about IPFW (we do not use PF for some reasons, I
> have to
> > > stay with IPFW).
> > >
> > > I'm a customer of two ITSPs and my SoHo network is be
on armv6, is aarch64 about
> > coming soon also supported?
> > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform
> > (assumed
> > having 2 GB of RAM)?
> >
> > My main concern is about IPFW (we do not use PF for some reasons, I have to
&g
otocol audio format but most important for us IP:port.
After negotiation each party performs the connection to the other. Let
me rephrase: Your asterisk will be telling your provider to which
IP:port is should send it's UDP connection for the audio stream, so you
can't control where you are conn
sed to build only on armv6, is aarch64
> > about
> > > > coming soon also supported?
> > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform
> > > > (assumed
> > > > having 2 GB of RAM)?
> > > >
>
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
t; coming soon also supported?
> > > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX
> platform
> > > > > (assumed
> > > > > having 2 GB of RAM)?
> > > > >
> > > > > My main concern is about IPFW (we do
ll got into medias res, aquestion about Pine64/AARCH64:
> > > > > >
> > > > > > - port net/asterisk13 is supposed to build only on armv6, is
> > aarch64
> > > > about
> > > > > > coming soon also supported?
> > &g
It looks like your httpd server is doing a redirect to your internal IP
address, which 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
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am Thu, 29 Sep 2016 16:00:10 +0300
Daniel Kalchev schrieb:
Yes, your are right :-)
Yes, I'm wrong, it is not NAT :-(
Thanks a lot,
Oliver
> It looks like your httpd server is doing a redirect to your internal IP
> address, which
On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote:
> Hello,
>
> i recently switched a router in our test-environment to FreeBSD 9.0-Beta3
> (and after things didnt worked ... checked out the current RELENG_9
> and recompiled kernel & world .. )
freebsd-pf archives might be a good start and th
On Tue, Oct 18, 2011 at 6:16 PM, Bjoern A. Zeeb
wrote:
> On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote:
>
>> Hello,
>>
>> i recently switched a router in our test-environment to FreeBSD 9.0-Beta3
>> (and after things didnt worked ... checked out the current RELENG_9
>> and recompiled kernel
Florian Wilkemeyer wrote:
> On Tue, Oct 18, 2011 at 6:16 PM, Bjoern A. Zeeb
> wrote:
> > On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote:
> >
> >> Hello,
> >>
> >> i recently switched a router in our test-environment to FreeBSD 9.0-Beta=
> 3
> >> (and after things didnt worked ... checked out
that the vnet jails external network is configured correctly.
Can not ping 8.8.8.8 from the vnet jails console. I can see the pf rules
are loaded. But the pf log shows no traffic at all.
Think problem is with the nat rule syntax or the nat function of pf is
non-functional. Can not reach the
Hi,
There's apparently a bug in VMware Workstation NAT implementation, made
visible by the change to default values of IPQoS in OpenSSH 7.8p1,
making all ssh connections from the guest behind the NAT to fail with
obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22:
B
> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote:
>
> Hi,
>
> There's apparently a bug in VMware Workstation NAT implementation, made
> visible by the change to default values of IPQoS in OpenSSH 7.8p1,
> making all ssh connections from the guest behind the
I've been hit by this as well. At least two others on IRC have had the same
issue.
Warner
On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote:
>
> > On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote:
> >
> > Hi,
> >
> > There's apparently a bug in
wrote:
> I've been hit by this as well. At least two others on IRC have had the
> same issue.
>
> Warner
>
> On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote:
>
>>
>> > On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote:
>> >
>> > Hi,
&
018 at 5:10 PM Enji Cooper wrote:
>>
>>>
>>>> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote:
>>>>
>>>> Hi,
>>>>
>>>> There's apparently a bug in VMware Workstation NAT implementation, made
>>>>
> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
>
> Mark Peek wrote:
>> Thanks for the cc:. I forwarded the original report on to an internal
>> VMware desktop product contact.
>
> Thank you.
>
>> What version of Workstation or Fusion is this occurring on? I saw
>> Workstation 14 mentioned but
On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote:
>
> > On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
> >
> > Mark Peek wrote:
> >> Thanks for the cc:. I forwarded the original report on to an internal
> >> VMware desktop product contact.
> >
> > Thank you.
> >
> >> What version of Workstation
Mark Peek wrote:
> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote:
>
>>
>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
>>>
>>> Mark Peek wrote:
Thanks for the cc:. I forwarded the original report on to an internal
VMware desktop product contact.
>>>
>>> Thank you.
>>>
What v
On Sat, Dec 22, 2018, 11:03 AM Yuri Pankov Mark Peek wrote:
> > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper
> wrote:
> >
> >>
> >>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
> >>>
> >>> Mark Peek wrote:
> Thanks for the cc:. I forwarded the original report on to an internal
> VMwar
In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri
Pankov write
s:
> Yuri Pankov wrote:
>> In-Reply-To: > com>
>> Mark Peek wrote:
>> > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper
wro=
>> te:
>> >=20
>> >>
>> >>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
>> >>>
>> >>> Mark
Cy Schubert wrote:
> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri
> Pankov write
> s:
>> Yuri Pankov wrote:
>>> In-Reply-To: l.gmail.
>>> com>
>>> Mark Peek wrote:
On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper
> wro=
>>> te:
=20
>
>> On Dec 21, 2018, at 17
> To: Cy Schubert
> Cc: Mark Peek , Enji Cooper ,
> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?=
> , freebsd-current
> Message-ID:
> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1
> changes
> References: <20181009.wbmk9h5t050.
ed-headers="v1"
>> From: Yuri Pankov
>> To: Cy Schubert
>> Cc: Mark Peek , Enji Cooper ,
>> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?=
>> , freebsd-current
>> Message-ID:
>> Subject: Re: workaround for VMware WS NAT bug triggered by
rotected-headers="v1"
> From: Yuri Pankov
> To: Cy Schubert
> Cc: Mark Peek , Enji Cooper ,
> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?=
> , freebsd-current
> Message-ID: <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net>
> Subject: Re: workaround for VMw
> On Dec 22, 2018, at 1:03 PM, Cy Schubert wrote:
…
> Regarding the Red Hat bugzilla bug, looks like they're doing the right
> thing by reaching out to VMware. This should be our position as well.
> Add it to ssh_config or sshd_config if one must but have VMware fix
> their bugs. Putting workar
In message <82004750-097a-47e5-9981-86b4b7a5f...@gmail.com>, Enji
Cooper writes
:
> > On Dec 22, 2018, at 1:03 PM, Cy Schubert =
> wrote:
>
> =E2=80=A6
>
> > Regarding the Red Hat bugzilla bug, looks like they're doing the right
> > thing by reaching out to VMware. This should be our position as
In message <861s681ypd@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg
rav?= w
rites:
> Cy Schubert writes:
> > Add it to ssh_config or sshd_config if one must but have VMware fix
> > their bugs. Putting workarounds in our O/S to work around a bug in some
> > other vendor's virtualization is s
Cy Schubert writes:
> Add it to ssh_config or sshd_config if one must but have VMware fix
> their bugs. Putting workarounds in our O/S to work around a bug in some
> other vendor's virtualization is something I don't support.
It's something we do *all the time*. Otherwise we'd just be a toy OS
In message <86pntszlae@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg
rav?= w
rites:
> Cy Schubert writes:
> > Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then.
>
> I don't speak for them, but I assure you that both their code and ours
> are full of workarounds for bugs in third-par
Cy Schubert writes:
> I know our code is full of workarounds and theirs probably too. The
> question is should we? IMO no.
Unfortunately, the world is imperfect and does not care about your
opinion. 90% of the hardware we run on deviates from the spec in some
way or another and requires workaro
Cy Schubert writes:
> Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then.
I don't speak for them, but I assure you that both their code and ours
are full of workarounds for bugs in third-party software and hardware,
and it is ridiculous to claim otherwise.
> No. We do like Red Hat does
Yuri Pankov writes:
> There's apparently a bug in VMware Workstation NAT implementation,
> [...] The patch itself is attached.
Could you please open a differential and add me as reviewer?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
free
In message <865zvkpphn@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg
rav?= w
rites:
> Cy Schubert writes:
> > I know our code is full of workarounds and theirs probably too. The
> > question is should we? IMO no.
>
> Unfortunately, the world is imperfect and does not care about your
> opinion
Dag-Erling Smørgrav wrote:
> Yuri Pankov writes:
>> There's apparently a bug in VMware Workstation NAT implementation,
>> [...] The patch itself is attached.
>
> Could you please open a differential and add me as reviewer?
https://reviews.freebsd.org/D18636
And the
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 complex ipfw rules
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
Is there any chance of getting the fix suggested in PR-47024 in 5.0
before release? Looks like a similar script bug with natd start-up was
fixed in 4.x-STABLE back in Feb. of 2002 -- See the CVS logs for
/etc/rc.network, in particular, cjc's log entries for revision 1.124
(MAIN) and revision 1
84 matches
Mail list logo
