On Tue, 18 Nov 2003 12:00:33 -0500
Loh John Wu <[EMAIL PROTECTED]> wrote:
> So I have a fresh install of FreeBSD 5.1 from a CD (ISO).
>
> Now I'm trying to turn on console redirection in my image, but I can't seem
> to get it to work properly.
>
> I read
So I have a fresh install of FreeBSD 5.1 from a CD (ISO).
Now I'm trying to turn on console redirection in my image, but I can't seem
to get it to work properly.
I read the article on turning on console redirection at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialco
On Monday 28 July 2003 06:26 am, you wrote:
> On Sun, 27 Jul 2003, Jim Durham wrote:
> > On Sunday 27 July 2003 03:10 am, Wouter Clarie wrote:
> > > Yes, that's what I meant. It should work, since it does here.
> > > VNC Server on the internal network, accessed from outside.
> >
> > Interesting. Is
On Sat, 26 Jul 2003, Jim Durham wrote:
> On Saturday 26 July 2003 04:07 am, Wouter Clarie wrote:
>
> > VNC works through NAT just fine. Never had any problems with that.
>
> Yes, I do that all the time, but in this case, the VNC *server* was the
> one behind the NAT, instead of the client, which
On Saturday 26 July 2003 04:07 am, Wouter Clarie wrote:
> On Sat, 26 Jul 2003, Yar Tikhiy wrote:
> > Could you check if TELNET, HTTP, or SSH from the outside world to
> > the inside machine works? The problem may have to do with VNC
> > protocol peculiarities preventing it from working through NAT
On Saturday 26 July 2003 03:42 am, Yar Tikhiy wrote:
> On Fri, Jul 25, 2003 at 01:49:38PM -0400, Jim Durham wrote:
> > The procedure we used was to alias a 2nd public address to the
> > outside interface and use a redirect_address statement in
> > natd.conf to redirect connections to the new public
On Saturday 26 July 2003 03:13 am, you wrote:
> On Sat, Jul 26, 2003 at 02:22:05AM +0200, Clement Laforet wrote:
> > for incoming traffic, you must use -redirect_address, but for
> > outgoing you have to set -alias_address.
> > If you want to use a specific public IP to map incoming AND
> > outgoin
On Sat, 26 Jul 2003, Yar Tikhiy wrote:
> Could you check if TELNET, HTTP, or SSH from the outside world to the
> inside machine works? The problem may have to do with VNC protocol
> peculiarities preventing it from working through NAT. (However, the VNC
> FAQ claims VNC will work through NAT.)
V
On Fri, Jul 25, 2003 at 01:49:38PM -0400, Jim Durham wrote:
>
> The procedure we used was to alias a 2nd public address to the outside
> interface and use a redirect_address statement in natd.conf to
> redirect connections to the new public IP to the inside machine.
Just a remark: If this 2nd p
On Sat, Jul 26, 2003 at 02:22:05AM +0200, Clement Laforet wrote:
>
> for incoming traffic, you must use -redirect_address, but for outgoing
> you have to set -alias_address.
> If you want to use a specific public IP to map incoming AND outgoing
> packets, you need to run 2 natd, using ipfw matchin
On Friday 25 July 2003 08:22 pm, Clement Laforet wrote:
> On Fri, 25 Jul 2003 13:49:38 -0400
> Jim Durham <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> > I'm wondering about the characteristics of the redirect_address
> > option
> >
> > of natd. I tried this on -questions, but no one replied, so I
> > tho
On Fri, 25 Jul 2003 13:49:38 -0400
Jim Durham <[EMAIL PROTECTED]> wrote:
Hi,
> I'm wondering about the characteristics of the redirect_address option
>
> of natd. I tried this on -questions, but no one replied, so I thought
> I'd ask on here, hoping to find folks more familiar with kernel
> me
I'm wondering about the characteristics of the redirect_address option
of natd. I tried this on -questions, but no one replied, so I thought
I'd ask on here, hoping to find folks more familiar with kernel
mechanisms here.
Consider a FreeBSD NAT "gateway" between a public IP on one network
inte
the "defrag all" feature of Linux solves the discussed problem, but can be
improved. We do not need to defrag the packets. We just need to queue them.
and, when the first frag has been received, we only need to save the
informations necessary for filtering (ip header stuff + ports for TCP/UDP and
only the first fragment will match the rule, if the rule uses ports or
> whatever info contained in the payload.
>
> The problem occurs if the packet (that should match) is subject to change
> by the engine (either redirection, nat, blocking, ...)
>
> IP Filter handles such
er info contained in the payload.
The problem occurs if the packet (that should match) is subject to change
by the engine (either redirection, nat, blocking, ...)
IP Filter handles such situation with specific code.
It would be a nice thing if this is added to standard code so that packet
filters
Hey,
We are doing packet redirection. The client sends packets through our
node to a given server. The server contents are replicated in 2 other
servers. We want to redirect new syn packets from the client to a specific
server in a round robin fashion. Here 's typical scenarion,
let the cli
On Tue, 11 May 1999, Tomas TPS Ulej wrote:
> I saw bounce package and also linux redir. More information about trasparent
> proxy I found at http://www.pdos.lcs.mit.edu/~cananian/Projects/IPfwd/ is
> there solution for FreeBSD? I need this:
>
> BOX A (195.168.11.1) -> REDIR (195.168.11.5) -> DEST
I saw bounce package and also linux redir. More information about trasparent
proxy I found at http://www.pdos.lcs.mit.edu/~cananian/Projects/IPfwd/ is
there solution for FreeBSD? I need this:
BOX A (195.168.11.1) -> REDIR (195.168.11.5) -> DEST 1 (195.168.12.1)
19 matches
Mail list logo