> > I'd suggest configuring dnscache to listen on the 64.4.197.65 IP for
> > your DMZ hosts. You can setup a second dnscache to listen on
> > 192.168.1.254 for your internal network. The two tinydns instances
can
> > be run on loopback interfaces (there's more than just 127.0.0.1
> > available, r
Charles Steinkuehler wrote:
>
> > > > 17: wan1: mtu 1500 qdisc pfifo_fast qlen
> 100
> > > > link/ppp
> > > > inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1
> > > > inet 64.4.197.99/32 scope global wan1
> > > > inet 64.4.197.100/32 scope global wan1
> > > > inet 64.
Charles Steinkuehler wrote:
> So...it looks like either dnscache is mis-configured (bad send-from IP),
> or more likely, that your masquerade rule connecting the internal
> network with the DMZ is mangling (masquerading) the return traffic.
Why am I thinking about correcting the error and dnsc
> > > 17: wan1: mtu 1500 qdisc pfifo_fast qlen
100
> > > link/ppp
> > > inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1
> > > inet 64.4.197.99/32 scope global wan1
> > > inet 64.4.197.100/32 scope global wan1
> > > inet 64.4.197.101/32 scope global wan1
> >
> > Please
> > > # ping -c 3 64.4.197.127
> > > PING 64.4.197.127 (64.4.197.127): 56 data bytes
> > > 64 bytes from 64.4.197.65: icmp_seq=0 ttl=255 time=0.3 ms
> > > 64 bytes from 64.4.197.69: icmp_seq=0 ttl=255 time=0.7 ms (DUP!)
> > > 64 bytes from 64.4.197.68: icmp_seq=0 ttl=128 time=0.9 ms (DUP!)
> > > 64
> OK, it gets more interesting ;>
Indeed! Lots of in-line comments, or just skip to the "executive
summary" at the end :-)
> [3] As it turns out, some name resolution stuff works (e.g.,
nslookup);
> but, other stuff does *NOT* work (e.g., host, dig, ping). tcpdump
> output is here:
>
Charles Steinkuehler wrote:
>
> Comments inline.
>
> > Yes, I, too, have been confused by some of this. We have several
> > successful proxy-arp dmz's; so, when we built this one, we started by
> > cloning those other config's and changing addresses, &c. and it
> appeared
> > to be working as e
Comments inline.
> Yes, I, too, have been confused by some of this. We have several
> successful proxy-arp dmz's; so, when we built this one, we started by
> cloning those other config's and changing addresses, &c. and it
appeared
> to be working as expected.
>
> # ip route
> 64.4.222.158 dev ips
Thank you, for your participation . . .
Ray Olszewski wrote:
>
> Sorry to jump into this late.
>
> You say:
>
> >[4] I need help understanding what is going on in lines like this:
> >
> >64.4.197.69 > 64.4.197.65: icmp: 64.4.197.69 udp port 32868
> > unreachable [tos 0xc0]
> >
> >
Hi
I had a little problem to get mine working too
this is the contents of my /etc/pcmcia/config.opts
--
#
# Local PCMCIA Configuration File
#
# Xircom RealPort drivers
#
device "xirc2ps_cs"
class "network" modul
Sorry to jump into this late.
You say:
[4] I need help understanding what is going on in lines like this:
64.4.197.69 > 64.4.197.65: icmp: 64.4.197.69 udp port 32868
unreachable [tos 0xc0]
I am confused with both icmp and udp specified on same line ???
I believe what this reports
OK, it gets more interesting ;>
[1] As you know, here is a summary of the dcd:
root@bluetrout:/etc
# ip addr
. . .
7: eth0: mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global
Thank you, Charles, et al. for your continued participation . . .
Charles Steinkuehler wrote:
>
> > root@bluetrout:/root
> > # ip addr
> > . . .
> > 7: eth0: mtu 1500 qdisc pfifo_fast qlen 100
> > link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff
> > inet 192.168.1.254/24 brd 192.168.1
Ray Olszewski wrote:
Not being a Shorewall expert, I can't help you with that part. But as to
the underlying iptables rules (the first part of what you describe
doing), you've only done half of what you need. In addition to the
changes to PREROUTING, you need entries similar to this (for each
Not being a Shorewall expert, I can't help you with that part. But as to
the underlying iptables rules (the first part of what you describe doing),
you've only done half of what you need. In addition to the changes to
PREROUTING, you need entries similar to this (for each port and
protocolinvo
Szûcs Tibor wrote about "[leaf-user] Ne2 pci card":
> If I put the insmod ne2k-pci command
> not loading the module, and write some error line
> " unresolved symbol ei_open"
> ethdev_init
> ei_interrupt
>
Hi!
I download and install teh last wisp image, and I have a little problem
If I put the insmod ne2k-pci command
not loading the module, and write some error line
" unresolved symbol ei_open"
ethdev_init
ei_interrupt
Hi,
If your e-Donkey server/client isn't running on your shorewall firewall
then you have to change everything I your shorewall config to:
loc:192.168.1.6 > net and
net > loc:192.168.1.6
f.ex.
#ACTION SOURCE DESTPROTO DESTSOURCE
ORIGINAL
#
PORTPORT(S)DEST
ACCEP
I have really big problem with using edonkey on my network, I had installed
some time ago shorewall and I think that it is really good program. But ...
edonkey don't work ... :(
I have done :
iptables -t nat -F {PREROUTING,POSTROUTING}
iptables -F
iptables -P {INPUT,FORWARD,OUTPUT} ACCEPT
and
I have really big problem with using edonkey on my network, I had installed
some time ago shorewall and I think that it is really good program. But ...
edonkey don't work ... :(
I have done :
iptables -t nat -F {PREROUTING,POSTROUTING}
iptables -F
iptables -P {INPUT,FORWARD,OUTPUT} ACCEPT
and
On Fri, 11 Oct 2002, Doug Hite wrote:
> Thanks for the quick response Jeff. Yes, it is very much a sequential
> thing - I don't know what a scan would look like from the logs, but if I
> had to guess what it would look like, this would be it. Here is a very
> brief snippit -
>
> Oct 11 06:56:0
21 matches
Mail list logo
