ACL WAN interface
Hi,
So I have a new WAN link that I am configuring an ACL on. The WAN link is layer 2 (VLAN segmentation). We have defined a subnet 192.168.200.0/24 which in this instance is the external IP subnet of all our routers. We have setup the VPN between the sites and it is working perfectly. My issue is related to when I come to setup an ACL on external interface permitting ssh (telnet for testing only). When I attempt to telnet/ssh to another router from one of the routers the traffic is dropped. I can however telnet/ssh to the router from a device on internal LAN subnet.
ip access-list extended ACL-WAN
## ACEs removed for esp, isakmp, icmp etc ##
permit tcp 192.168.200.0 0.0.0.255 192.168.200.0 0.0.0.255 eq 23
permit tcp 10.10.10.0 0.0.0.255 any eq 23
deny any any log
This is the error I receive is
%SEC-6-IPACCESSLOGP: list ACL_WAN denied tcp 192.168.200.1(23) -> 192.168.200.14(39066), 1 packet
Any suggestions on how to resolve this?
thank you
So I have a new WAN link that I am configuring an ACL on. The WAN link is layer 2 (VLAN segmentation). We have defined a subnet 192.168.200.0/24 which in this instance is the external IP subnet of all our routers. We have setup the VPN between the sites and it is working perfectly. My issue is related to when I come to setup an ACL on external interface permitting ssh (telnet for testing only). When I attempt to telnet/ssh to another router from one of the routers the traffic is dropped. I can however telnet/ssh to the router from a device on internal LAN subnet.
ip access-list extended ACL-WAN
## ACEs removed for esp, isakmp, icmp etc ##
permit tcp 192.168.200.0 0.0.0.255 192.168.200.0 0.0.0.255 eq 23
permit tcp 10.10.10.0 0.0.0.255 any eq 23
deny any any log
This is the error I receive is
%SEC-6-IPACCESSLOGP: list ACL_WAN denied tcp 192.168.200.1(23) -> 192.168.200.14(39066), 1 packet
Any suggestions on how to resolve this?
thank you
Comments
-
xnx Member Posts: 464 ■■■□□□□□□□I'm guessing there's NAT taking place which explains the port 39066?
Obviously you've applied the ACL in the correct direction?Getting There ...
Lab Equipment: Using Cisco CSRs and 4 Switches currently -
busines4u Member Posts: 67 ■■□□□□□□□□The error you are receiving appears to be blocking traffic that is destined for port 39066. Are you specifying a port or something that is causing this behavior because the destination port should be 23, which is what your ACL is permitting.
-
rji Member Posts: 26 ■□□□□□□□□□There is no NAT configured, its a private WAN connection with layer 2 between the external interfaces. Direction of the acl is "in" on both routers. All other traffic defined in the ACL - esp, isakmp, icmp hit the correct rules are permitted as expected.
I am guessing its related to the TCP 3 way handshake somehow....
thanks -
rji Member Posts: 26 ■□□□□□□□□□To clarify I am telnetting from 192.168.200.14 to 192.168.200.1 on the default telnet port 23.
192.168.200.14(39066) <<< 39066 would be the source port. Re-running the test over again this port number changes. -
busines4u Member Posts: 67 ■■□□□□□□□□Is this happening when you try connecting to all the routers on your WAN segment? Also does the destination port always stay the same (39066) or does it change when you try connecting again?
-
rji Member Posts: 26 ■□□□□□□□□□Yes all WAN routers. The destination port is always 23 the source port is random (39066 etc)
-
Dieg0M Member Posts: 861permit tcp 192.168.200.0 0.0.0.255 eq 23 192.168.200.0 0.0.0.255Follow my CCDE journey at www.routingnull0.com
-
rji Member Posts: 26 ■□□□□□□□□□By amending the ACL on both routers with the following I was able to telnet between R1 (192.168.200.1) and R2 (192.168.200.14) and vice versa.
ip access-list extended ACL-WAN
permit tcp 192.168.200.0 0.0.0.255 192.168.200.0 0.0.0.255 eq 23 log
permit tcp 192.168.200.0 0.0.0.255 192.168.200.0 0.0.0.255 gt 1023 log
The first ACE permits telnet and the second entry with the "gt" aka greater than permits the response to the random source port eg 39066 (or any port above 1024). Not ideal.
Can any one fill in the blanks and explain why this is the case? -
xnx Member Posts: 464 ■■■□□□□□□□Did you try Diego's suggestion??Getting There ...
Lab Equipment: Using Cisco CSRs and 4 Switches currently -
rji Member Posts: 26 ■□□□□□□□□□I did and the traffic was dropped (on the destination router) from the source of the random high port, this is one of the reasons I came up with using the second ACE as a workaround.
-
Dieg0M Member Posts: 861permit tcp 192.168.200.0 0.0.0.255 eq 23 192.168.200.0 0.0.0.255 is on the source router and permit tcp 192.168.200.0 0.0.0.255 192.168.200.0 0.0.0.255 eq 23 is on the destination router if you are doing inbound filtering. Don't they teach you how to configure ACL's in the CCNA security?Follow my CCDE journey at www.routingnull0.com
-
busines4u Member Posts: 67 ■■□□□□□□□□permit tcp 192.168.200.0 0.0.0.255 eq 23 192.168.200.0 0.0.0.255 is on the source router and permit tcp 192.168.200.0 0.0.0.255 192.168.200.0 0.0.0.255 eq 23 is on the destination router if you are doing inbound filtering. Don't they teach you how to configure ACL's in the CCNA security?
Forgive me for not understanding this with the certs I have but it has been a while since I got to utilize my Cisco skills. For the first ACE on the source router why would it have the "192.168.200.0 0.0.0.255 eq 23" I thought this portion of the ACL was for the source IP address and source port number. Then the second portion "192.168.200.0 0.0.0.255" would be the destination (and port number if specified). Since this would be on the source/originating end of things wouldn't the source port be greater than 1024 (edit: 1023) and the destination port would be 23? Perhaps I just misinterpreted what you said? -
xnx Member Posts: 464 ■■■□□□□□□□You're correct about the Source / Destination parts, however I think he means you need to set up an ACL on both sides so the traffic can go one way and know how to get back.Getting There ...
Lab Equipment: Using Cisco CSRs and 4 Switches currently -
Dieg0M Member Posts: 861You're correct about the Source / Destination parts, however I think he means you need to set up an ACL on both sides so the traffic can go one way and know how to get back.
Exactly, TCP is not unidirectional so if there is inbound ACL on both routers you will have to account for that.Follow my CCDE journey at www.routingnull0.com -
busines4u Member Posts: 67 ■■□□□□□□□□Thanks for the clarification. I thought I was missing something, but I see what you are saying now.