Hello,
I have reported bug 209491 (Broadcast storm with ipfw+natd+gateway)
for -CURRENT, but now it is also in 11-STABLE. It is still here, as
I have tested it today with src r305790 (11.0-PRERELEASE).
So please be warned. If you are using similar configuration as me
with ipfw+natd+gateway, you
On 21. Dec 2011, at 02:23 , Doug Barton wrote:
> On 12/20/2011 02:01, Claude Buisson wrote:
>> Hi,
>>
>> It seems (from my own csup's and cvswe.cgi) that the src commits are lost,
>> starting with r228697 Sun Dec 18 22:04:55 2011)
>
> Yeah, my warning 2 days ago that this was going to happen se
On 12/20/2011 02:01, Claude Buisson wrote:
> Hi,
>
> It seems (from my own csup's and cvswe.cgi) that the src commits are lost,
> starting with r228697 Sun Dec 18 22:04:55 2011)
Yeah, my warning 2 days ago that this was going to happen seems to have
gone un-heeded. :) I'm sure you can take bz' w
On 20. Dec 2011, at 10:01 , Claude Buisson wrote:
> It seems (from my own csup's and cvswe.cgi) that the src commits are lost,
> starting with r228697 Sun Dec 18 22:04:55 2011)
>
> What is going on (or off) ?
Re $subject -- yes. It will be worked on.
--
Bjoern A. Zeeb
Hi,
It seems (from my own csup's and cvswe.cgi) that the src commits are lost,
starting with r228697 Sun Dec 18 22:04:55 2011)
What is going on (or off) ?
Claude Buisson
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
Hi,
* area damai™ <[EMAIL PROTECTED]> [071202 21:42]:
> whenever i run /etc/rc.d/netif it will read rc.conf and add the pc IP and
> netmask but it wont read the default gateway resulting lost connectivity to
> internet
> # -- my /etc/rc.conf :
> defaultrouter="192.16
hi!
whenever i run /etc/rc.d/netif it will read rc.conf and add the pc IP and
netmask but it wont read the default gateway resulting lost connectivity to
internet
# -- my /etc/rc.conf :
defaultrouter="192.168.1.1"
hostname="msc.edu"
ifconfig_rl0="inet 192.168.
> You might be better off running ntpd on the firewall and having
> the inside hosts sync to it.
That would be nice - except my problem is that the firewal is the only
one on which ntp *doest* run! :-)
Thanks for all the other suggestions - will take a look a them later today
and see if I can tra
On 2007-Jul-25 10:30:25 +1000, Andrew Reilly <[EMAIL PROTECTED]> wrote:
>On Wed, Jul 25, 2007 at 05:24:25AM +1000, Peter Jeremy wrote:
>> On 2007-Jul-24 16:00:08 +0100, Pete French <[EMAIL PROTECTED]> wrote:
>> Yes it does. The major difference is that ntpd will use a source
>> port of 123 whilst
ts behind a nat firewall
> will be competing for the same ip quadtuple at the NAT box.
Usually the clients behind the NAT gateway use the ntpd
running on the gateway itself, not any servers beyond.
So NTP queries never have to be forwarded across the
gateway, so they're not subject to NAT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Andrew Reilly wrote:
> On Wed, Jul 25, 2007 at 05:24:25AM +1000, Peter Jeremy wrote:
>> On 2007-Jul-24 16:00:08 +0100, Pete French <[EMAIL PROTECTED]> wrote:
>> Yes it does. The major difference is that ntpd will use a source
>> port of 123 whilst n
On Wed, Jul 25, 2007 at 05:24:25AM +1000, Peter Jeremy wrote:
> On 2007-Jul-24 16:00:08 +0100, Pete French <[EMAIL PROTECTED]> wrote:
> Yes it does. The major difference is that ntpd will use a source
> port of 123 whilst ntpdate will use a dynamic source port.
Is that behaviour that can be defea
On 2007-Jul-24 16:00:08 +0100, Pete French <[EMAIL PROTECTED]> wrote:
>at least I cannot see anything wrong). I would assume that ntpdate
>also uses UDP - and using that I can see all these servers ?
Yes it does. The major difference is that ntpd will use a source
port of 123 whilst ntpdate will
Hi, all!
On Tue, Jul 24, 2007 at 04:00:08PM +0100, Pete French wrote:
> Yes, I discovered the UDPness of it last night and went
> through the rules again. I am pretty sure they are correct (or
> at least I cannot see anything wrong). I would assume that ntpdate
> also uses UDP - and using that I
ere I guess, just hard to work out where.
> I'm running ntpd on a NAT gateway myself (RELENG_6), and
> there are no problems at all.
yes, I too am doing this on a machine elsewhere, which is why this is
so frustrating! I know it works, I even have it working on a different
network, a
Do you have a dynamically assigned IP
address? In that case ntpd needs to be restarted when a
new address is assigned, because ntpd has the unfortunate
habit to bind to all addresses that exist at the time it
is started.
I'm running ntpd on a NAT gateway myself (RELENG_6), and
there are no
> Well it could just as easily be the associated reboot, but one hesitates to
> suggest that on a *nix list :)
Well, I updated to this mornings -STABLE and I still get the same effect.
Somewhat puzzled, and I not sure where to go from here - especially as
making the queries with 'ntpdate' works f
On Monday 23 July 2007 20:22:22 Pete French wrote:
> > It's deja-vu all over again.
> >
> > I found my works NTP service was broken on Friday, just after I started
> > my holiday.
>
> Interesting to hear from someone also using NAt with a very similar
> problem. Thanks, I am running -STABLE rather
> It's deja-vu all over again.
>
> I found my works NTP service was broken on Friday, just after I started my
> holiday.
Interesting to hear from someone also using NAt with a very similar
problem. Thanks, I am running -STABLE rather than RELENG, but I suspect
I will simply try updating to a late
same config as a number of other machines, all of which work.
>
> We have a segment of network which is behind a NAT, and there is a BSD box
> running 'pf' actiing as the NAT gateway. Running ntpd on the actual
> NAT box does not work, but running it on the clients the far sid
a segment of network which is behind a NAT, and there is a BSD box
running 'pf' actiing as the NAT gateway. Running ntpd on the actual
NAT box does not work, but running it on the clients the far side of
the NAT does, or on clients the live side of the NAT. I should probably
exolain th
On Aug 19, 2006, at 10:58 PM, SigmaX asdf wrote:
Found my problem. T[h]e firewall_type option is case sensitive --
and "OPEN"
is supposed to be lowercase.
The firewall_type option isn't case-sensitive, and hasn't been since
early 4.x; see /etc/rc.firewall:
case ${firewall_type} in
[Oo][P
SigmaX asdf wrote:
> For the archives:
>
> Found my problem. Te firewall_type option is case sensitive -- and "OPEN"
> is supposed to be lowercase.
I would find that very surprising, given that as far as I can see,
everywhere that the firewall_type variable is parsed it's tested against
[Oo][Pp]
For the archives:
Found my problem. Te firewall_type option is case sensitive -- and "OPEN"
is supposed to be lowercase.
Cheerio,
SigmaX
On 7/28/06, SigmaX asdf <[EMAIL PROTECTED]> wrote:
I'm trying to setup a gateway/firewall on my network in a similar setup to
tha
On Mon, 2006-07-31 at 10:01 +0100, Rodrigo Galiano wrote:
> Hi,
>
>Just add the following lines on rc.conf to get your gateway up and
> running for the LAN:
>
> gateway_enable="YES"
> natd_enable="YES"
> natd_flags="-n xxx" (you should
Hi,
Just add the following lines on rc.conf to get your gateway up and
running for the LAN:
gateway_enable="YES"
natd_enable="YES"
natd_flags="-n xxx" (you should replace xxx with your external interface
name)
firewall_enable="YES"
firewall_script="
I take it firewall_type="OPEN" does not include the divert rule?
The handbooks reads "The kernel source needs 'option divert' statement added
to the other IPFIREWALL statements compiled into a custom kernel." Is this
still the case in FreeBSD 6.1? Or am I covered by the IPDIVERT module or
someth
On Sat, Jul 29, 2006 at 01:42:41PM -0400, SigmaX asdf wrote:
> >^^^
> >Should be natd_enable="YES"
>
>
> Heh; yeah, typo in my post. The file has it ok. Is there something I have
> to do to specify the interfaces which have nat enabled? Does natd_enable
> automatically forward
On 7/29/06, Igor Robul <[EMAIL PROTECTED]> wrote:
On Fri, Jul 28, 2006 at 07:00:18PM -0400, SigmaX asdf wrote:
> gateway_enable="YES"
> firewall_enable="YES"
> firewall_type="OPEN"
> natd_enabl="YES"
^^^
Should be natd_enable="YES"
Heh; yeah, typo in my post. The file has it
On Fri, Jul 28, 2006 at 07:00:18PM -0400, SigmaX asdf wrote:
> gateway_enable="YES"
> firewall_enable="YES"
> firewall_type="OPEN"
> natd_enabl="YES"
^^^
Should be natd_enable="YES"
___
freebsd-stable@freebsd.org mailing list
http://lists.
I'm trying to setup a gateway/firewall on my network in a similar setup to
that shown in the in the handbook diagram at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-natd.html.
I've followed what I can figure out, adding the following to my /etc/rc.conf
gateway_e
Peter wrote:
> --- Renato Botelho <[EMAIL PROTECTED]> wrote:
>
>> I'm trying to use pf + ftp-proxy n a 6.1-PRERELEASE machine.
>>
>> I have this line on inetd.conf:
>>
>> ftp-proxy stream tcp nowait root/usr/libexec/ftp-proxy
>>
>> ftp-proxy -n
>>
>> And this lines on pf.conf:
>>
>>
--- Renato Botelho <[EMAIL PROTECTED]> wrote:
> I'm trying to use pf + ftp-proxy n a 6.1-PRERELEASE machine.
>
> I have this line on inetd.conf:
>
> ftp-proxy stream tcp nowait root/usr/libexec/ftp-proxy
>
> ftp-proxy -n
>
> And this lines on pf.conf:
>
> rdr on $int_if proto
I'm trying to use pf + ftp-proxy n a 6.1-PRERELEASE machine.
I have this line on inetd.conf:
ftp-proxy stream tcp nowait root/usr/libexec/ftp-proxy
ftp-proxy -n
And this lines on pf.conf:
rdr on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port ftp-proxy
pass in quick
Hi,
I have a FreeBSD 6.0-STABLE server running as my internet gateway. It
was newly installed to 6.0-RELEASE yesterday, and built to -STABLE from
a cvsup early this morning.
I have two separate accounts at the same broadband ISP, with two
separate PPPoE modems on two separate phone lines
n &,
I am able to give them matching remote gateway addresses.
However this is not the case when the interfaces are created any other
way, i.e. via ppp. Ditto ng0/ng1 created by mpd.
Also, if I then kill the cat /dev/tun commands, leaving tun0 and tun1
existing, but unopened, I am then no
I'm not sure if my messages are being received to the mailing list ok. Just
in case the previous one didn't get through, the summary was:
when tun0/tun1 are created with cat /dev/tun &, it is indeed possible to
configure both with the same remote gateway. In all other circumstan
e. If I repeat exactly what you do - including
the two cat /dev/tun commands - then it works for me too. So long as the
tun0 and tun1 interfaces are created with a cat /dev/tun &, I am able to
give them matching remote gateway addresses.
However this is not the case when the interfaces
On Fri, 13 Jan 2006 08:07, Tom Jobbins wrote:
> This can be demonstrated from the command line with the following:
> [EMAIL PROTECTED]:~]$ ifconfig tun0 1.2.3.5 1.2.3.250
> [EMAIL PROTECTED]:~]$ ifconfig tun1 1.2.4.4 1.2.3.250
> ifconfig: ioctl (SIOCAIFADDR): File exists
This is really odd, becaus
Hi,
I have a FreeBSD 6.0-STABLE server running as my internet gateway. It was
newly installed to 6.0-RELEASE yesterday, and built to -STABLE from a cvsup
early this morning.
I have two separate accounts at the same broadband ISP, with two separate
PPPoE modems on two separate phone lines. I
> Hello.
>
> I have an Atheros PCI card in my firewall/gateway machine.
> It seems fully configured because the clients see a good strong signal
> but I can't get a dhcp lease from it. I'm not bothering with WEP just yet.
>
> I followed the instructions found he
Hello.
I have an Atheros PCI card in my firewall/gateway machine.
It seems fully configured because the clients see a good strong signal
but I can't get a dhcp lease from it. I'm not bothering with WEP just yet.
I followed the instructions found here:
http://www.freebsd.org/doc/en_US
On Thu, Dec 23, 2004 at 02:24:18PM -0400, Marc G. Fournier wrote:
>
> Due to limitations in the standard 'linksys/dlink/netgear' routers, as far
> as firewalls are concerned, last night I setup one of my 5.3-STABLE boxes
> as being the gateway ... unless I've set
On Thursday 23 December 2004 18:24, Marc G. Fournier wrote:
> Due to limitations in the standard 'linksys/dlink/netgear' routers,
> as far as firewalls are concerned, last night I setup one of my
> 5.3-STABLE boxes as being the gateway ... unless I've set something
>
Due to limitations in the standard 'linksys/dlink/netgear' routers, as far
as firewalls are concerned, last night I setup one of my 5.3-STABLE boxes
as being the gateway ... unless I've set something up wrong, 'blows
chunks' is what comes to mind :(
The machine:
CPU:
* Christian Chen ([EMAIL PROTECTED]):
> So, what I'm actually doing is:
>
> 1. Set up NAT to route between my ethernet card and tun0
> 2. Set up the firewall rules via PPP
Ugh.
Simply let ppp(8) take care of NAT, do the firewalling with ipfw(8) and
you're done. Close to trivial.
--
Thomas Se
Jacob gets back from vacation.
I compiled the 2200 firmware into the driver in the kernel and applied
your patch (and enabled SMP as this is a SMP box) and it's now recognising
the disks fine. It throws an error on LUN 0 which is the Gateway box, not
a disk LUN but now maps the 2 disk LUNS fine
47 matches
Mail list logo
