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.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
ASKER
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.