• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 860
  • Last Modified:

acl filtering

I have two servers that I am having issues with the ACL which is shown below:


Extended IP access list STOP
     1 permit tcp host 192.168.47.65 any eq 8181
     10 permit tcp host 192.168.47.63 any eq 8181
     20 permit tcp host 192.168.48.24 any eq 8181
     30 permit tcp host 192.168.52.100 any eq 8181
     40 permit tcp host 192.168.52.53 any eq 8181
     50 permit tcp host 192.168.49.126 any eq 8181
     60 permit tcp host 192.168.52.92 any eq 8181
     70 permit tcp host 192.168.48.72 any eq 8181
     80 permit tcp host 192.168.47.36 any eq 22
     90 permit icmp host 192.168.47.36 any
     100 permit udp host 192.168.47.33 any eq domain
     110 permit udp host 192.168.47.33 any eq 389
     120 permit udp host 192.168.47.33 any eq 636
     130 permit tcp host 192.168.47.33 any eq 636
     140 permit tcp host 192.168.47.33 any eq 389
     150 permit tcp host 192.168.47.33 any eq domain
     160 permit tcp host 192.168.46.1 any eq 8181
     170 permit tcp host 192.168.46.2 any eq 8181
     180 permit tcp host 192.168.46.3 any eq 8181
     190 permit tcp host 10.217.1.1 any eq 8181
     200 permit tcp host 10.217.1.2 any eq 8181
     210 permit tcp host 10.217.1.3 any eq 8181
     220 permit tcp host 192.168.49.72 any eq 8181
     230 permit ip host 192.168.108.20 any
     240 permit icmp host 192.168.108.20 any
     250 permit icmp host 192.168.47.33 any


We are able to telnet to the 192.168.47.33 on port 389 with no issues.
We are not able to telnet to the 10.53.1.20 on port 389 at all.

This ACL is on a switch on the vlan interface outbound. There is currently no inbound ACL on this interface and none on the interface for the 192.168 subnet.

This has now been going on for a few days and we need to resolve this as they are planning on rolling out this server next week. Also, this is the only server on the vlan and it is pointing to the 1.1 for its gateway.
0
INV_support
Asked:
INV_support
  • 2
  • 2
  • 2
  • +1
5 Solutions
 
leuqarteCommented:
I don't see where 10.53.1.20 is allowed in the ACL.  There is an implied deny all after line 250.
0
 
pony10usCommented:
I agree. There is a permit for 192.168.47.33

110 permit udp host 192.168.47.33 any eq 389

but none for 10.53.1.20

Add:

115 permit udp host 10.53.1.20 any eq 389
0
 
INV_supportAuthor Commented:
Even with the access list appended to include:
115 permit udp host 10.53.1.20 any eq 389
116 permit udp host 10.53.1.20 any eq 389

I get destination unreachable; gateway or host down.

I tried those acl changes yesterday but figured I would give it another shot today. I also verified that the server is in fact listening on this port.

Also, of note, is that I am able to ping the server from the switch but not able to run a trace to it as it just times out and stops after 30. This should be a one hop from the switch, going through the default gateway which is the 1.1 address.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
qbakiesCommented:
This is a bit confusing and could use a drawing.  However, it seems that you are saying the VLAN containing 10.53.1.20  has an outbound ACL on it and you aren't able access 389 on the server.  If this is true can you tell me from what IP you are trying to do this?

 90 permit icmp host 192.168.47.36 any
     110 permit udp host 192.168.47.33 any eq 389
     140 permit tcp host 192.168.47.33 any eq 389
     230 permit ip host 192.168.108.20 any

These are the only lines that would allow that and I'm not sure what 389 is being used for so I don't know what protocol should be allowed.  Can you provide some more insight?

What IP are you coming from?
What is 389 used for?
0
 
qbakiesCommented:
If the ACL is applied outbound on the VLAN containing 10.53.1.20 then 10.53.1.20 doesn't need to be placed in the source portion of the statement, but rather the destination portion.
So:

5 permit <PROTOCOL> host <SOURCE IP> host 10.53.1.20 eq 389
0
 
leuqarteCommented:
389 is LDAP
Can the 10.53.1.20 server be pinged from 192.168.47.33?
0
 
INV_supportAuthor Commented:
As it turned out, applying the following worked:
permit ip host 192.168.xxx.xxx any

The sad part is that they will not need the 389 after the testing is done and will be using the 636 that has been working the entire time. Thanks everyone for the help.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now