Brian,
Thanks... Would please you enlighten me a litte further?
1. I am not deny any outgoing on the out, so everything
can go out.
2. Thus, packages incoming the only ones allowed through
would be the ones originated from the inside (established).
3. The problem that I can see in the protocol analyzer
is the dns reply to the dns request originated from
the inside.
The dns request/reply are ip packages on udp, so I allow
then through using permit tcp/udp for them. For some
reason, the router looks at dns request/reply as ip;
Hence, permit ip any any would work. There is no IP
filtering for dns.
The samples that I have seen indicate that it should work.
Access-list that others used seem to work. I am at a lost
on this, since the protocol analyzer clearly indicate the
problem is with the dns reply not able to come back into
the router.
Anyway, appreciate your comments and comments from anyone
else wish to contribute. Meanwhile, I will break down the
package see if I can come up with anything.
TIA/Trang
> -----Original Message-----
> From: Brian [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 28, 2000 2:03 PM
> To: Nguyen_Trang
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: Access-List filter & NT login
>
>
>
> nguyen,
>
> you can't just use "established" on an access list. You have to have
> other entries. A packet only qualifies as "established" once
> it has gone
> thru the access list at least one time and matched another
> rule BESIDES
> established. After that, it can match against "established"
> and not have
> to go thru every rule in the list. You need to forget about
> "established".........construct a valid working access list without
> it.......then once its working properly you can go ahead and add the
> "established" rule as the first match in the access list.
>
> Brian
>
>
> On Mon, 28 Aug 2000, Nguyen_Trang wrote:
>
> > Brian/All:
> >
> > Oops, sorry Brian. That second line was not there in the
> test access-list.
> > The first line was the only line there. I have since
> performed additional
> > test. Here are the results:
> > Recap:
> > > > Network A = 222.9.241.0 (network connecting to outside)
> > > > Network B = 222.9.242.0
> > > > Router Interface 0/0 = 222.9.241.15
> > > > Router Interface 0/1 = 222.9.242.15
> > > > ip access-list extended Test
> > > > permit tcp any 222.9.242.0 0.0.0.255 established
> > > > ip access-group Test in (to router interface 0/0)
> > Objective: Network B able to surf the web.
> >
> > With only the above permit, I put a protocol-analyzer
> > on the interface. I notice that dns query UDP 53 is not
> being replied.
> > so I added the following statements and the log show:
> >
> > permit tcp any 222.9.242.0 0.0.0.255 established (205 matches)
> > permit tcp any any eq domain
> > permit udp any any eq domain
> > permit tcp any any eq echo (just for test)
> > permit udp any any eq echo (just for test)
> > permit tcp any any eq whois (just for test)
> > permit udp any any eq rip (250 matches) (just for test)
> > permit tcp any any eq hostname (just for test)
> > permit udp any any eq who (just for test)
> > permit tcp any any (just for test)
> >
> > Still the test machine cannot access the web. So I added
> > permit ip any any
> > Then the test machine can access the web. The protocol analyzer
> > shows that the dns query UDP received a reply from the outside.
> > the hits shows up in the permit ip any any.
> > The problem seems to be in the dns query UDP reply. I thought
> > the permit tcp&udp any any eq domain would take care of the
> > problem but it didn't.
> >
> > Any help would be appreciated.
> >
> > Thanks in advance.
> >
> > > -----Original Message-----
> > > From: Brian [mailto:[EMAIL PROTECTED]]
> > > Sent: Sunday, August 27, 2000 9:34 PM
> > > To: Nguyen_Trang
> > > Cc: '[EMAIL PROTECTED]'
> > > Subject: Re: Access-List filter & NT login
> > >
> > >
> > > On Sun, 27 Aug 2000, Nguyen_Trang wrote:
> > >
> > > > What I am missing? Thanks in advance for your help.
> > > >
> > > > Objective:
> > > > Hosts on network B can surf the net.
> > > > Specific host IP address can log into the Windows NT server
> > > > on network B.
> > > >
> > > > The networks have valid class C address. The addresses
> > > > have been changed in the following exhibits.
> > > > Network A = 222.9.241.0
> > > > Network B = 222.9.242.0
> > > >
> > > > Router (B) sits between two networks A & B.
> > > > The Ethernet interface 0/0 = 222.9.241.26 (Network A).
> > > > The Ethernet interface 0/1 = 222.9.242.26 (Network B).
> > > > The Networks on this router (B) are 222.9.241.0 and 222.9.242.0
> > > > The ip route on router (B) is 0.0.0.0 0.0.0.0 222.9.241.1
> > > >
> > > > The router (A) on network A IP address is: 222.9.241.1.
> > > > The networks on this router (A) are: 222.9.242.0 via
> 222.9.242.26.
> > > > The ip route on router (A) is 0.0.0.0 0.0.0.0 is to the
> serial port
> > > >
> > > > If there is no access-list on router B, hosts on network B have
> > > > no problem going to the internet. If the following filter
> > > is applied,
> > > > the hosts cannot go to the Internet.
> > > > ip access-list extended Test
> > > > permit tcp any 222.9.242.0 0.0.0.255 established
> > > > permit tcp 222.9.242.0 0.0.0.255 any
> > >
> > > this is your problem. The first line is "ok", but it
> won't come into
> > > effect until after the first packet has made it thru the
> > > list. the next
> > > line is "not ok". Your saying "allow any packet to come into
> > > router B's
> > > e0/0 so long as it has a source address of 222.29.242.0.
> > > 222.29.242.0 is
> > > the network that will be going OUT this interface, not into
> > > it. What you
> > > probably meant to do was say "permit tcp any 222.9.242.0
> > > 0.0.0.255".......which says "allow packets in from
> anywhere so long as
> > > they have a destination of 222.9.242.0 (and are tcp of
> > > course)". After a
> > > packet is allowed in on that rule, further packets can be
> > > caught by the
> > > first rule (if htey are tcp).
> > >
> > > Brian
> > >
> > >
> > > >
> > > > I have not work on the Windows NT log in. Any information on
> > > > how to get this done also would be very much appreciated.
> > > >
> > > > the list is applied to 222.9.241.26 in
> > > >
> > > > Thanks in advance / Trang
> > > >
> > > > ___________________________________
> > > > UPDATED Posting Guidelines:
> > > http://www.groupstudy.com/list/guide.html
> > > > FAQ, list archives, and subscription info:
http://www.groupstudy.com
> > > Report misconduct and Nondisclosure violations to
> > [EMAIL PROTECTED]
> > >
> >
> > -----------------------------------------------
> > Brian Feeny, CCNA, CCDA [EMAIL PROTECTED]
> > Network Administrator
> > ShreveNet Inc. (ASN 11881)
> >
>
-----------------------------------------------
Brian Feeny, CCNA, CCDA [EMAIL PROTECTED]
Network Administrator
ShreveNet Inc. (ASN 11881)
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
