Access list to deny access to router interfaces.

[jomo frank]

Hello Expert,

I have a router configured as spoke in dmvpn topology connect to Hub router via the vpn tunnel over the internet.

I want to deny all access to the wan interface for any attempts via the internet.

I humble request some guidance to achieve .same.

I Start to design an access list

access-list 106 deny ip any host 190.80.1.235 (wan interface of the router

access-list 106 deny ip any host  172.16.99.2  (lan interface of the router)

unsure how set up the permit line in the access for dmvpn traffic protocols

Regards

[balaji.bandi]

Look at the securing Hub, allow only required ports and rest deny example :

https://packetpushers.net/securing-a-dmvpn-spoke-part-2/

[Georg Pauwen]

Hello,

this could be very tedious, and depends on what routing protocols you are using (typically EIGRP and BGP). It also deoends on whether or not you are using IPSec. Post the full running configuration of your spoke router...

[jomo frank]

Hello Georg,

the config of the spoke below

Building configuration...

Current configuration : 1713 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Lethem_test
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
!
ip cef
!
!
!
!
!
!
username admin privilege 15 secret 5 $1$myf5$ONU/9zx4bDIuLo0YdicY11
!
!
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 5
!
crypto isakmp policy 2
encr aes 256
authentication pre-share
group 5
crypto isakmp key edsbsbsbs@@@@wssss address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set testletmvpn esp-aes 256 esp-sha-hmac
!
crypto ipsec profile CiscoCP_Profile1
set transform-set testletmvpn
!
!
!
!
interface Tunnel0
bandwidth 1000
ip address 10.243.101.7 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication ang_rbyp
ip nhrp map multicast 190.xx.pp.156
ip nhrp map 10.243.101.6 190.xx.pp.156
ip nhrp network-id 100000
ip nhrp holdtime 360
ip nhrp nhs 10.243.101.6
ip nhrp registration no-unique
ip tcp adjust-mss 1360
delay 1000
tunnel source FastEthernet0/1
tunnel mode gre multipoint
tunnel key 100000
tunnel protection ipsec profile CiscoCP_Profile1
!
interface FastEthernet0/0
ip address 10.ppp.kkk.184 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address dhcp
duplex auto
speed auto
!
router eigrp 100
network 10.ppp.kkk.0 0.0.0.255
network 10.243.101.0 0.0.0.255
network 10.0.0.0
no auto-summary
!
!
ip http server
ip http authentication local
ip http secure-server
!
!
!
control-plane
!
!
!
line con 0
privilege level 15
login local
line aux 0
line vty 0 4
privilege level 15
login local
transport input telnet ssh
!
scheduler allocate 20000 1000
!
end

Regards

[Georg Pauwen · Accepted solution]

Hello,

I lab tested this, and I think what you have to do is to configure the access list to allow all IP traffic between the WAN IP addresses, as well as the local networks, and have the implicit deny take care of blocking the rest.

access-list 106 permit ip host WAN_IP_ADDRESS_REMOTE host WAN_IP_ADDRESS_LOCAL

access-list 106 permit ip REMOTE_LAN_IP_SUBNET LOCAL_LAN_IP_SUBNET

Then apply the access list inbound on your WAN interface:

interface FastEthernet0/1
ip address dhcp

--> ip access-group 106 in
duplex auto
speed auto

[Giuseppe Larosa]

Hello Georg,

your proposed configuration allows communication between the local Spoke and the HUB router only, but in DMVPN there is the potential to build dynamic Spoke to Spoke tunnels when needed.

So the original poster should clarify what kind of connectivity he wants to have over the DMVPN.

Hope to help

Giuseppe

[Georg Pauwen]

Hello Giuseppe,

you are absolutely right. This is just for one spoke to the hub. I guess in the end, for the access list to work in the entire DMVPN topology, all local networks need to be added, as well as all WAN IP host addresses.

[Elliot Dierksen]

If you put the underlay/transport network for the DMVPN into a VRF, that could do what you want without complex ACL's. You do need to put an ACL on the VTY ports (WITHOUT the keyword vrf-also), and that will do it. I consider putting the underlay network into a separate VRF to be a best practice. After you build the VRF, you would need to add the "tunnel vrf MY-TRANSPORT-VRF" command to the tunnel interfaces.