Lockdown GRE traffic in ACL

[johnlloyd_13]

hi,

i need to configure a temporary GRE tunnel via the internet for management access while provisioning a remote site.

i also need to lockdown this GRE tunnel (on top of the VTY ACL) and would need someone to advise if i only need to allow GRE using the tunnel source and destination IP in the ACL?

R1

interface Loopback1
ip address 1.1.1.1 255.255.255.255

interface Tunnel1
ip address 192.168.1.1 255.255.255.252
tunnel source 1.1.1.1 <<< LOCAL ISP PUBLIC IP
tunnel destination 2.2.2.2 <<< REMOTE ISP PUBLIC IP

ip access-list extended GRE_ACL
permit gre host 2.2.2.2 host 1.1.1.1   <<< IS THIS ALL I NEED TO SSH/TELNET THE REMOTE SITE FROM HQ?
permit icmp any any

interface Tunnel1
ip access-group GRE_ACL in

R2

interface Loopback2
ip address 2.2.2.2 255.255.255.255

interface Tunnel2
ip address 192.168.1.2 255.255.255.252
tunnel source 2.2.2.2
tunnel destination 1.1.1.1

ip access-list extended GRE_ACL
permit gre host 1.1.1.1 host 2.2.2.2
permit icmp any any

interface Tunnel2
ip access-group GRE_ACL in

[Giuseppe Larosa · Accepted solution]

Hello @johnlloyd_13 ,

the proposed ACLs should be applied to the physical interfaces used by GRE endpoints to go out to the internet  and not on the tunnel itself.

within the tunnel the traffic is the internal traffic 192.168.1.0/30 and traffic from / to remote LAN subnet depending on the way you use the GRE p2p tunnel you can even run a dynamic routing protocol  over it.

Use of SSH is recommended as GRE does not provide security by itself

Hope to help

Giuseppe

[johnlloyd_13]

hi giuseppe,

you were right, the ACL to lockdown GRE traffic should be applied on the outside interface facing ISP. i was trying to applied in the GRE tunnel at first and i get locked out.

i allowed GRE protocol from R1 and R2's public IP that were used as the tunnel source and destination.

1.1.1.1 is the public LAN IP given by ISP which is configured as sub-if in R1.

R1#sh ip access-l TEMP_GRE_ACL
Extended IP access list TEMP_GRE_ACL
10 permit gre host 2.2.2.2 host 1.1.1.1 (19608 matches)
20 permit icmp any any echo-reply

interface GigabitEthernet0/0.10
encapsulation dot1Q 10
ip vrf forwarding ISP
ip address 4.6.21.22 255.255.255.252
ip access-group TEMP_GRE_ACL in

[paul driver]

Hello
You could also encrypt the tunnel and then apply a context based acl on top of it.

ip access-list extended IPsec
permit udp any any eq isakmp
permit esp any any
permit icmp any host x.x.x.x
deny ip any any log

ip inspect name cbac tcp
ip inspect name cbac udp
ip inspect name cbac icmp

crypto isakmp policy 10
encr aes
authentication pre-share
group 5

crypto isakmp key 5tan123 address <remotepublicip>
crypto ipsec transform-set GRE_IPSEC esp-aes esp-sha-hmac
crypto ipsec profile Site-to-Site
set transform-set GRE_IPSEC

interface Tunnel 0
ip address x.x.x.x y.y.y.y
tunnel source <local public ip>
tunnel destination <remmote public ip>
tunnel mode ipsec ipv4
tunnel protection ipsec profile Site-to-Site
ip access-group IPsec in
ip inspect cbac out

[johnlloyd_13]

hi,

thanks for the reply! the router doesn't have ipsec license to run crypto commands.

we also don't want to avail one since it's just for temporary remote mgmt access.

[Richard Burts]

If the router does not have a license that enables crypto processing then there is no option for any kind of vpn to protect the traffic. In that case a GRE tunnel should provide the desired access. I do have a few observations:

- you identify the 1.1.1.1 address as the ISP Public IP. If this is  the ISP address then I am surprised that it is on a loopback interface. I would expect the Public IP to be configured on the outside interface of the router.

interface Loopback1
ip address 1.1.1.1 255.255.255.255

Is there a reason to put the Public IP on a loopback that we do not know about?

- In your GRE_ACL you have this

permit icmp any any

I do not understand why icmp is related to GRE tunnel traffic.

- you tell us "i also need to lockdown this GRE tunnel". I am not clear what you mean with this. To me locking down suggests that you want to control what traffic can go through the tunnel. But the suggested acl , which should be applied to the outside interface, only makes sure that GRE traffic would be allowed to enter the outside interface. There is not anything about what kind of traffic would use the tunnel.

- you tell us that the tunnel is for management traffic. How are you going to control so that no data traffic uses the tunnel and that management traffic does not use some other path

- At this point we do not know what is configured on the outside interface of the router. Would we be correct to assume that there is already an acl to examine incoming traffic? In that case you just need to add the statement permitting GRE to the existing acl.