Problems in getting an ACL that allows ssh only one way to work

[ThomasD86]

Hi,

I am hitting another issue with an ACL that doesn't make much sense. I've got Router A: An ASR 920 that has 2 BDI configured on it. One has a public network configured and serves as default gateway for the UNI on the router. The other has a private IP and serves has a p2p link towards our Router B, an ASR9906 where it terminates on a PWHE interface.

I've a static route that tells router A to forward all of its traffic towards the 9906, the 9906 has a static route that tells it where to find the public network configured on router A.

IP are as follows:
Router  A:

BDI100: 200.1.1.1/29
BDI101 172.16.20.1/31

BDI100 is also the ssh source interface.

Router B:
Pw-Ether100: 172.16.20.0/31

The idea is that since this router will be delivered to customers if somehow they manage to access it, to have some ACL in place on the PW-Ether interface that forbids the customer from accessing private ip ranges or SSH into any upstream device(s). On the other hand, we want to be able to SSH into the router.

So I've created this ACL:

10 deny ipv4 any 10.0.0.0 0.255.255.255
20 deny ipv4 any 172.16.0.0 0.15.255.255
30 deny ipv4 any 192.168.0.0 0.0.255.255
40 permit ipv4 200.1.1.0 0.0.0.7 any

The way this reads in my mind is: forbid any kind of traffic from any source ip towards the 3 private ip ranges but allow traffic from the public subnet we assigned to the customer towards any public IP address. This is configured in INGRESS on the PW-Ether interface.

I familiarised myself with this document

https://www.cisco.com/c/en/us/support/docs/ip/access-lists/26448-ACLsamples.html#anc9

And using the "established" parameter seems just what I need, so I added the following entry:

permit tcp host 200.1.1.1 any eq ssh established

I used the 200.1.1.1 ip as this is the BDI address that is also configured as ssh source interface. I've added it as next to last entry in the ACL:

10 deny ipv4 any 10.0.0.0 0.255.255.255
20 deny ipv4 any 172.16.0.0 0.15.255.255
30 deny ipv4 any 192.168.0.0 0.0.255.255
40 permit tcp host 200.1.1.1 any eq ssh established
50 permit ipv4 200.1.1.0 0.0.0.7 any

It is my understanding that with the "established" word at the end of it, the ACL will permit the return packet the router sends in answer to the SYN request originating from the upstream router.

Checking the ACL counters on the ASR9k shows that despite having set the BDI with the public gateway as the ssh source interface, the packet is hitting line 20. Which is the p2p link between the ASR920 and 9k.

 20 deny ipv4 any 172.16.0.0 0.15.255.255 (1 hw match)

I am not sure why the ACL is being matched on that line. Usually when configuring ACL I Never bother looking at the p2p link between the routers, I just deny a source IP regardless of its geographical location in the topology I am not sure why this logic is not applying here. If I remove the ACL and try to ssh from the 920 to the 9k I am successful and if I issue the "show user" command my source IP will match the one of the interface I've set as a source.

Shouldn't the ACL match on that rather than on the p2p link?

Anyhow I changed my ACL to:

10 deny ipv4 any 10.0.0.0 0.255.255.255
20 permit tcp host 172.16.20.1 any eq ssh established
30 deny ipv4 any 172.16.0.0  0.15.255.255 
40 deny ipv4 any 192.168.0.0 0.0.255.255
50 permit ipv4 200.1.1.0 0.0.0.7 any

The way this reads to me is: traffic for whatever ip is configured on the 920 is denied towards all private IP ranges. However, we are allowing SYN/ACK replies that have 172.16.20.1 to go through. The public network on the router, can also reach any public ip address.

This is what happens:

10 deny ipv4 any 10.0.0.0 0.255.255.255
 20 permit tcp host 172.16.20.1 any eq ssh established
 30 deny ipv4 any 172.16.0.0 0.15.255.255 (4 hw matches)
 40 deny ipv4 any 192.168.0.0 0.0.255.255
 50 permit ipv4 78.40.160.0 0.0.0.7 any

I am not sure why line 20 is being ignored. This happens regardless if I try to ssh the public gateway on the 920 or, the private p2p link. 

Could anyone kindly explain or, point me out to some documents it seems my own research didn't provide adequate results

Thanks a lot

[paul driver]

Hello

Not sure i understand exactly what you trying to acheive, but if you wish for the 200.1.1.0/29 subnet to have ssh access then  just append an acl on the vty lines of that router for it.

rtr
access-list 100 permt tcp 200.1.1.0 0.0.0.7 any eq ssh
line vty 0 4
access-class 100 in
transport input ssh

[ThomasD86]

Hi Paul, thanks for the reply.

I want to be able to ssh from ROUTER A to router B but, I do not want the opposite to be possible.
Router A ssh source ip is 172.16.20.0. Router B ssh source IP is 200.1.1.1. My objective is to create an ACL on router A that:

- blocks traffic from any IP on Router B towards the 3 private ip addresses range

- permits return ssh traffic

- permits the public network configured on router B to reach public IP addresses.

This is the ACL I created and set in ingress on Router A:

10 deny ipv4 any 10.0.0.0 0.255.255.255  - denies traffic towards the /8 private IP range
20 permit tcp any any eq ssh established - allows returning traffic from a SSH session started by Router A
30 deny ipv4 any 172.16.0.0 0.15.255.255 - denies traffic towards the /12 private IP range
40 deny ipv4 any 192.168.0.0 0.0.255.255  - denies traffic towards the /16 private IP range 
50 permit ipv4 200.1.1.1.0 0.0.0.7 any  - allows traffic from the public network configured on router B

My problem is that when I try to start a SSH session from Router A (172.16.20.0) towards either Router B public ip address (200.1.1.1) or the private ip  (172.16.20.1) the returning traffic is being matched and denied on line 30.

I am not understanding why it's not being matched against line 20 since it should be the SYN/ACK reply to a SSH session started from Router A. Yes I am denying the 172.16.0.0 /12 range which Router A source address belongs to but I am doing so after a permit tcp any any statement. 

Shouldn't the return traffic be matched on line 20 rather than 30?

[paul driver]

Hello

from rtr b

access-list 100 deny ip any host <rtra>
access-list 100 permit tcp any any eq ssh
access-list 101 permit tcp host <rtra> any eq ssh

line vty 0 4

access-class 100 out

access-class 101 in

[ThomasD86 · Accepted solution]

Hi Paul and thanks again for helping.

I've finally figured it out!

In this scenario Router A since its the one initiating the SSH session acts as client rather than a server, so I was not matching that on my ACL statement. The correct one is:

20 permit tcp any eq ssh any established

This makes it work. I didn't know you could have the eq ssh flag after the source, so I have to blame my own ignorance