ACL in blocks the other side (WAN)

[chrislgicale]

Good day,

I'm not expert in ACLs. I guess I'm within basic on it. My concern is, we have Head Office and Project Site. This two sites are connected via point-to-point leased line. Our data/voice (internet) is supplied by  Head Office. Whenever, I input a listed port ACL in Project Site, the Head Office can still able to ping the project site but literally can access (i.e. folder sharing, remote/RDP). Here is the network details;

Head Office subnet 192.168.1.0 / 24

Project Site subnet 172.32.16.0 / 22

Extended IP access list 107
    10 permit tcp host 172.32.16.11 any
    20 permit tcp 172.32.16.0 0.0.3.255 any eq 4370
    30 permit tcp 172.32.16.0 0.0.3.255 any eq domain
    40 permit tcp 172.32.16.0 0.0.3.255 any eq 993
    50 permit tcp 172.32.16.0 0.0.3.255 any eq 995
    60 permit tcp 172.32.16.0 0.0.3.255 any eq 23399
    70 permit tcp 172.32.16.0 0.0.3.255 any eq 587
    80 permit tcp 172.32.16.0 0.0.3.255 any eq 445
    90 permit tcp 172.32.16.0 0.0.3.255 any eq 465
    100 permit tcp 172.32.16.0 0.0.3.255 any eq ftp
    110 permit tcp 172.32.16.0 0.0.3.255 any eq www
    120 permit tcp 172.32.16.0 0.0.3.255 any eq 443
    130 permit tcp 172.32.16.0 0.0.3.255 any eq 143
    140 permit tcp 172.32.16.0 0.0.3.255 any eq 389
    150 permit tcp 172.32.16.0 0.0.3.255 any eq 522
    160 permit tcp 172.32.16.0 0.0.3.255 any eq 636
    170 permit tcp 172.32.16.0 0.0.3.255 any eq 135
    180 permit tcp 172.32.16.0 0.0.3.255 any eq 3389
    190 permit tcp 172.32.16.0 0.0.3.255 any eq pop3
    200 permit tcp 172.32.16.0 0.0.3.255 any eq 5223
    210 permit tcp 172.32.16.0 0.0.3.255 any eq 9339
    220 permit tcp 172.32.16.0 0.0.3.255 any eq smtp
    230 permit tcp 172.32.16.0 0.0.3.255 any eq telnet
    240 permit tcp 172.32.16.0 0.0.3.255 any eq 5242
    250 permit tcp 172.32.16.0 0.0.3.255 any eq 4244
    260 permit tcp 172.32.16.0 0.0.3.255 any eq 5243
    270 permit tcp 172.32.16.0 0.0.3.255 any eq 9785
    280 permit tcp 172.32.16.0 0.0.3.255 any eq 1720
    290 permit tcp 172.32.16.0 0.0.3.255 any eq 1503
    300 permit tcp 172.32.16.0 0.0.3.255 any eq 1731
    310 permit tcp 172.32.16.0 0.0.3.255 any eq 1719
    320 permit tcp 172.32.16.0 0.0.3.255 any eq 2727
    330 permit tcp 172.32.16.0 0.0.3.255 any eq 2427
    340 permit tcp 172.32.16.0 0.0.3.255 any eq 2000
    350 permit tcp 172.32.16.0 0.0.3.255 any eq 5060
    360 deny tcp 172.32.16.0 0.0.3.255 any
    370 permit ip any any

Whenever I implement the "ip access-group 107 in" on the Project Site. Head Office literally block their access, except the ping. Although, we have not indicate their subnet to be block, it looks like they're block.

Appreciate any inputs. Thanks!

Chris

[Jon Marshall]

Chris

Which interface are you applying the acl to ?

Can you perhaps post the configuration of the L3 device at the remote site removing any sensitive information ?

Jon

[chrislgicale]

Hi Jon, please see below. Thanks!

Head Office WAN IP: 192.168.10.6 / 30

Project Site WAN IP: 192.168.10.5 / 30

PID#sh ip int bri
Interface                  IP-Address      OK? Method Status                Prot
ocol
Embedded-Service-Engine0/0 unassigned      YES NVRAM  administratively down down

GigabitEthernet0/0         192.168.10.5    YES NVRAM  up                    up

GigabitEthernet0/1         172.32.16.1     YES NVRAM  up                    up

PID#sh run
Building configuration...

Current configuration : 2251 bytes
!
! No configuration change since last restart
version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
boot-start-marker
boot-end-marker
!
aaa new-model
!
aaa authentication login default local
aaa authorization exec default local
!
aaa session-id common
!
no ipv6 cef
ip source-route
ip cef
!
no ip domain lookup
multilink bundle-name authenticated
!
crypto pki token default removal timeout 0
!
interface Embedded-Service-Engine0/0
 no ip address
 shutdown
!
interface GigabitEthernet0/0
 ip address 192.168.10.5 255.255.255.252
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 ip address 172.32.16.1 255.255.252.0
 ip access-group 107 in
 duplex auto
 speed auto
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 192.168.10.6
ip route 192.168.1.0 255.255.255.0 192.168.10.6
ip route 192.168.5.192 255.255.255.192 192.168.10.6

[Jon Marshall]

Chris

Just happened to be logged on :-)

There is nothing wrong with your configuration and acl.

When you say traffic is blocked what exactly doesn't work ie. what is the source IP, the destination IP and more importantly the application you are trying to access from the remote site ?

Jon

[chrislgicale]

The Head Office LAN side unable to remote on Project Site side, if "ACL 107 in" is implemented. I wonder how to allow specific IP from them thru remote, basically for monitoring. Thanks.

[Jon Marshall]

Chris

I though the acl was to allow the remote office to access applications at the Head Office.

If this is not the case then can you specify exactly what is happening in terms of who is accessing what from where ie.

if the access is to an application in the remote site then what is the application at the remote site ie what port and what IP in the remote site.

Jon

[chrislgicale]

Jon,

You're right the remote office can access applications at the Head Office. My problem is the Head Office can't access the remote office (i.e. RDP to remote office server).

Head Office LAN subnet: 192.168.1.0 / 24

Project Site LAN subnet: 172.32.16.0 / 22

Do I have to input the Head Office LAN subnet on my ACL 107?

Thanks!

[Jon Marshall · Accepted solution]

Chris

You need to add this line to your acl before line 360 -

<num < 360> permit tcp 172.32.16.0 0.0.3.255 eq 3389 any

assuming RDP is running on port 3389.

Note also you can be more specific if it is only specific 172.16.32.x IPs and you can use the Head Office subnet instead of any.

It's up to you really as to how much you want to lock it down.

Edit - should have explained. The issue is that your acl allows traffic from 172.16.32.x IPs to any IPs with a destination port of 3389. But in this case because the RDP connection is initiated from Head Office it is the return traffic you have to match and so 3389 is now the source port and not the destination port.

Line 360 blocks all TCP not allowed in the lines above and you hadn't allowed it.

Jon

[chrislgicale]

Jon,

May I know what's the difference between this lines;

     permit tcp 172.32.16.0 0.0.3.255 any eq 3389

and

     permit tcp 172.32.16.0 0.0.3.255 eq 3389 any

Well appreciate your response.

Thanks!

Chris

[Jon Marshall]

Chris

The first line says -

allow any 172.32.16.x IP (within the range) with any source port to access any other IP with a destination port of 3389.

The source port will be a randomly generated port.

The second line says  -

allow any 172.32.16.x IP with a source port of 3389 to access any other IP on any port.

You may not have seen the explanation I added to the last post but basically you need to match the return traffic to Head Office and this will have a source port of 3389 and not a destination port because the connection was initiated from the Head Office site.

Jon

[chrislgicale]

Great Jon!

Will try these tomorrow and let you know the result.

Appreciate it much.

Thanks!

Chris

[Jon Marshall · Accepted solution]

Chris

Just to add something that may help.

If you initiate a connection to a server running an application then the source port is usually random and the destination port is well know eg. port 80 for www etc.

For RDP it is 3389.

So when a client at Head Office tries to connect to a device at the remote site using RDP the source port is random and the destination port is 3389.

Your acl has no affect on this traffic going to the device because your acl is applied inbound.

However the return traffic is checked against your acl.

And the return traffic flips the ports so now the source port is 3389 and the destination port is the random port on the device at Head Office.

Apologies if I am telling you something you already know.

Jon

[chrislgicale]

Jon,

Your assistance and explanation was really excellent. I insert this line,

    permit tcp host 172.32.16.12 eq 3389 host 192.168.1.6

to allow RDP specific remote office server (16.12) from specific head office IP (1.6).

Can I ask a little more about my ACL 107? Or should I need to create another discussion?

I was thinking if my ACL 107 is by checking allow all UDP traffic? Is it recommended to block also UDP? If recommended, may I know the basic I should consider to allow UDP versus the deny.

Well appreciate your sharing of knowledge :)

Chris

[Jon Marshall]

Chris

Glad you got it working.

Your acl is allowing all traffic for UDP because of the permit ip any any at the end.

If you want to tie the acl down to restrict that as well then you need to follow the same principle as you have with TCP and have lines for that as well.

If there are connections like the RDP one from Head Office then you would need to account for return traffic as well as we did with that additional line..

As to whether it is recommended it really comes down to your own security concerns. If you only want the remote site to have external access on certain ports and block everything else then it may be worth doing if you know all the ports they access.

Let me know if there are an specific concerns you have.

Jon

[Jon Marshall]

Chris

Sorry, just reread your last post.

I assumed you got it working, did you ?

Jon