Bug 209491 (Broadcast storm with ipfw+natd+gateway) from -CURRENT is now in 11-STABLE

2016-09-16 Thread Cejka Rudolf
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 can see unusual traffic on your outer
network. In our case, three servers with outer interface on the same
local network (broadcast domain) plus some workstations with netbios
queries means seriously overloaded network.

Best regards.

-- 
Rudolf Cejka  http://www.fit.vutbr.cz/~cejkar
Brno University of Technology, Faculty of Information Technology
Bozetechova 2, 612 66  Brno, Czech Republic
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Is the svn2cvs gateway down ?

2011-12-21 Thread Bjoern A. Zeeb

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 seems to have
 gone un-heeded. :)  I'm sure you can take bz' word that it's being
 looked at now though.

It's been fixed and the changes should propagate to cvsup mirrors close
to everyone the next two hours.

/bz

-- 
Bjoern A. Zeeb You have to have visions!
 Stop bit received. Insert coin for new address family.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Is the svn2cvs gateway down ?

2011-12-20 Thread Claude Buisson

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/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Is the svn2cvs gateway down ?

2011-12-20 Thread Bjoern A. Zeeb
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 You have to have visions!
 Stop bit received. Insert coin for new address family.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Is the svn2cvs gateway down ?

2011-12-20 Thread Doug Barton
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' word that it's being
looked at now though.


Doug

-- 

[^L]

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


/etc/rc.d/netif wont add default gateway

2007-12-02 Thread area damai™
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.1.9 netmask 255.255.255.0
inetd_enable=YES
linux_enable=YES
saver=daemon
sshd_enable=YES
#usbd_enable=YES

# -- while issuing /etc/rc.d/netif restart:
[EMAIL PROTECTED] ~]# /etc/rc.d/netif restart
Stopping network: lo0 rl0 plip0 pfsync0 pflog0.
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff00
rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=8VLAN_MTU
inet 192.168.1.9 netmask 0xff00 broadcast 192.168.1.255
ether 00:15:e9:7c:76:12
media: Ethernet autoselect (100baseTX full-duplex)
status: active

# -- the result of running netif to routing tables:
[EMAIL PROTECTED] ~]# netstat -rn
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.1 link#1 UC 0 0 rl0
192.168.1.10 00:0f:b0:84:97:80 UHLW 1 15 rl0 1146

Internet6:

# -- i have to manually add default gateway to get my gateway back on
routing tables:
[EMAIL PROTECTED] ~]# route add default 192.168.1.1
add net default: gateway 192.168.1.1

# -- routing status
[EMAIL PROTECTED] ~]# netstat -rn
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGS 0 0 rl0
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.1 link#1 UC 0 0 rl0
192.168.1.1 link#1 UHLW 2 0 rl0
192.168.1.10 00:0f:b0:84:97:80 UHLW 1 54 rl0 1056

Internet6:

***my question is, why /etc/rc.d/netif wont read directly from my
/etc/rc.conf as I already stated the defaultrouter=192.168.1.1 there?

i'm on FreeBSD 6.2 on LAN

[EMAIL PROTECTED] ~]$ uname -a
FreeBSD www.msc.edu 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #1: Sat Dec  1
14:31:02 MYT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MSC  i386
[EMAIL PROTECTED]

thanks for helping
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: /etc/rc.d/netif wont add default gateway

2007-12-02 Thread Wolfgang Zenker
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.168.1.1
 hostname=msc.edu
 ifconfig_rl0=inet 192.168.1.9 netmask 255.255.255.0
 [..]

 # -- while issuing /etc/rc.d/netif restart:
 [EMAIL PROTECTED] ~]# /etc/rc.d/netif restart
 Stopping network: lo0 rl0 plip0 pfsync0 pflog0.
 [..]

what happens is that /etc/rc.d/netif restart first runs
/etc/rc.d/netif stop. This stops all network interfaces.
Now the kernel routing system gets notified that these interfaces 
are no longer available and deletes all routes that use this
interfaces.
After that /etc/rc.d/netif start runs and the interfaces
become available again. Every time a network interface becomes
available, the kernel adds a route to the immedialtely connected
network (which is determined by interface address and netmask).

So stopping an interface has the side effect of clearing ALL routes
going through this nterface, while starting an interface has only
the side effect of adding a route for the net that is locally
connected to this interface.
The kernel can not add the default route on its own again because
all information about this route had been deleted ehrn the interface
went down.

To add non-local routes (including the default route) you could now
run /etc/rc.d/routing start

Wolfgang
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-25 Thread Matthew Seaman
-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 ntpdate will use a dynamic source port.
 
 Is that behaviour that can be defeated?  If it uses a fixed
 source port, then multiple ntpd clients behind a nat firewall
 will be competing for the same ip quadtuple at the NAT box.  (Or
 does ipnat or pf have the ability to fake different source
 addresses?)

NAT gateways will remap the source port number as necessary to
disambiguate the different hosts.  Although NTP defaults to using
port 123 on both the source and destination ends, it only *has* to
use port 123 on the destination (server) end.  The admin can
override that behaviour by using 'restrict addr ntpport' in
ntp.conf if required.  NTP queries performed via user programs like
ntpq(8) and ntpdc(8) always use an arbitrary high numbered source
port.

There's a similar configuration trick used with the DNS, except in
that case, it works in the opposite sense: DNS queries will use an
arbitrary high numbered source port by default, but you can
configure named to force use of port 53 as the source port.
Obviously this only applies to the server-to-server queries
performed by recursive DNS servers -- as far as I know, there's no
way to force the local resolver library on a particular machine to
use a specific source port.

In any case, the justification for forcing UDP packets to use a
specific source port disappears when you use a modern stateful
firewall like any of the three (pf, ipfw, ipf) supplied with
FreeBSD.

 (I've had what I think is this problem with a VPN setup, where
 only one client behind the NAT firewall could run the VPN client
 at a time, because the VPN protocol used a fixed port and UDP.
 Maybe my NAT rules need more sophistication?  I don't pay all
 that much attention to it...)

Indeed.  For instance, in the case of IPSec there is a special
high-numbered port reserved for use exchanging keys when transiting
NAT gateways. See http://www.ietf.org/rfc/rfc3947.txt for the gory
details.  Note that other VPN packages such as OpenVPN work in a
different way and shouldn't hit this particular hurdle, or at least,
not in the same way.

Cheers,

Matthew

- --
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
  Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpvw38Mjk52CukIwRCEwOAKCA7xelVOzskL4BXyFiplIwwJTJPgCfVWb5
l6Kfk7Sx1glV44FBBL8oqkU=
=GeJ8
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-25 Thread Oliver Fromme
Andrew Reilly wrote:
  Peter Jeremy wrote:
   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 defeated?  If it uses a fixed
  source port, then multiple ntpd clients 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 translation at all.
The gateway rather acts as server and client at the same
time.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH  Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

Passwords are like underwear.  You don't share them,
you don't hang them on your monitor or under your keyboard,
you don't email them, or put them on a web site,
and you must change them very often.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-25 Thread Peter Jeremy
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 ntpdate will use a dynamic source port.

Is that behaviour that can be defeated?

I don't believe so.

  If it uses a fixed
source port, then multiple ntpd clients behind a nat firewall
will be competing for the same ip quadtuple at the NAT box.

You might be better off running ntpd on the firewall and having
the inside hosts sync to it.

  (Or
does ipnat or pf have the ability to fake different source
addresses?)

All NAT tools I've seen have the ability to either use multiple
external addresses or re-write the source port to avoid clashes.
Note that, by default, ntpd doesn't care about the source port
of incoming packets (this can be controlled with the 'ntpport'
option to 'restrict').

(I've had what I think is this problem with a VPN setup, where
only one client behind the NAT firewall could run the VPN client
at a time, because the VPN protocol used a fixed port and UDP.
Maybe my NAT rules need more sophistication?  I don't pay all
that much attention to it...)

I suspect that either your NAT rules need to allow source port
re-writing or the VPN protocol is fussier about having the source
port.

-- 
Peter Jeremy


pgp317m8M4Z7o.pgp
Description: PGP signature


Re: ntpd on a NAT gateway seems to do nothing

2007-07-25 Thread Pete French
 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 track this down.

-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-24 Thread ian j hart
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 than RELENG, but I suspect
 I will simply try updating to a later STABLE tomorrow and see if that
 helps.

  I'm using IPFW and ipnat, which I believe is somewhat unusual. Ipnat is
  there to 'fix' the source IP. Don't ask!
 
 :-) once you start playing with NAT things can get odd quite fast I have
 : found!
 :
  Anyway; I just did a cleandir x2, rebuild and update to p6, and it's
  working again.
 
  Might be worth a try.

 I'll try tomorrow, thanks,

 -pete.

Well it could just as easily be the associated reboot, but one hesitates to 
suggest that on a *nix list :)

-- 
ian j hart
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-24 Thread Pete French
 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 fine.

-pcf.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-24 Thread Oliver Fromme
Pete French wrote:
  [...]
  Any suggestions ? I assume it has something to do with the NAT, but I am
  not sure what. All other TCP connections out from that machine to
  external systems work fine, so it is not as if outbound connections from
  there are not working at all.

Note that NTP does not use TCP, but UDP.  Are you sure that
your filter rules are OK?  It's certainly possible to have
a bug in the rule set so it forwards NTP replies for the
internal clients, but doesn't allow them to reach the ntpd
running on the machine itself.

Another question:  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 problems at all.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH  Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-24 Thread Pete French
 Note that NTP does not use TCP, but UDP.  Are you sure that
 your filter rules are OK?  It's certainly possible to have
 a bug in the rule set so it forwards NTP replies for the
 internal clients, but doesn't allow them to reach the ntpd
 running on the machine itself.

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 can see all these servers ?

 Another question:  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.

No, everything is static. It has to be some error in my PF config
file somewhere 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, and it particlaly works here too (it can see one NTP machine on
the far side NAT, just none further away). I will continue looking

Thanks,

-pcf.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-24 Thread Patrick M. Hausen
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 can see all these servers ?

I would try and run 

# tcpdump -n -i NAT interface host NTP server

in a separate window and compare the output when running 
ntpdate vs. starting ntpd.

HTH,

Patrick M. Hausen
Leiter Netzwerke und Sicherheit
-- 
punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
[EMAIL PROTECTED]   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-24 Thread Peter Jeremy
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 use a dynamic source port.

Is it possible that your NAT rules are interfering with ntpd using
port 123?  Can you check that ntpd is binding to port 123 (using
lsof or netstat+fstat).  As well as tcpdump'ing the NTP traffic,
you might like to ktrace ntpd and verify that incoming packets
are actually arriving there.

If your NAT box is not busy, you might be able to enable logging on
som relevant rules and see what your firewall is actually doing
with the packets.

-- 
Peter Jeremy


pgpWL1Q4KzH8e.pgp
Description: PGP signature


Re: ntpd on a NAT gateway seems to do nothing

2007-07-24 Thread Andrew Reilly
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 defeated?  If it uses a fixed
source port, then multiple ntpd clients behind a nat firewall
will be competing for the same ip quadtuple at the NAT box.  (Or
does ipnat or pf have the ability to fake different source
addresses?)

(I've had what I think is this problem with a VPN setup, where
only one client behind the NAT firewall could run the VPN client
at a time, because the VPN protocol used a fixed port and UDP.
Maybe my NAT rules need more sophistication?  I don't pay all
that much attention to it...)

Cheers,

-- 
Andrew
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


ntpd on a NAT gateway seems to do nothing

2007-07-23 Thread Pete French
Just following the similarly names thread with a bit of interest and I decided
to check my own ntp setup and, to my surprise, discovered I also have a machine
which does nothing. What is more surprising to me is that it has the 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 side of
the NAT does, or on clients the live side of the NAT. I should probably
exolain that the NAT goes onto another network which is also natted, though
that NAT is out of my control.

The ntp.conf file looks like this on all machines:

disable auth
enable ntp
driftfile /etc/ntp.drift
server 10.17.19.0
server 195.40.0.250
server 158.43.128.33
server 158.43.128.66
server 158.43.192.66

The time servers there are for easynet, pipex and an internal machine at
a remote location. ntpdate on the machine can query all the hosts fine,
but ntpdc -p gives:

 remote   local  st poll reach  delay   offsetdisp
===
=valliere.ns.eas 172.16.1.8  16   640 0.0  0.00 0.0
=turpentine.ratt 172.16.1.8   3  1287 0.01451 -0.007633 1.93823
=ntp2.pipex.net  172.16.1.8  16   640 0.0  0.00 0.0
=ntp0.pipex.net  172.16.1.8  16   640 0.0  0.00 0.0
=ntp1.pipex.net  172.16.1.8  16   640 0.0  0.00 0.0

As you can see, it can only reach the internal machine. On other machines
behind the NAT it looks like this:

 remote   local  st poll reach  delay   offsetdisp
===
=valliere.ns.eas 10.50.50.2   2  256  377 0.00577 -0.004396 0.01192
=turpentine.ratt 10.50.50.2   3  256  377 0.01534 -0.004566 0.00482
*ntp2.pipex.net  10.50.50.2   2  256  377 0.00635 -0.004052 0.00899
=ntp0.pipex.net  10.50.50.2   2  256  377 0.00729 -0.002443 0.01395
=ntp1.pipex.net  10.50.50.2   2  256  377 0.00768 -0.002426 0.00951

But those connections are flowing through the NAT box oon which ntpd
is not connecting!

Any suggestions ? I assume it has something to do with the NAT, but I am
not sure what. All other TCP connections out from that machine to
external systems work fine, so it is not as if outbound connections from
there are not working at all.

-pcf.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-23 Thread ian j hart
On Monday 23 July 2007 13:50:09 Pete French wrote:
 Just following the similarly names thread with a bit of interest and I
 decided to check my own ntp setup and, to my surprise, discovered I also
 have a machine which does nothing. What is more surprising to me is that it
 has the 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 side of
 the NAT does, or on clients the live side of the NAT. I should probably
 exolain that the NAT goes onto another network which is also natted, though
 that NAT is out of my control.

 The ntp.conf file looks like this on all machines:

   disable auth
   enable ntp
   driftfile /etc/ntp.drift
   server 10.17.19.0
   server 195.40.0.250
   server 158.43.128.33
   server 158.43.128.66
   server 158.43.192.66

 The time servers there are for easynet, pipex and an internal machine at
 a remote location. ntpdate on the machine can query all the hosts fine,
 but ntpdc -p gives:

  remote   local  st poll reach  delay   offsetdisp
 ===
 =valliere.ns.eas 172.16.1.8  16   640 0.0  0.00 0.0
 =turpentine.ratt 172.16.1.8   3  1287 0.01451 -0.007633 1.93823
 =ntp2.pipex.net  172.16.1.8  16   640 0.0  0.00 0.0
 =ntp0.pipex.net  172.16.1.8  16   640 0.0  0.00 0.0
 =ntp1.pipex.net  172.16.1.8  16   640 0.0  0.00 0.0

 As you can see, it can only reach the internal machine. On other machines
 behind the NAT it looks like this:

  remote   local  st poll reach  delay   offsetdisp
 ===
 =valliere.ns.eas 10.50.50.2   2  256  377 0.00577 -0.004396 0.01192
 =turpentine.ratt 10.50.50.2   3  256  377 0.01534 -0.004566 0.00482
 *ntp2.pipex.net  10.50.50.2   2  256  377 0.00635 -0.004052 0.00899
 =ntp0.pipex.net  10.50.50.2   2  256  377 0.00729 -0.002443 0.01395
 =ntp1.pipex.net  10.50.50.2   2  256  377 0.00768 -0.002426 0.00951

 But those connections are flowing through the NAT box oon which ntpd
 is not connecting!

 Any suggestions ? I assume it has something to do with the NAT, but I am
 not sure what. All other TCP connections out from that machine to
 external systems work fine, so it is not as if outbound connections from
 there are not working at all.

 -pcf.
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]

It's deja-vu all over again.

I found my works NTP service was broken on Friday, just after I started my 
holiday.

Packets were going out but nothing was coming back.

I'm using IPFW and ipnat, which I believe is somewhat unusual. Ipnat is there 
to 'fix' the source IP. Don't ask!

Checking the logs it appears that this broke after I updated from 
6.2-RELEASE-p1 to 6.2-RELEASE-p5. I found this in messages.

May 30 17:25:31 firewall ntpd[825]: ntpd 4.2.0-a Tue May 29 20:59:19 BST 2007 
(1)
May 30 17:27:31 firewall ntpd[825]: too many recvbufs allocated (40)

ntpq -p would report No Association ID's (from memory)

Anyway; I just did a cleandir x2, rebuild and update to p6, and it's working 
again.

Might be worth a try.

-- 
ian j hart
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ntpd on a NAT gateway seems to do nothing

2007-07-23 Thread Pete French
 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 later STABLE tomorrow and see if that
helps.

 I'm using IPFW and ipnat, which I believe is somewhat unusual. Ipnat is there 
 to 'fix' the source IP. Don't ask!

:-) once you start playing with NAT things can get odd quite fast I have found!

 Anyway; I just did a cleandir x2, rebuild and update to p6, and it's working 
 again.

 Might be worth a try.

I'll try tomorrow, thanks,

-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Gateway [SOLVED]

2006-08-21 Thread Chuck Swiger

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][Pp][Ee][Nn])
setup_loopback
${fwcmd} add 65000 pass all from any to any
;;

--
-Chuck

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Gateway [SOLVED]

2006-08-20 Thread SigmaX asdf

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
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_enable=YES
firewall_enable=YES
firewall_type=OPEN
natd_enabl=YES
natd_interface=rl0

My understanding is that in FreeBSD 6 it's not necessary to recompile a
kernal with IPFIREWALL and IPDIVERT, but appropriate modules will be loaded
automatically.

That said, the NAT and gateway stuff doesn't seem to be working properly,
leastwise not when I try to connect from my Ubuntu Linux client (See thread
here: http://ubuntuforums.org/showthread.php?t=224843)

What all am I supposed to do to setup this gateway?

SigmaX


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Gateway [SOLVED]

2006-08-20 Thread Doug Barton
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][Ee][Nn]. Can you please verify that if the _only_ thing you change
is that variable from open to OPEN that it doesn't work, and if so, can
you please set rc_debug and rc_info to yes in /etc/rc.conf, reboot, and give
us an idea where it's breaking?

Thanks,

Doug

-- 

This .signature sanitized for your protection

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Gateway

2006-07-31 Thread SigmaX asdf

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
something?

SigmaX

On 7/29/06, Igor Robul [EMAIL PROTECTED] wrote:


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 any/every packet to any/every interface?
Personally I use ipfilter, but for ipfw/natd you need to specify
divert rule. You can find many examples, including ones in FreeBSD
handbook.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Gateway

2006-07-31 Thread Rodrigo Galiano
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=/etc/ipfw.test (this is to specify firewall script file
(don't forget the natd rule on the firewall script).



Regards
---
Rodrigo Galiano Celestino
Consultor de Internet  Sistemas
Cellular: +244 923 57 79 72
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of SigmaX asdf
Sent: segunda-feira, 31 de Julho de 2006 8:39
To: Igor Robul
Cc: freebsd-stable@freebsd.org
Subject: Re: Gateway

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
something?

SigmaX

On 7/29/06, Igor Robul [EMAIL PROTECTED] wrote:

 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 any/every packet to any/every interface?
 Personally I use ipfilter, but for ipfw/natd you need to specify
 divert rule. You can find many examples, including ones in FreeBSD
 handbook.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Gateway

2006-07-31 Thread Iasen Kostov
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 replace xxx with your external interface
 name)

from /etc/defaults/rc.conf :

natd_interface=   # Public interface or IPaddress to use.

 firewall_enable=YES
 firewall_script=/etc/ipfw.test (this is to specify firewall script file
 (don't forget the natd rule on the firewall script).
 


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Gateway

2006-07-29 Thread Igor Robul
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.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Gateway

2006-07-29 Thread SigmaX asdf

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 ok.  Is there something I have
to do to specify the interfaces which have nat enabled?  Does natd_enable
automatically forward any/every packet to any/every interface?

SigmaX
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Gateway

2006-07-29 Thread Igor Robul
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 any/every packet to any/every interface?
Personally I use ipfilter, but for ipfw/natd you need to specify
divert rule. You can find many examples, including ones in FreeBSD
handbook.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Gateway

2006-07-28 Thread SigmaX asdf

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_enable=YES
firewall_enable=YES
firewall_type=OPEN
natd_enabl=YES
natd_interface=rl0

My understanding is that in FreeBSD 6 it's not necessary to recompile a
kernal with IPFIREWALL and IPDIVERT, but appropriate modules will be loaded
automatically.

That said, the NAT and gateway stuff doesn't seem to be working properly,
leastwise not when I try to connect from my Ubuntu Linux client (See thread
here: http://ubuntuforums.org/showthread.php?t=224843)

What all am I supposed to do to setup this gateway?

SigmaX
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Problems with pf + ftp-proxy on gateway

2006-03-28 Thread Renato Botelho
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 on $ext_if inet proto tcp from any port ftp-data to
$ext_if:0 user proxy flags S/SA keep state

When one machine inside my network (e.g. 192.168.x.x) connects to an
external ftp server (e.g. ftp.FreeBSD.org), data connection doesn't
work.

Connection comes to my firewall and is accepted but connection is not
established and stay like this here:

self tcp 200.x.x.x:57625 - 200.x.x.x:20   ESTABLISHED:FIN_WAIT_2

Any kind of help will be appreciate

thanks
--
Renato Botelho
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Problems with pf + ftp-proxy on gateway

2006-03-28 Thread Peter

--- 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 tcp from any to any port ftp - 127.0.0.1 port
 ftp-proxy
 pass in quick on $ext_if inet proto tcp from any port ftp-data to
 $ext_if:0 user proxy flags S/SA keep state
 
 When one machine inside my network (e.g. 192.168.x.x) connects to an
 external ftp server (e.g. ftp.FreeBSD.org), data connection doesn't
 work.
 
 Connection comes to my firewall and is accepted but connection is not
 established and stay like this here:
 
 self tcp 200.x.x.x:57625 - 200.x.x.x:20   ESTABLISHED:FIN_WAIT_2

You need to decide whether you are working with passive ftp clients
(probably), active, or both.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Problems with pf + ftp-proxy on gateway

2006-03-28 Thread Matthew Seaman
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:

 rdr on $int_if proto tcp from any to any port ftp - 127.0.0.1 port
 ftp-proxy
 pass in quick on $ext_if inet proto tcp from any port ftp-data to
 $ext_if:0 user proxy flags S/SA keep state

 When one machine inside my network (e.g. 192.168.x.x) connects to an
 external ftp server (e.g. ftp.FreeBSD.org), data connection doesn't
 work.

 Connection comes to my firewall and is accepted but connection is not
 established and stay like this here:

 self tcp 200.x.x.x:57625 - 200.x.x.x:20   ESTABLISHED:FIN_WAIT_2
 
 You need to decide whether you are working with passive ftp clients
 (probably), active, or both.

Or use the ftp/pftpx port, which handles proxying all types of active and
passive FTP.  That's the successor to ftp-proxy(8) due to be released
shortly as part of OpenBSD 3.9, and documented at:

http://www.openbsd.org/cgi-bin/man.cgi?query=ftp-proxyapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
  Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature


Re: Two PPP connections to the same ISP with same remote gateway

2006-01-16 Thread Tom Jobbins

Thanks for replying, Daniel


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, because I don't see this on my machines (as per our 
discussion on IRC which you mention below), I did..

midget# uname -a
FreeBSD midget.dons.net.au 5.4-STABLE FreeBSD 5.4-STABLE #4: Mon Aug  1 
09:01:42 CST 2005[EMAIL PROTECTED]:/usr/src/sys/i386/compile/MIDGET  i386

midget# cat /dev/tun 
[1] 21524
midget# cat /dev/tun 
[2] 21525
 

I've isolated the difference.   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 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 longer able to set the matching 
gateway.   And if I don't kill the cat commands, ppp can't use those tun 
devices because another process has them open.


So it would appear this was just a dead end.  I don't know whats 
different about an interface created with the cat command - perhaps as 
it's not connected to a real network utility, the normal route checking 
does not apply?


If you - or anyone else - has any more ideas as to what I can try to 
make this work, I would be most grateful.  It's incredibly frustrating 
to be limited in this way, given that I'm almost certain that ipfilters 
source-based routing will get around any routing issues if I could only 
bring the interfaces up.



Thanks


Tom
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Two PPP connections to the same ISP with same remote gateway

2006-01-16 Thread Tom Jobbins

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 need to connect 
both of these simultaneously thus providing me with two PPP connections 
to the same ISP.


The problem I am having is that both connections have the same remote 
gateway, and FreeBSD is preventing me from setting the IP address on the 
second connection because its gateway is the same.


This can be demonstrated from the command line with the following:
[EMAIL PROTECTED]:~]$ ifconfig tun0 1.2.3.6 1.2.3.250
[EMAIL PROTECTED]:~]$ ifconfig tun1 1.2.3.7 1.2.3.250  
ifconfig: ioctl (SIOCAIFADDR): File exists


What is strange is that I was speaking to an op on the Efnet IRC channel 
#FreeBSDHelp who said he was able to execute the above two commands on 
his 6.0 machine without problems.  So I am confused as to why it won't 
work for me.  Perhaps there is some kernel or other configuration option 
he has set but I don't, which would make this work?


If anyone could tell me a way to get this working I would be most 
grateful.  Ultimately what I need to achieve is two simulatenous PPP 
connections to the same ISP using the same remote gateway.  Once these 
are established I will be using ipfilter to do source-IP routing, i.e. 
LAN machine 192.168.0.100 will be routed via tun0, 192.168.0.200 will be 
routed via tun1, etc.


Thanks in advance

Tom

PS.  Mulilink connections or any other method of combining the two PPP 
connections will not work for me - I need them to be separate and 
distinct, with their own IP addresses.  If I had realised there would be 
this problem then I would have chosen a different broadband ISP for the 
second connection - but now I'm stuck into a minimum contract so I need 
to get it working.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Two PPP connections to the same ISP with same remote gateway

2006-01-13 Thread Tom Jobbins
Thanks for replying, Daniel


This is really odd, because I don't see this on my machines (as per our
 discussion on IRC which you mention below), I did..

 midget# cat /dev/tun 
 [1] 21524
 midget# cat /dev/tun 
 [2] 21525



I've isolated the difference.   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 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 longer able to set the matching
gateway.   And if I don't kill the cat commands, ppp can't use those tun
devices because another process has them open.

So it would appear this was just a dead end.  I don't know whats different
about an interface created with the cat command - perhaps as it's not
connected to a real network utility, the normal route checking does not
apply?

If you - or anyone else - has any more ideas as to what I can try to make
this work, I would be most grateful.  It's incredibly frustrating to be
limited in this way, given that I'm almost certain that ipfilters
source-based routing will get around any routing issues if I could only
bring the interfaces up.


Thanks


Tom
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Two PPP connections to the same ISP with same remote gateway

2006-01-13 Thread Tom Jobbins
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 circumstances,
e.g. when they are created by ppp, it is not possible.

I have found a solution.  It's messy as hell, but it does seem to work.

Here's what I do:

1. Bring up the first connection with ppp, or mpd
2. Bring up the second connection with mpd - it has to be mpd because ppp
will shut the connection down when it fails to set the IP address.  mpd
leaves the connection open, just with no IP address set.

At this point, ifconfig shows:

tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1492
inet 87.74.2.230 -- 83.146.18.40 netmask 0x
Opened by PID 879
ng0: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST mtu 1492
inet6 fe80::20e:cff:fea1:bf55%ng1 prefixlen 64 scopeid 0x5

3. Manually ifconfig the mpd interface (ng0) setting the correct IP address
(which I see in the mpd logs), and an incorrect gateway:

[EMAIL PROTECTED]:~]$ /sbin/ifconfig ng1 87.74.29.242 83.146.18.99 netmask
0x -link0
[EMAIL PROTECTED]:~]$

4. Using ipfilter + ipnat, I do source based routing, specifying the correct
remote gateway to ipfilter:
/etc/ipf.rules:
pass in quick on em0 to ng0:83.146.18.40 from 192.168.0.212/32 to any
/etc/ipnat.rules:
map ng0 192.168.0.212/32 - 0.0.0.0/32
map tun0 192.168.0.0/24 - 0.0.0.0/32

And voila, it works - LAN machine 192.168.0.212 is using interface ng0, and
all other machines are using interface tun0.  I assume ipfilter ignores the
remote gateway configured against ng0, and simply passes packets directly to
the (correct) gateway I have configured it with.

The main downside is that I have to manually ifconfig the ng0 interface
every time that connection is brought up.  However I can probably get this
done automatically using a script that is executed by mpd every time the
interface comes up.

So it's not pretty, but it gets the job done.

I would very much like to request a fix for future FreeBSD versions to allow
the user to specify two point-to-point links with the same remote gateway
:)  I realise it's not standard and in many cases it's an error, but as you
can see from the above there are cases where it's necessary, and where it
works fine.

Thanks again for your help Daniel


Tom



On 13/01/06, Daniel O'Connor [EMAIL PROTECTED] wrote:

 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, because I don't see this on my machines (as per our
 discussion on IRC which you mention below), I did..

 midget# uname -a
 FreeBSD midget.dons.net.au 5.4-STABLE FreeBSD 5.4-STABLE #4: Mon Aug  1
 09:01:42 CST 2005[EMAIL PROTECTED]
 :/usr/src/sys/i386/compile/MIDGET  i386

 midget# cat /dev/tun 
 [1] 21524
 midget# cat /dev/tun 
 [2] 21525
 midget# ifconfig tun0
 tun0: flags=8010POINTOPOINT,MULTICAST mtu 1500
 midget# ifconfig tun1
 tun1: flags=8010POINTOPOINT,MULTICAST mtu 1500
 Opened by PID 21524
 midget# ifconfig tun2
 tun2: flags=8010POINTOPOINT,MULTICAST mtu 1500
 Opened by PID 21525
 midget# ifconfig tun1 1.2.3.4 1.2.3.254
 midget# ifconfig tun2 1.2.3.5 1.2.3.254
 midget# ifconfig tun1
 tun1: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500
 inet 1.2.3.4 -- 1.2.3.254 netmask 0xff00
 inet6 fe80::290:27ff:fe45:a94%tun1 prefixlen 64 scopeid 0x8
 Opened by PID 21524
 midget# ifconfig tun2
 tun2: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500
 inet 1.2.3.5 -- 1.2.3.254 netmask 0xff00
 inet6 fe80::290:27ff:fe45:a94%tun2 prefixlen 64 scopeid 0x9
 Opened by PID 21525

 I also tried with a netmask of 255.255.255.255 - same result.

 my sysctl.conf contains..
 net.inet.ip.fw.one_pass=0
 hw.intr_storm_threshold=15000
 hw.snd.maxautovchans=4
 hw.snd.pcm0.vchans=4

 My kernel config is pretty standard - I've attached it if you want to look
 through it.

 I also tried it on a 6.0 amd64 machine -
 FreeBSD eureka.gsoft.com.au 6.0-RC1 FreeBSD 6.0-RC1 #0: Wed Oct 26
 13:29:47 UTC 2005 [EMAIL PROTECTED]
 :/usr/obj/local0/src/sys/GENESIS  amd64

 Same result..

 --
 Daniel O'Connor software and network engineer
 for Genesis Software - http://www.gsoft.com.au
 The nice thing about standards is that there
 are so many of them to choose from.
   -- Andrew Tanenbaum
 GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Two PPP connections to the same ISP with same remote gateway

2006-01-12 Thread Tom Jobbins
 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 need to connect both of these
simultaneously thus providing me with two PPP connections to the same ISP.

The problem I am having is that both connections have the same remote
gateway, and FreeBSD is preventing me from setting the IP address on the
second connection because its gateway is the same.

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

Similarly when I connect using either ppp or mpd, I get the above error in
the logs and the second connection fails.  Either connection works on its
own, but they won't work simultaneously.

What is strange is that I was speaking to an op on the Efnet IRC channel
#FreeBSDHelp who said he was able to execute the above two commands on his
6.0 machine without problems.  So I am confused as to why it won't work for
me.  Perhaps there is some kernel or other configuration option he has set
but I don't, which would make this work?

If anyone could tell me a way to get this working I would be most grateful.
Once the connections are established I will be using ipfilter to do
source-IP routing, i.e. LAN machine 192.168.0.100 will be routed via tun0,
192.168.0.200 will be routed via tun1, etc.


Thanks in advance


Tom

PS.  Mulilink connections or any other method of combining the two PPP
connections will not work for me - I need them to be separate and distinct,
with their own IP addresses.  If I had realised there would be this problem
then I would have chosen a different broadband ISP for the second connection
- but now I'm stuck into a minimum contract so I need to get it working.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Two PPP connections to the same ISP with same remote gateway

2006-01-12 Thread Daniel O'Connor
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, because I don't see this on my machines (as per our 
discussion on IRC which you mention below), I did..

midget# uname -a
FreeBSD midget.dons.net.au 5.4-STABLE FreeBSD 5.4-STABLE #4: Mon Aug  1 
09:01:42 CST 2005[EMAIL PROTECTED]:/usr/src/sys/i386/compile/MIDGET  i386

midget# cat /dev/tun 
[1] 21524
midget# cat /dev/tun 
[2] 21525
midget# ifconfig tun0
tun0: flags=8010POINTOPOINT,MULTICAST mtu 1500
midget# ifconfig tun1
tun1: flags=8010POINTOPOINT,MULTICAST mtu 1500
Opened by PID 21524
midget# ifconfig tun2
tun2: flags=8010POINTOPOINT,MULTICAST mtu 1500
Opened by PID 21525
midget# ifconfig tun1 1.2.3.4 1.2.3.254
midget# ifconfig tun2 1.2.3.5 1.2.3.254
midget# ifconfig tun1
tun1: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500
inet 1.2.3.4 -- 1.2.3.254 netmask 0xff00
inet6 fe80::290:27ff:fe45:a94%tun1 prefixlen 64 scopeid 0x8
Opened by PID 21524
midget# ifconfig tun2
tun2: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500
inet 1.2.3.5 -- 1.2.3.254 netmask 0xff00
inet6 fe80::290:27ff:fe45:a94%tun2 prefixlen 64 scopeid 0x9
Opened by PID 21525

I also tried with a netmask of 255.255.255.255 - same result.

my sysctl.conf contains..
net.inet.ip.fw.one_pass=0
hw.intr_storm_threshold=15000
hw.snd.maxautovchans=4
hw.snd.pcm0.vchans=4

My kernel config is pretty standard - I've attached it if you want to look 
through it.

I also tried it on a 6.0 amd64 machine - 
FreeBSD eureka.gsoft.com.au 6.0-RC1 FreeBSD 6.0-RC1 #0: Wed Oct 26 13:29:47 UTC 
2005 [EMAIL PROTECTED]:/usr/obj/local0/src/sys/GENESIS  amd64

Same result..

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
machine i386
cpu I686_CPU
ident   MIDGET

options SCHED_4BSD  # 4BSD scheduler
options INET# InterNETworking
options INET6   # IPv6 communications protocols
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options MD_ROOT # MD is a potential root device
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_GPT# GUID Partition Tables.
options COMPAT_43   # Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI
options KTRACE  # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time 
extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options ADAPTIVE_GIANT  # Giant mutex is adaptive.

device  apic# I/O APIC

# Bus support.  Do not remove isa, even if you have no isa slots
device  isa
device  pci

# Floppy drives
device  fdc

# ATA and ATAPI devices
device  ata
device  atadisk # ATA disk drives
device  ataraid # ATA RAID drives
device  atapicd # ATAPI CDROM drives
device  atapicam

# SCSI peripherals
device  scbus   # SCSI bus (required for SCSI)
device  ch  # SCSI media changers
device  da  # Direct Access (disks)
device  sa  # Sequential Access (tape etc)
device  cd  # CD
device  pass# Passthrough device (direct SCSI access)

# atkbdc0 controls both the keyboard and the PS/2 mouse
device  atkbdc  # AT keyboard controller
device  atkbd   # AT keyboard
device  psm # PS/2 mouse

device  vga # VGA video card driver

device  splash  # Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
device  sc

device  agp # support several AGP chipsets

# Floating point support - do not disable.
device  npx

# Add 

WAP gateway config

2005-02-10 Thread Matt Herzog
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.ISO8859-1/books/handbook/network-wireless.html

I ran these commands:
sysctl net.link.ether.bridge.enable=1
sysctl net.link.ether.bridge.config=wi0,vr0
sysctl net.inet.ip.forwarding=1

The ath0 is bridged with the vr0 which is the internal NIC.
dhcpd is running on vr0. I have the following in my ipf.conf:
pass in quick on ath0 from any to any
pass out quick on ath0 from any to any

un /root# wicontrol ath0
NIC serial number:  [  ]
Station name:   [ unaligned.com ]
SSID for IBSS creation: [ wap ]
Current netname (SSID): [ wap ]
Desired netname (SSID): [ wap ]
Current BSSID:  [ 00:0f:3d:ae:36:e0 ]
Channel list:   [ ffe ]
IBSS channel:   [ 11 ]
Current channel:[ 11 ]
Comms quality/signal/noise: [ 0 13 0 ]
Promiscuous mode:   [ Off ]
Intersil-Prism2 based card: [ 1 ]
Port type (1=BSS, 3=ad-hoc):[ 6 ]
MAC address:[ 00:0f:3d:ae:36:e0 ]
TX rate (selection):[ 11 ]
TX rate (actual speed): [ 11 ]
RTS/CTS handshake threshold:[ 2312 ]
Create IBSS:[ Off ]
Access point density:   [ 1 ]
Power Mgmt (1=on, 0=off):   [ 0 ]
Max sleep time: [ 100 ]
WEP encryption: [ Off ]
TX encryption key:  [ 1 ]
Encryption keys:[  ][  ][  ][  ]

My entire ifconfig:

fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=8VLAN_MTU
inet 24.98.219.30 netmask 0xfe00 broadcast 255.255.255.255
ether 00:03:47:0b:74:7b
media: Ethernet autoselect (100baseTX full-duplex)
status: active
ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
ether 00:0f:3d:ae:36:e0
media: IEEE 802.11 Wireless Ethernet DS/11Mbps hostap (autoselect 
hostap)
status: associated
ssid mycod 1:mycod
channel 11 authmode OPEN powersavemode OFF powersavesleep 100
rtsthreshold 2312 protmode CTS
wepmode OFF weptxkey 1
vr0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255
ether 00:d0:68:01:55:a3
media: Ethernet autoselect (100baseTX full-duplex)
status: active
plip0: flags=108810POINTOPOINT,SIMPLEX,MULTICAST mtu 1500
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet 127.0.0.1 netmask 0xff00 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: WAP gateway config

2005-02-10 Thread Mark Andrews

 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.ISO8859-1/books/handbook/network-wireless.ht
 ml
 
 I ran these commands:
 sysctl net.link.ether.bridge.enable=1
 sysctl net.link.ether.bridge.config=wi0,vr0

Shouldn't that be:

sysctl net.link.ether.bridge.config=ath0,vr0

 sysctl net.inet.ip.forwarding=1
 
 The ath0 is bridged with the vr0 which is the internal NIC.
 dhcpd is running on vr0. I have the following in my ipf.conf:
 pass in quick on ath0 from any to any
 pass out quick on ath0 from any to any
 
 un /root# wicontrol ath0
 NIC serial number:  [  ]
 Station name:   [ unaligned.com ]
 SSID for IBSS creation: [ wap ]
 Current netname (SSID): [ wap ]
 Desired netname (SSID): [ wap ]
 Current BSSID:  [ 00:0f:3d:ae:36:e0 ]
 Channel list:   [ ffe ]
 IBSS channel:   [ 11 ]
 Current channel:[ 11 ]
 Comms quality/signal/noise: [ 0 13 0 ]
 Promiscuous mode:   [ Off ]
 Intersil-Prism2 based card: [ 1 ]
 Port type (1=BSS, 3=ad-hoc):[ 6 ]
 MAC address:[ 00:0f:3d:ae:36:e0 ]
 TX rate (selection):[ 11 ]
 TX rate (actual speed): [ 11 ]
 RTS/CTS handshake threshold:[ 2312 ]
 Create IBSS:[ Off ]
 Access point density:   [ 1 ]
 Power Mgmt (1=on, 0=off):   [ 0 ]
 Max sleep time: [ 100 ]
 WEP encryption: [ Off ]
 TX encryption key:  [ 1 ]
 Encryption keys:[  ][  ][  ][  ]
 
 My entire ifconfig:
 
 fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
   options=8VLAN_MTU
   inet 24.98.219.30 netmask 0xfe00 broadcast 255.255.255.255
   ether 00:03:47:0b:74:7b
   media: Ethernet autoselect (100baseTX full-duplex)
   status: active
 ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
   inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
   ether 00:0f:3d:ae:36:e0
   media: IEEE 802.11 Wireless Ethernet DS/11Mbps hostap (autoselect ho
 stap)
   status: associated
   ssid mycod 1:mycod
   channel 11 authmode OPEN powersavemode OFF powersavesleep 100
   rtsthreshold 2312 protmode CTS
   wepmode OFF weptxkey 1
 vr0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
   inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255
   ether 00:d0:68:01:55:a3
   media: Ethernet autoselect (100baseTX full-duplex)
   status: active
 plip0: flags=108810POINTOPOINT,SIMPLEX,MULTICAST mtu 1500
 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
   inet 127.0.0.1 netmask 0xff00 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


FreeBSD 5.3-STABLE makes terrible router/gateway?

2004-12-23 Thread Marc G. Fournier
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: Intel(R) Pentium(R) 4 CPU 2.00GHz (1995.01-MHz 686-class CPU)
real memory  = 536805376 (511 MB)
avail memory = 519823360 (495 MB)
Two controllers:
fxp0: Intel 82550 Pro/100 Ethernet port 0xd000-0xd03f mem 
0xfa00-0xfa01,0xfa021000-0xfa021fff irq 19 at device 9.0 on pci2 miibus0: MII 
bus on fxp0
fxp0: Ethernet address: 00:02:b3:ee:da:3e
de0: Digital 21140A Fast Ethernet port 0xd100-0xd17f mem 
0xfa02-0xfa02007f irq 20 at device 11.0 on pci2
de0: [GIANT-LOCKED]
de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.0
de0: enabling 10baseT port
de0: Ethernet address: 00:00:c0:b9:e1:f9
Firewall rules are bare minimal:
# ipfw list
00050 divert 8668 ip from any to any via de0
01000 allow ip from any to any
65535 deny ip from any to any
And natd is running with:
-redirect_port tcp 192.168.1.4:22 22 -n de0
I run interactive sessions to my remote/colo servers ... and I can *see* 
the difference between the Linksys and the FreeBSD box, as far as being 
able to get work done is concerned ...

My only thought is that its the de controller itself ... when I tried to 
compile it into the kernel, vs using it as a module, it caused the server 
itself to crash just before it did the PRNG stuff (just after mounting 
root) ... loading it as a module works fine though ...

is there a problem with the de driver itself, or 5.x, that needs to be 
looked into?

thanks ...

Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 5.3-STABLE makes terrible router/gateway?

2004-12-23 Thread Josh Paetzel
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
 up wrong, 'blows chunks' is what comes to mind :(

 The machine:

 CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (1995.01-MHz 686-class CPU)
 real memory  = 536805376 (511 MB)
 avail memory = 519823360 (495 MB)

 Two controllers:

 fxp0: Intel 82550 Pro/100 Ethernet port 0xd000-0xd03f mem
 0xfa00-0xfa01,0xfa021000-0xfa021fff irq 19 at device 9.0 on
 pci2 miibus0: MII bus on fxp0 fxp0: Ethernet address:
 00:02:b3:ee:da:3e

 de0: Digital 21140A Fast Ethernet port 0xd100-0xd17f mem
 0xfa02-0xfa02007f irq 20 at device 11.0 on pci2 de0:
 [GIANT-LOCKED]
 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.0
 de0: enabling 10baseT port
 de0: Ethernet address: 00:00:c0:b9:e1:f9

 Firewall rules are bare minimal:

 # ipfw list
 00050 divert 8668 ip from any to any via de0
 01000 allow ip from any to any
 65535 deny ip from any to any

 And natd is running with:

 -redirect_port tcp 192.168.1.4:22 22 -n de0

 I run interactive sessions to my remote/colo servers ... and I can
 *see* the difference between the Linksys and the FreeBSD box, as
 far as being able to get work done is concerned ...

 My only thought is that its the de controller itself ... when I
 tried to compile it into the kernel, vs using it as a module, it
 caused the server itself to crash just before it did the PRNG stuff
 (just after mounting root) ... loading it as a module works fine
 though ...

 is there a problem with the de driver itself, or 5.x, that needs to
 be looked into?

 thanks ...

 
 Marc G. Fournier   Hub.Org Networking Services
 (http://www.hub.org) Email: [EMAIL PROTECTED]   Yahoo!:
 yscrappy  ICQ: 7615664

Is it possible that there is a 10/100 or duplex mismatch on the NICs?  
I use a 200mhz Ppro w/ the fxp0 and sis0 drivers to nat/firewall a 
3mbps connection so I would think your hardware is sufficient to do 
the job.
-- 
Thanks,

Josh Paetzel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 5.3-STABLE makes terrible router/gateway?

2004-12-23 Thread Tim Robbins
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 something up wrong, 'blows 
 chunks' is what comes to mind :(
 
 The machine:
 
 CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (1995.01-MHz 686-class CPU)
 real memory  = 536805376 (511 MB)
 avail memory = 519823360 (495 MB)
 
 Two controllers:
 
 fxp0: Intel 82550 Pro/100 Ethernet port 0xd000-0xd03f mem 
 0xfa00-0xfa01,0xfa021000-0xfa021fff irq 19 at device 9.0 on pci2 
 miibus0: MII bus on fxp0
 fxp0: Ethernet address: 00:02:b3:ee:da:3e
 
 de0: Digital 21140A Fast Ethernet port 0xd100-0xd17f mem 
 0xfa02-0xfa02007f irq 20 at device 11.0 on pci2
 de0: [GIANT-LOCKED]
 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.0
 de0: enabling 10baseT port
 de0: Ethernet address: 00:00:c0:b9:e1:f9
 
 Firewall rules are bare minimal:
 
 # ipfw list
 00050 divert 8668 ip from any to any via de0
 01000 allow ip from any to any
 65535 deny ip from any to any
 
 And natd is running with:
 
 -redirect_port tcp 192.168.1.4:22 22 -n de0
 
 I run interactive sessions to my remote/colo servers ... and I can *see* 
 the difference between the Linksys and the FreeBSD box, as far as being 
 able to get work done is concerned ...
 
 My only thought is that its the de controller itself ... when I tried to 
 compile it into the kernel, vs using it as a module, it caused the server 
 itself to crash just before it did the PRNG stuff (just after mounting 
 root) ... loading it as a module works fine though ...
 
 is there a problem with the de driver itself, or 5.x, that needs to be 
 looked into?

Please put a little effort into researching the problem before making
unhelpful comments about blowing chunks. Try a different NIC; try using
ipfilter or pf NAT instead of natd if you expect performance.


Tim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD Server and Gateway

2002-07-08 Thread Thomas Seck

* 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 Seck

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message



Re: QLogic 2200 to IBM ESS (Shark) via SAN Data Gateway.

2000-05-31 Thread Carl Makin


Hi Ken,

On Wed, 31 May 2000, Kenneth D. Merry wrote:

 On Thu, Jun 01, 2000 at 12:58:18 +1000, Carl Makin wrote:

  Is anyone using a QLogic 2200 FC card that can help me with a problem.

 You probably won't get much help on the QLogic side of things until Matt
 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.

 The patch is against -current, hopefully it'll apply okay to -stable.

Applied fine with an offset of -10. :)

FYI,

bash-2.04# ./rawio -a -I ESS-FC -v 1 /dev/da1c
TestID   K/sec  /sec %User%Sys  %Total
RR   ESS-FC 8396.3  5220.2 4.3 4.4  16384
SR   ESS-FC21633.9 13200.4 9.710.1  16384
RW   ESS-FC 5498.9  3400.2 2.6 2.8  16384
SW   ESS-FC18207.9 0.3 8.3 8.6  16384

I'm happy enough with that!

Many thanks!

Carl.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message