Internet Group Management Protocol (IGMP)

IGMP is acronym for Internet Group Management Protocol. IGMP is a communication protocol used by hosts and adjacent routers for multicasting communication with IP networks and uses the resources efficiently to transmit the message/data packets. 

• Multicast communication can have single or multiple senders and receivers and thus, IGMP can be used in streaming videos, gaming, or web conferencing tools. 
• This protocol is used on IPv4 networks and for using this on IPv6, multicasting is managed by Multicast Listener Discovery (MLD). 
• Like other network protocols, IGMP is used on network layer. 
• MLDv1 is almost same in functioning as IGMPv2 and MLDv2 is almost like IGMPv3. 
• The communication protocol, IGMPv1 was developed in 1989 at Stanford University. IGMPv1 was updated to IGMPv2 in year 1997 and again updated to IGMPv3 in year 2002.

IGMP version 1

IGMP (Internet Group Management Protocol) version 1 is the first version that hosts can use to announce to a router that they want to receive multicast traffic from a specific group. It’s a simple protocol that uses only two messages:

• Membership report
• Membership query

When a host wants to join a multicast group, it will send a membership report to the group address that it wants to receive. When the multicast-enabled router receives this message, it will start forwarding the requested multicast traffic on the interface where it received the IGMP membership report on.

The router will periodically send a membership query to destination 224.0.0.1 (all hosts multicast group address). Hosts that receive this message will respond with a membership report to tell the router that they are still interested in receiving the multicast traffic. When the router receives the membership report, it’s expiry timer will be refreshed. When no hosts respond, the router knows that nobody is interested anymore in the multicast traffic, and it will then remove the entry once the timer exceeds.

IGMPv1 Packet Format

• Version – Set to 1.
• Type – 1 for Host Membership Query and Host Membership Report.
• Unused – 8-bits of zero which are of no use.
• Checksum – It is the one’s complement of the sum of IGMP messages.
• Group Address – The group address field is zero when sent and ignored when received in membership query message. In a membership report message, the group address field takes the IP host group address of the group being reported.   

IGMP version 2

IGMP version 2 is the “enhanced” version of IGMP version 1. One of the major reasons for a new version was to improve the “leave” mechanism. In IGMP version 1, hosts just stop listening to the multicast group address but they never report this to the router. Here are the new features:

• Leave group messages: when a host no longer wants to listen to a multicast group address then it will report to the router that it has stopped listening.
• Group specific membership query: the router is now able to send a membership query for a specific group address. When the router receives a leave group message, it will use this query to check if there are still any hosts interested in receiving the multicast traffic.
• MRT (Maximum Response Time) field: this is a new field in query messages. It specifies how much time hosts must respond to the query.
• Querier election process: when there are two routers in the same subnet then only one of them should send query messages. The election ensures only one router becomes the active querier. The router with the lowest IP address becomes the active querier.

IGMPv2 Packet Format

• Type:
• 0x11 for Membership Query
• 0x12 for IGMPv1 Membership Report
• 0x16 for IGMPv2 Membership Report
• 0x22 for IGMPv3 Membership Report
• 0x17 for Leave Group 
• Max Response Time – This field is ignored for message types other than membership query. For membership query type, it is the maximum time allowed before sending a response report. The value is in units of 0.1 seconds.
• Checksum – It is the one’s complement of the sum of IGMP message.
• Group Address – It is set as 0 when sending a general query. Otherwise, multicast address for group-specific or source-specific queries.

IGMP version 3

IGMP version 3 adds support for “source filtering”. IGMP version 1 and version 2 allow hosts to join multicast groups, but they don’t check the source of the traffic. Any source can receive traffic to the multicast group(s) that they joined.

With source filtering, we can join multicast groups but only from specified source addresses. IGMP version 3 is a requirement for SSM (Source Specific Multicast)

Why is this useful? Let me give you an example:

• Above we have a video server that is streaming multicast traffic on the network using destination address 239.1.1.1. There are four hosts listening to this traffic, life is good. Suddenly something happens:
• An attacker didn’t like the video stream and decided to stream his favorite video to destination address 239.1.1.1.1. Since we don’t check the source address, everyone will receive the traffic from our attacker. It’s also possible to send bogus traffic and create a DoS attack like this.
• IGMP version 1 and 2 don’t have any protection against this.
• With IGMP version 3, our hosts can be configured to receive multicast traffic only from specified source addresses.

IGMPv3 Packet Format

• Max Response Time – This field is ignored for message types other than membership query. For membership query type, it is the maximum time allowed before sending a response report. The value is in units of 0.1 seconds.
• Checksum – It is the one’s complement of the one’s complement of the sum of IGMP message.
• Group Address – It is set as 0 when sending a general query. Otherwise, multicast address for group-specific or source-specific queries.
• Resv – It is set zero of sent and ignored when received.
• S flag – It represents Suppress Router-side Processing flag. When the flag is set, it indicates to suppress the timer updates that multicast routers perform upon receiving any query.
• QRV – It represents Querier’s Robustness Variable. Routers keeps on retrieving the QRV value from the most recently received query as their own value until the most recently received QRV is zero.
• QQIC – It represents Querier’s Query Interval Code.
• Number of sources – It represents the number of source addresses present in the query. For general query or group-specific query, this field is zero and for group-and-source-specific query, this field is non-zero.
• Source Address[i] – It represents the IP unicast address for N fields.

IGMP Filter

• Multicast IGMP membership report messages include the multicast group addresses that our receivers want to join. By default, all multicast groups will be accepted. What if we want to restrict this?
• It is possible to filter certain multicast groups. We can configure IGMP filtering on a multicast router or on a switch where IGMP snooping is enabled. 

Multicast IGMP Proxy

IGMP Proxy allows hosts in a UDLR (Unidirectional Link Routing) topology that are not directly connected to a downstream router to join a multicast group from an upstream router by using a back channel.

To understand IGMP proxy, let’s first look at what a UDL (Unidirectional Link) is?
A UDL is a link where traffic only goes one way.

Above we have three multicast routers. There’s a router called upstream, downstream, and R3. The upstream and downstream routers are connected with two links:

• One unidirectional satellite link.
• One regular Internet connection.

Some satellite links are unidirectional which means that we can only send traffic from the upstream router to the downstream router, not the other way around. 
This causes issues with routing protocols like OSPF or EIGRP but also with multicast traffic. 
Receiving multicast traffic through the satellite link is no problem but our downstream router is unable to let the upstream router know that it wants to receive or prune multicast traffic.
To solve this, we can use a back channel. The back channel is a regular interface, like an Internet connection. 
The downstream router can use the back channel to inform the upstream router that it wants to receive certain multicast traffic. It does this by “proxying” an IGMP membership report. 
When the upstream router receives the IGMP membership report, it will create a forwarding entry for the UDL interface.

Here’s what you see above:

• H1 (our receiver) wants to join a multicast group so it sends an IGMP join (membership report) to R3.
• R3 processes the IGMP membership report and sends a PIM join to its RP (the downstream router).
• The downstream router receives the PIM join and creates a (*,G) forwarding entry in its multicast routing table.
• The downstream router proxies an IGMP membership report over the back channel to the upstream router.
• The upstream router receives the IGMP membership report and creates a forwarding entry for the UDL link.
• Multicast traffic is now forwarded over the UDL link from the upstream router to the downstream router.

Introduction to Multicast

 There are three types of traffic that we can choose from for our networks:

• Unicast – A packet sent from one host to only one other host. A hub will forward a unicast out all ports. If a switch has a table entry for the unicasts MAC address, it will forward it out only the appropriate port.
• Broadcast – A packet sent from one host to all hosts on the IP subnet. Both hubs and switches will forward a broadcast out all ports. By definition, a router will not forward a broadcast from one segment to another.
• Multicast – A packet sent from one host to a specific group of hosts. Switches, by default, will forward a multicast out all ports. A router, by default, will not forward a multicast from one segment to another.

If you want to send a message from one source to one destination, we use unicast. If you want to send a message from one source to everyone, we use broadcast.
What if we want to send a message from one source to a group of receivers? That’s when we use multicast.

Differences between Unicast, Broadcast and Multicast

Why do you want to use multicast instead of unicast or broadcast?

Above we have a small network with a video server that is streaming a movie and four hosts who want to watch the movie. Two hosts are on the same LAN, the other two hosts are on another site that is connected through a 30 Mbit WAN link.
A single HD video stream requires 6 Mbps of bandwidth.

• When we are using unicast, the video server will send the packets to each individual host. 
• With four hosts, it means the video server will be streaming 4x 6Mbps = 24Mbps of traffic.
• Each additional host that wants to receive this video stream will put more burden on the video server and requires more bandwidth from the WAN link. 
• Right now, we require 2x 6Mbps of bandwidth for H3 and H4. 
• When four more hosts would join on the right side, our WAN link would be completely saturated.
• The main problem with unicast traffic is that it is not scalable. Are there any advantages? It’s simple since unicast works “out of the box”.
• If our video server would broadcast its traffic then the load on the video server will be reduced, it’s only sending the packets once. 
• The problem however is that everyone in the broadcast domain will receive it…whether they like it or not. 
• Another issue with broadcast traffic is that routers do not forward broadcast traffic, it will be dropped.
• Multicast traffic is very efficient. 
• This time we only have two hosts that are interested in receiving the video stream. 
• The video server will only send the packets once, the switches and routers will only forward traffic to the hosts that want to receive it. 
• This reduces the load of the video server and network traffic in general.
• When using unicast, each additional host will increase the load and traffic rate. 
• With multicast it will remain the same.

Multicast Concept

• A multicast is a packet sent from one computer to a group of hosts. A host must join a multicast group to accept a multicast. Joining a multicast group can be accomplished statically or dynamically.
• Multicast traffic is generally sent from a multicast server to multicast clients. Very rarely is a multicast packet sent back from a client to the server.
• Multicasts are utilized in a wide range of applications, most notably voice or video systems that have one source “serving” out data to a very specific group of clients.
• The key to configuring multicast is to ensure only the hosts that require the multicast traffic receive it.

We also require applications that support multicast. A simple example is the VLC media player, it can be used to stream and receive a video on the network.
When a router receives multicast traffic, somehow it must know if anyone is interested in receiving the multicast traffic. Look at the picture below:

• Above you can see the router is receiving the multicast traffic from the video server. 
• It doesn’t know where and if it should forward this multicast traffic. 
• We need some mechanism on our hosts that tell the router when they want to receive multicast traffic. We use the IGMP (Internet Group Management Protocol) for this. 
• Hosts that want to receive multicast traffic will use the IGMP protocol to tell the router which multicast traffic they want to receive.

IGMP helps the router to figure out on what interfaces it should forward multicast traffic but what about switches?

• Our router knows that it must forward the multicast traffic since a host used IGMP to tell the router it is interested. 
• Once the multicast traffic arrives at the switch, we have another problem. 
• Switches learn MAC addresses by looking at the source address of an Ethernet frame. 
• Since we use multicast addresses only for the destination, how is the switch supposed to learn where to forward multicast traffic to?

To help the switch figure out where to forward multicast traffic, we can use IGMP snooping. 
The switch will “listen” to IGMP messages between the host(s) and router to figure out where it should forward multicast traffic to. 
There’s also a Cisco proprietary protocol called CGMP (Cisco Group Management Protocol) that can be used between switches and routers. 
The router will then be able to inform the switch where to forward multicast traffic. Unlike IGMP snooping, CGMP isn’t used much.

Addressing
Class D addresses have been reserved for multicast. Within the Class D address space, several ranges have been reserved for specific purposes:

• 224.0.0.0 – 224.0.0.255 – Reserved for routing and other network protocols, such as OSPF, RIP, VRRP, etc.
• 224.0.1.0 – 238.255.255.255 – Reserved for “public” use, can be used publicly on the Internet. Many addresses in this range have been reserved for specific applications
• 239.0.0.0 – 239.255.255.255 – Reserved for “private” use and cannot be routed on the Internet.

The following outlines several of the most common multicast addresses reserved for routing protocols:

• 224.0.0.1 – all hosts on this subnet
• 224.0.0.2 – all routers on this subnet
• 224.0.0.5 – all OSPF routers
• 224.0.0.6 – all OSPF Designated routers
• 224.0.0.9 – all RIPv2 routers
• 224.0.0.10 – all IGRP routers
• 224.0.0.12 – DHCP traffic
• 224.0.0.13 – all PIM routers
• 224.0.0.19-21 – ISIS routers
• 224.0.0.22 – IGMP traffic
• 224.0.1.39 – Cisco RP Announce
• 224.0.1.40 – Cisco RP Discovery

Multicasts Routing

A router, by default, will drop multicast traffic, unless a Multicast routing protocol is utilized. Multicast routing protocols ensure that data sent from a multicast source are received by (and only by) its corresponding multicast clients.
Several multicast routing protocols exist, including:

• Protocol Independent Multicast (PIM)
• Multicast OSPF (MOSPF)
• Distance Vector Multicast Routing Protocol (DVMRP)
• Core-Based Trees (CBT)

Multicast routing must be enabled globally on a Cisco router or switch, before it can be used:

Switch(config)# ip multicast-routing

Normally, routers build routing tables that contain destination addresses, and route packets towards that destination. With multicast, routers are concerned with routing packets away from the multicast source. This concept is called Reverse Path Forwarding (RPF).
Multicast routing protocols build tables that contain several elements:

• The multicast source, and its associated multicast address (labeled as “S,G”, or “Source,Group”)
• Upstream interfaces that point towards the source
• Downstream interfaces that point away from the source towards multicast hosts.

Conclusion

You have seen the difference between unicast, broadcast and multicast and how multicast is far more scalable than the other two traffic types. We also discussed the different protocols that are required to make multicast work:

• IGMP so hosts can tell routers they want to receive multicast traffic.
• IGMP snooping so the switch knows where to forward multicast traffic.
• Multicast routing: we need a protocol like PIM that can route multicast traffic.

Multicast has many advantages; the main advantage is the scalability compared to unicast traffic. 
One of the disadvantages is that we require applications that support multicast, and we have to configure the network to support it.

IPsec Protocol

There are two main IPsec Protocols. These protocols are:

• AH (Authentication Header)
• ESP (Encapsulation Security Payload)

AH and/or ESP are the two protocols that we use to protect user data. Both can be used in transport or tunnel mode

AH (Authentication Header) is the first protocol of IPsec. It provides mainly source Authentication and data integrity. With this mechanism, various attacks are removed. It provides strong hashing algorithms to provide data integrity. But there is no encryption and no data confidentiality mechanisms. This is provided by ESP (Encapsulation Security Protocol).

IPsec Authentication Header

• The IPsec Authentication Header provides connectionless support for data integrity and authentication along with protection against a replay attack.
• The Authentication Header authenticates as much of the IP header as possible along with any upper-layer protocols.
• However, IPsec cannot authenticate any field values that change.
• The Authentication Header can be used alone or with the Encapsulating Security Payload protocol and may be used in either transport or tunnel mode.
• Prior to exchanging data, IPsec creates a security association between the two communicating entities. This provides the attributes necessary for the Authentication Header process.

The AH format is described in RFC 2402. The below shows the position of the Authentication Header fields in the IP packet.

• Next Header: It is an 8-bit field which identifies the type of what follows. This identifies the next protocol.
• Length: It is an 8 bits long field and contains the length of the AH header.
• Reserved: It is reserved for future use. Its length is 16 bits, and it is set to zero.
• SPI (Security Parameters Index): this is a 32-bit identifier, so the receiver knows to which flow this packet belongs.
• The Security Parameter Index is an essential part of IPsec as it distinguishes between the traffic streams that use different encryption rules and algorithms.
• The security association defines the Security Parameter Index and therefore only has local significance between the two entities.
• Sequence: The Sequence Number is a mandatory 32-bit field containing an incrementing counter value that supports anti-replay.
• The sender must always transmit this field, but the receiver doesn’t have to act on it.
• Both sender and receiver will initialize the counter to zero.
• When IPsec establishes a new security association, this will trigger the counter to reinitialize at zero.
• The Sequence Number must never recycle.
• Some vendors support the extended 64-bit Sequence Number, which is an extension to the 32-bit Sequence Number..
• ICV (Integrity Check Value): The Integrity Check Value is a variable field that contains the Integrity Check Value for the packet.
• The field must be a multiple of 32 bits in length and it may include some padding.
• The security association will specify the Integrity Check Value authentication algorithms, which include message authentication code using symmetric encryption, such as AES, or one-way hash function, such as SHA-256 or SHA-384.

The Authentication Header is an appropriate protocol to use when confidentiality is not required, such as providing assurance that a neighbor advertisement comes from an authorized router.
If encryption is required, the network administrator should use the Encapsulating Security Payload protocol. 

Encapsulating Security Payload

• The Encapsulating Security Payload provides confidentiality, authentication, integrity, and anti-replay service for IPv4 and IPv6.
• We can provide security services between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.
• During IPsec conversations, IPsec creates a security association that provides the necessary attributes for the Encapsulating Security Payload.
• The device adds the Security Parameter to the IP header, and that differentiates between the traffic streams using different encryption rules and algorithms.
• You can use the encryption-only feature to provide for confidentiality with the Encapsulating Security Payload. However, using encryption without integrity may leave the communication stream vulnerable to attacks.
• Best practice is to use an integrity method when using Encapsulating Security Payload protocol by using an integrity check value in the Encapsulating Security Payload header or providing authentication separately by adding an authentication header.

Top level format of an Encapsulating Security Payload packet:

The Encapsulating Security Payload has most of the same fields as the authentication header, but the fields are in three sections.

• ESP Header
• The header contains two fields, the Security Parameters Index, and a Sequence number, and comes before the encrypted data.
• Security Parameters Index (32 bits) - Identifies a security association. This field is mandatory. The value of zero is reserved for local, implementation- specific use and MUST NOT be sent on the wire. IPsec adds the security parameter index to the header as this distinguishes between traffic streams that use different encryption rules and algorithms.
• Sequence Number (32 bits) - The sequence number is a mandatory 32-bit field value that contains an incrementing counter value. When possible, use the extended 64-bit sequence number, which is an extension to the current 32-bit sequence number. A monotonically increasing counter value; this provides an anti-replay function, as discussed for AH. The first packet sent using a given SA will have a Sequence number of 1.
• Payload Data (variable) - The Payload data is a variable length field containing data from the original IP packet. This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is protected by encryption. The type of content that was protected is indicated by the Next Header field.

The trailer goes after the encrypted data and may contain padding.

• Padding (0-255 bytes) − Padding for encryption, to extend the payload data to a size that fits the encryptions' cipher block size, and to align the next field.
• Pad Length (8 bits) − Indicates the number of pad bytes immediately preceding this field.
• Next Header (8 bits) − Identifies the type of data contained in the payload data field by identifying the first header in that payload.
• Authentication Data (variable) − A variable-length field (must be an integral number of 32-bit words) that contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field. Authenticated data contains an integrity check value when using the optional authentication feature.

The Encapsulating Security Payload header can provide a mix of security services in IPv4 and IPv6.
The network administrator may choose to apply the Encapsulating Security Payload alone or in combination with the authentication header in a nested fashion.
Below is the Wireshark snap, where we see both the authentication header and the Encapsulating Security Payload.

• We use both because the authentication header ensures authentication and integrity but not confidentiality. 
• The Encapsulating Security Payload provides confidentiality, authentication, and integrity services. However, the field values that IPsec hashes are different.
• The authentication header hashes both the payload and header of a packet.
• The Encapsulating Security Payload uses a hash algorithm. 
• However, it doesn’t include the IP header of the packet in that, that IP header is a mutable field, meaning that it changes as it passes through a NAT device.
• We can use the Encapsulating Security Payload in either transport or tunnel mode.
• The set of services offered will depend on what options the network administrator selected and where on the network IPsec must travel.

Operating Modes
In IPsec, both authentication header and the encapsulating security payload support two modes, transport, and tunnel.

IP packet transformation when using the Authentication Header

• We see here first the original IP packet, and then the authentication header transport mode, which has the IP header first, and then the authentication header.
• In tunnel mode, you’ll see the authentication header and the IP header, but IPsec places a brand-new header around the entire packet and essentially treats the original packet as data.

IP packet transformation when using the encapsulating security payload.

• We see here the original IP packet and then the encapsulating security payload transport mode, where we see the encapsulating security payload header after the IP header.
• In tunnel mode, you’ll see the encapsulating security header and then the IP header, but IPsec places a brand-new header around the entire packet and essentially treats the original IP packet as data.
• Many times, when using encapsulating security payload, a data communication stream will use both transport and tunnel modes when travelling from point A to point B.

Transport mode encrypts only the data portion of each packet, yet leaves the header unencrypted.
We use transport mode when a device, such as a firewall, must see the source and destination address to route the packet and NAT must take place. After passing through the firewall and the NAT device, the packet then changes to a tunnel mode before been sent out onto a internet.

Tunnel mode protects the entire original IP packet by encrypting both the header and the data portion. Tunnel mode will add a new header to the IP packet. IPsec treats the original packet as the data portion. We use tunnel mode between the two gateways, where the gateway will most likely act as a proxy for the host behind the router.

So, imagine the packet is starting in the private network.

• The IP packet might start out in transport mode.
• And then, after passing through the firewall and NAT device, IPsec can add a header to be in tunnel mode as the packet travels across an insecure WAN.
• Coming in from the WAN, and then again through the firewall and NAT device, it’ll then again be safely in the private network on the other side.
• The device can then remove the tunnel mode header and deliver the payload.

Identity and Access Management Concept

Identity and Access Management is the concept behind controlling access to assets, including information, systems and devices. IAM focuses on issues related to granting and revoking privileges to access data or perform actions on systems. The goal of IAM is to provide the right people with the right access to the right resources at the right time. Controlling access to assets is a central theme of security. All assets should be protected, but with different levels of protection depending on the system context or criticality.

IAM can be broken down into four core interconnected concepts.

• Identification
• Authentication
• Authorization
• Auditing and Accountability

Various regulations require that all activities of identification, authentication, and authorization are monitored through audit or security logs to provide accountability and support forensic analysis if security issues occur.

Identification

• Identification is the process of a user claiming an identity. 
• A user is an active entity that accesses a system to receive information or perform an action. 
• Users can be persons, programs, services, or anything else that can access a resource. 
• A user must provide an identity to a system to start the authentication, authorization, and accountability processes. 
• Providing an identity might entail typing a username, swiping a smartcard, or positioning your hand, face or finger in front of a scanning device. 
• Identification is usually integrated with user management. 
• User management involves creating and managing user identities, bundling them into groups for effective management and assigning users and groups to roles. 
• User management operations include creating, modifying, and deleting user identities, as well as granting and revoking credentials and roles.

Authentication

• Authentication is the process of validating the identity of a user. 
• The three basic methods of authentication are as follows. 
• Type one authentication factor is something you know, this may be a password or a phrase, or a personal identification number or pin. 
• Type two authentication factor is something you have. Physical devices that a user possesses can help them provide authentication. Examples include a one-time password generator, smartcard, or hardware token. 
• Type three authentication factor is something you are. It is a physical characteristic of a person identified with different types of biometrics. Examples include fingerprints, voice prints, and retina patterns. 
• Multi-factor authentication involves using two or more authentication factors. For example, combining something you know, with something you have. 
• Ideally, the factors should be from different categories. This method increases security as it requires a malicious user to break multiple authentication methods to break the schemes.

Authorization

• Authorization defines what users are allowed to access after authenticating, unauthorized users should not be able to access business assets or perform critical functions. 
• Authorization can be controlled by policies. For example, it could be time of day restrictions, length of time restrictions, file or folder access rights and more. 
• Setting the right authorizations is critical to ensure data protection, prevent fraud, and for regulatory compliance in general. 
• Here are some important authorization principles to consider. 
• Firstly, the principle of least privilege means giving a user or process only those privileges which are essential to perform its intended function. 
• Secondly, separation of duty as a security principle, has as its primary objective, the prevention of fraud and errors. This objective is achieved by disseminating the tasks and associated privileges for a specific business process among multiple users.

Auditing and Accountability

• The final piece of the IAM puzzle is auditing and accountability. 
• The process of tracking users and their activities to provide accountability. 
• If a user misuses privileges or compromise is suspected, we can investigate and ensure that the user is held accountable based on collected audit logs. 
• These capabilities ensure users are accountable for their actions, verify that the security policies are enforced and can be used as forensic tools. 
• Auditing capabilities are also necessary to fulfil regulatory or compliance activities.

Challenges

There are several challenges that may result from insecure implementation of identification, authentication, authorization, and accounting systems. 
Some examples are:

• Identity theft
• Attacks on authentication
• Trusting the means of authentication
• Improper or missing authorization checks
• Incorrect permission assignments
• Unprotected or unencrypted API and external calls
• Untraceable access
• Missing logs of security events
• Unnecessary usage or storage of personal data.

Virtual Private Network (VPN) overview

History of VPN

• The history of VPN began in the late 1990s, when a software engineer at Microsoft developed a secure way for a client to connect to a server.
• The engineer developed Point-to-Point Tunneling Protocol, which is the forerunner of today’s VPNs.
• Microsoft included VPN capabilities, in their operating systems for anyone to use.
• However, during that time, only businesses were using VPN technology.
• Eventually, home users started to embrace the idea of protecting their data, and e-commerce sites began to use SSL VPNs to secure credit card transactions.
• Concurrently, businesses expanded the use of VPN technology to protect communications of the growing number of remote workers.
• After the initial setup, using a VPN is transparent to the client, as they access network resources in the same way they would as if they were sitting in the private network, but remotely using cryptographic tunneling protocols.
• VPN technology has improved and are adaptable for all types of internet users, from desktop to laptop, and mobile operating systems.
• A VPN uses technology such as IPsec and transport layer security to secure network traffic between sites.

Benefits of VPN

Today, there are many reasons to have a VPN.
A VPN protects your communication and can protect your identity while traversing the internet.
VPNs provide confidentiality by encrypting the data, authentication to ensure only authorized entities are communicating, and integrity by detecting any message modification.

VPNs provide four main benefits over setting up a private WAN network, such as those used by Frame Relay, point-to-point circuits, and ATM:

• Security: It is provided through data encryption to protect confidentiality, data integrity checking to validate packets, and authentication to prevent unauthorized access.
• Cost: Public networks, such as the Internet, can be used instead of building a private WAN infrastructure, greatly reducing a company’s WAN Infrastructure cost.
• Bandwidth: Inexpensive high-bandwidth connections, such as DSL and cable, can be used to interconnect offices to allow for fast and secure access to corporate resources.
• Scalability: Companies can easily add large numbers of users and offices without building a significant WAN infrastructure.

Virtual Private Network

A virtual private network (VPN) is a private network that is built over a public infrastructure.

Security mechanisms, such as encryption, allow VPN users to securely access a network from

different locations via a public telecommunications network, most frequently the Internet.

• A VPN is a secure channel or tunnel between two endpoints that encrypts and keeps data confidential as it crosses through an insecure network.
• VPNs can protect at different layers of the OSI model from data link all the way to the application layer.
• There are choices in the way you create a VPN, such as IPsec, SSL/TLS, and browser-based VPNs for consumers.

When the VPN connection is established between 2 parties (between a VPN client and vpn gateway or between 2 VPN gateways), a secured virtual tunnel will be created with capability to encrypt the data (so no hacker can see the data content), preserve data integrity (no data change during transmission) and ensure the communication only happen between that 2 authenticated parties.

In Short, how does a VPN work?
A VPN masks your IP address by acting as an intermediary and rerouting your traffic. It also adds encryption, or a tunnel around your identity, as you connect. The combination of the VPN server and the encryption tunnel blocks your ISP, governments, hackers, and anyone else from spying on you as you navigate the web.

Types of VPNs

• IPsec VPN
• An internet protocol security or IPsec VPN, works by creating a secure channel, using the internet key exchange protocol or IKE to first authenticate the secure connection.
• Then IPsec uses symmetric encryption, such as AES, to secure the data between the endpoints.
• An IPsec VPN is a solid choice; however, it can run into trouble with network address translation and firewall rules.
• Secure Shell (SSH)
• Secure Shell offers VPN tunneling and built-in username and password authentication to establish a connection to a single computer.
• It uses port 22 to authenticate the process.
• PuTTY is something that you can use to create the connection for Secure Shell.
• SSL/TLS VPN
• SSL/TLS-based VPNs have been around since the early 1990s and were first developed by Netscape and eventually adopted by nearly everyone to create tunnels between specific applications, primarily in web browsers.
• SSL/TLS VPNs provide encryption and reliability for the upper layers of the OSI model.
• We use an SSL/TLS VPN for transmitting sensitive information, such as banking or credit card information to a server using HTTPS.
• Businesses will most likely use an SSL certificate to reassure clients.
• Unlike SSH, it doesn’t require any authentication and typically uses port 443 to make a connection.
• Multiprotocol Label Switching VPN
• Multi-protocol label switching includes various methods for creating VPNs, using MPLS, and it provides a flexible way to route traffic through an MPLS network.

Now, there are other solutions as well.

• Open VPN, which is an open-source solution that has many security and control features. Open VPN uses SSL/TLS so it’s able to cross network address translation and firewalls with minimal problems.

In some cases, you might simply want or need a browser-based VPN, and you can go online to select a couple of them.

• HTTPS Everywhere
• ZenMate – You can browse anonymously when a secure connection is not available.

VPN Topologies

A VPN topology defines the way we configure devices to support the VPN.
An organization decides to implement a VPN according to business needs.
In general, we group VPN topology in three main categories:

• Remote Access VPN
• A classic concept of a VPN is a remote access VPN, which allows users to have the ability to securely access internal resources.
• When using a remote access VPN, users must be part of the corporate network and the network administrator invites mobile and small office/home office employees to join by setting up a VPN so they can access the corporate network anytime, anywhere.
• Intranet VPN
• Intranet is either a confined private network withing the LAN or it may be globally interconnected LANs that use WAN technologies to communicate.
• We limit access to the internet to people, processes, and devices that are part of the organization’s directory.
• We use an intranet site to site VPN to link branch offices.
• Extranet VPN
• An extranet is an internet or private network that only authorized outsiders can access.
• That could include subcontractors, temporary workers, or business-to-business communication.
• The network administrator sets up a secure tunnel so they can securely access the corporate network anytime.

Physical Topologies

Physical topologies include hub and spoke, mesh and hybrid configuration.

• A common configuration is the hub and spoke topology.

• The hub is the central office, as we see on the left, and the remote offices are the spokes.
• Many organizations use this hierarchy design, such government, retail, and banks.
• A hub and spoke configuration work well when sites must communicate with the central office but not to each other.
• Hub and spoke topology might not work for everyone, sometimes because of prohibitive cost associated with international links, or an organization may require peer communication, where they must talk with one another.
• As a result, an organization may choose a mesh or partial-mesh topology.
• With a full mesh, all links communicate with one another.
• With a partial mesh, sites may only have communication with certain other sites.

• Here we see a partial mesh where Boston will be able to communicate with New York, and New York will be able to communicate with London, but New York is unable to communicate directly with Madrid.
• Large multinational companies may have a hybrid formation that combines hub and spoke with a partial mesh topology.

• Here we see Boston and Paris using hub and spoke topology, and the rest of the network is using a partial mesh topology.

An external access VPN can be remote access or site-to-site.

Remote Access VPN

• A remote access VPN connects client on the outside to the corporate network.
• Clients include outside sales staff and teleworkers that need access to corporate resources.
• For a remote access VPN to work, such as a remote access full tunnel, the remote worker must install VPN client software on their device.
• A remote access VPN can also include clientless SSL VPN, which provides access without requiring client software on the remote device.
• When accessing the corporate boundary, the client initiates a connection, and the request passes through the internet.
• Once it reaches the corporate boundary, the VPN server received the request and either accepts or rejects the request to connect.
• The VPN server will many times pass the request through a radius server.
• The radius server consults a list of policies, such as connection request policies.
• This includes checking authentication and authorization conditions along with any accounting policies.
• Health policies assess the health of a device prior to joining the network, includes the status of a client’s Window updates and possible malware.
• Network policies include the set of conditions, constraints, and settings that allow clients to join according to parameters, such as time of day, geolocation, and how long they can be on the network.

Site-to-Site VPN

• A site-to-site VPN connects entire networks.
• For example, a hub and spoke topology, where the hub is the central office, and the remote offices are the spokes.
• When using a site-to-site VPN, the individual hosts do not have client software.
• The connection is transparent in that clients are unaware that they are connecting via a VPN.
• Clients send traffic via normal TCP/IP connections through a VPN gateway.
• When setting up a VPN, the network administrator has choices.
• A common secure tunneling protocol is IPsec encapsulating security payload as a full tunnel or site-to-site VPN.
• The encapsulating security payload protocol provides confidentiality, authentication, integrity, and anti-replay service for IPv4 and IPv6.
• The network administrator may also use an SSL/TLS as a full tunnel or clientless VPN.
• With a clientless VPN, the client doesn’t have to have any VPN client software.
• They simply connect through a web browser.

The Cisco ASA offers choices in how to configure the VPN.

• We could use an IPsec site-to-site VPN, a full tunnel SSL VPN, clientless SSL VPN, or a full tunnel IPsec VPN.
• Whether an external access VPN is a remote access or site-to-site, the network administrator has choices as to how to configure the VPN, so that clients can securely connect and communicate with the network.

VPN Implementation

There are two types of VPN implementation:

• Route-Based: A route-based VPN creates a virtual IPsec interface, and whatever traffic hits that interface is encrypted and decrypted according to the phase 1 and phase 2 IPsec settings.
• A route-based VPN is created with two policies, one for inbound and another for outbound with a normal Accept action.
• If the VPN connection requires redundancy, a route-based VPN is normally required.
• Numbers of VPN tunnels are limited to either route entries or number of tunnel interface specified which are supported by the device.
• Traffic flowing through the VPN tunnel can be NATTed since it passes through either the tunnel interface or gateway IP address specified as next-hop in routing.
• Policy based: In a policy-based VPN, the tunnel is specified within the policy itself with an action of IPsec. 
• Also, for a policy-based VPN, only one policy is required.
• Remote access VPN can be implemented with policy-based VPN.
• Traffic flowing through the VPN tunnel can’t be NATTed.
• Numbers of VPN tunnels are limited by the number of policies specified

VPN Protocol Types

• Internet Protocol Security (IPsec): Internet Protocol Security, known as IPsec, is used to secure Internet communication across an IP network. IPSec secures Internet Protocol communication by verifying the session and encrypts each data packet during the connection. IPsec runs in 2 modes:
• Transport mode
• Tunneling mode
• Layer 2 Tunneling Protocol (L2TP): L2TP or Layer 2 Tunneling Protocol is a tunneling protocol that is often combined with another VPN security protocol like IPsec to establish a highly secure VPN connection. L2TP generates a tunnel between two L2TP connection points and IPsec protocol, encrypts the data and maintains secure communication between the tunnels.
• Point–to–Point Tunneling Protocol (PPTP): PPTP or Point-to-Point Tunneling Protocol generates a tunnel and confines the data packet. Point-to-Point Protocol (PPP) is used to encrypt the data between the connection. PPTP is one of the most widely used VPN protocol and has been in use since the early release of Windows. PPTP is also used on Mac and Linux apart from Windows.
• SSL and TLS: SSL (Secure Sockets Layer) and TLS (Transport Layer Security) generate a VPN connection where the web browser acts as the client and user access is prohibited to specific applications instead of entire network. Online shopping websites commonly uses SSL and TLS protocol. It is easy to switch to SSL by web browsers and with almost no action required from the user as web browsers come integrated with SSL and TLS. SSL connections have “https” in the initial of the URL instead of “http”.
• Secure Shell (SSH): Secure Shell or SSH generates the VPN tunnel through which the data transfer occurs and also ensures that the tunnel is encrypted. SSH connections are generated by a SSH client and data is transferred from a local port on to the remote server through the encrypted tunnel.

• MPLS VPN is the VPN solution that is used by Service Providers. It is the most used VPN types used by Service Providers. MPLS VPN is a complex and expensive solution for home users. 

  There are different types of MPLS VPNs. Mainly there are two types MPLS VPNs. These are:
• Layer 2 VPNs
• VPLS (Virtual Private LAN Service)
• VPWS (Virtual Private Wire Service) (Pseudowire)
• Layer 3 VPNs
• SSTP (Secure Socket Tunneling Protocol): A VPN protocol developed by Microsoft that uses SSL to secure the connection, but only available for Windows.
• IKEv2 (Internet Key Exchange version 2): A VPN protocol that provides fast and secure connections, but not widely supported by VPN providers.
• OpenVPN: An open-source VPN protocol that is highly configurable and secure, widely supported by VPN providers and considered one of the most secure VPN protocols.
• WireGuard: A relatively new and lightweight VPN protocol that aims to be faster, simpler, and more secure than existing VPN protocols.

VPN Tunneling Types

Tunneling is the technique of putting an integrated data packet into another packet (which contains routing information) and sending it over the internet. The packets travel through a path which is known as tunnel. To secure a tunneled transmission against interception, all traffic over a VPN is encrypted for safety. Virtual Private Network (VPN) supports 2 types of tunneling which are as follows:

• Voluntary tunneling
• VPN client in the voluntary tunneling handles all the connection setup. 
• For the setup of connection through tunnel both the tunnel client and the tunnel server have to accept the same tunneling protocol. 
• In voluntary tunneling, client-first form a connection to the ISP or carrier network provider. 
• Then the tunnel on a VPN server builds by the VPN client application using this live connection. 
• Two step procedure is required to set up the VPN connection in voluntary tunneling.
• Compulsory tunneling
• The carrier network provider in the voluntary tunneling handles all the connection setup required for VPN. 
• It is a one step process as compared to the two steps in voluntary tunneling. 
• In compulsory tunneling, the client first establishes a normal connection to the carrier then the carrier works as an intermediary to make a connection between a VPN server and that client. 
• Compulsory tunneling provides complete management control of the tunnels to the ISP and hides the details of the connectivity of VPN server from the clients.
• Broker devices are used in compulsory tunneling for the verification of clients. 
• The logic build in the broker device are used to associates the client with the different VPN servers.
• This network device is also called as the following:
• VPN Front End Processor (FEP)
• Network Access Server (NAS)
• Point of Presence Server (POS)

VPN: Key Components

The purpose of a VPN is to secure network communication and as a critical component of an organization’s overall security plan.
Today, the market has multiple VPN choices, and the networking team must ensure the best possible solution for the organization.
Now, there are several key components to ensure an effective VPN and those include:

• VPN platform: Hardware or Software
• Cryptographic techniques: Ensure confidentiality, integrity, and authentication.
• Confidentiality – Use symmetric encryption algorithms that include AES and AES-CBC
• Data Integrity – Use hash algorithms that include SHA-224 and SHA-256
• Authentication – Use either a PSK or the asymmetric encryption algorithm RSA.
• Key exchange: so that both parties have the same shared key. Choices for Key exchange include:
• RSA (Rivest-Shamir-Adleman)
• Internet Key Exchange (IKE) – method use in IPsec.
• Pre-shared key (PSK)

Applications of VPN

• VPN can easily bypass geographic restrictions on websites or streaming audio and video.
• Using a VPN, we can protect ourselves from snooping from untrustworthy Wi-Fi hotspots.
• One can gain privacy online by hiding one’s true location.
• One can protect themselves from being logged while torrenting.

BGP Attributes LAB - Local Preference and AS-Prepend

This LAB demonstrates the use of BGP attributes such as Local Preference and Prepending AS-Path to influence inbound and outbound traffic within an Autonomous System.

• Local Preference
• As you all know that this attribute is only applicable within an Autonomous System and the routes with higher Local Preference value are more preferred than the lower. Therefore, this attribute is applicable to all the outbound traffic exiting your AS if you have multiple exit points. The default value is 100.
• Prepend AS-Path
• In this attribute, we add ASN numbers of the local AS to the routes advertised outbound to another AS. Let's say our Local AS is 1234 and the other AS is 2000. Then the other AS will not choose its original path through AS 2000 to reach the destination networks but instead it will choose another path through AS 3000 to reach the destination networks. This is because BGP always chooses the route with the shortest AS-Path value in its routing table.

Host-A and Host-B are connected to R1 and R2 respectively. All these devices are in Autonomous System 1234. R1 is peering with R2 through iBGP configurations.
ISP01, ISP02, and ISP03 are service provider networks where each router is in different Autonomous systems as shown below.

• ISP01 is in ASN 2000
• ISP02 is in ASN 3000
• ISP03 is in ASN 4000

The webserver exists on ISP03 network.

The primary task in this LAB is to influence the traffic flow from Host01 and Host02 to reach the webserver and vice versa.
We will follow two main conditions for the traffic flow between Host01, Host02 to reach the Webserver.

Condition-1: BGP configurations with default attributes

The “next-hop-self” feature on BGP will give us proper gateway IP for an alternate route to reach destination networks

Configuration for R1
configure terminal
interface GigabitEthernet0/0
ip address 192.168.30.0 255.255.255.254
no shut
exit
!
interface serial2/0
ip address 45.45.45.1 255.255.255.254
no shut
exit
!
interface ethernet3/0
ip address 192.168.10.1 255.255.255.0
no shut
exit
!
ip dhcp pool HOST-A
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
dns-server 192.168.10.1
exit
!
router bgp 1234
neighbor 192.168.30.1 remote-as 1234
neighbor 45.45.45.0 remote-as 2000
address-family ipv4
redistribute connected
neighbor 192.168.30.1 activate
neighbor 192.168.30.1 next-hop-self
neighbor 45.45.45.0 activate
neighbor 45.45.45.0 next-hop-self
exit
!
end
wr

Configuration for R2
configure terminal
interface GigabitEthernet0/0
ip address 192.168.30.1 255.255.255.254
no shut
exit
!
interface serial2/0
ip address 54.54.54.0 255.255.255.254
no shut
exit
!
interface ethernet3/0
ip address 192.168.20.1 255.255.255.0
no shut
exit
!
ip dhcp pool HOST-A
network 192.168.20.0 255.255.255.0
default-router 192.168.20.1
dns-server 192.168.20.1
exit
!
router bgp 1234
neighbor 192.168.30.0 remote-as 1234
neighbor 54.54.54.1 remote-as 3000
address-family ipv4
redistribute connected
neighbor 192.168.30.0 activate
neighbor 192.168.30.0 next-hop-self
neighbor 54.54.54.1 activate
neighbor 54.54.54.1 next-hop-self
exit
!
end
wr

R1#
*Mar  5 17:39:18.071: %BGP-5-ADJCHANGE: neighbor 192.168.30.1 Up
R1#

Configuration for ISP1
configure terminal
interface GigabitEthernet0/0
ip address 192.168.40.1 255.255.255.254
no shut
exit
!
interface serial2/0
ip address 45.45.45.0 255.255.255.254
no shut
exit
!
router bgp 2000
neighbor 192.168.40.0 remote-as 4000
neighbor 45.45.45.1 remote-as 1234
address-family ipv4
redistribute connected
neighbor 192.168.40.0 activate
neighbor 192.168.40.0 next-hop-self
neighbor 45.45.45.1 activate
neighbor 45.45.45.1 next-hop-self
exit
!
end
wr

ISP1#
*Mar  5 17:07:53.479: %BGP-5-ADJCHANGE: neighbor 45.45.45.1 Up
ISP1#

Configuration for ISP2
configure terminal
interface GigabitEthernet0/0
ip address 192.168.50.0 255.255.255.254
no shut
exit
!
interface serial2/0
ip address 54.54.54.1 255.255.255.254
no shut
exit
!
router bgp 3000
neighbor 192.168.50.1 remote-as 4000
neighbor 54.54.54.0 remote-as 1234
address-family ipv4
redistribute connected
neighbor 192.168.50.1 activate
neighbor 192.168.50.1 next-hop-self
neighbor 54.54.54.0 activate
neighbor 54.54.54.0 next-hop-self
exit
!
end
wr

ISP2#
*Mar  5 17:07:41.835: %BGP-5-ADJCHANGE: neighbor 54.54.54.0 Up
ISP2#

Configuration for ISP3
configure terminal
interface GigabitEthernet0/0
ip address 192.168.40.0 255.255.255.254
no shut
exit
!
interface GigabitEthernet1/0
ip address 192.168.50.1 255.255.255.254
no shut
exit
!
interface ethernet3/0
ip address 192.168.60.1 255.255.255.0
no shut
exit
!
ip dhcp pool Web-Server
network 192.168.60.0 255.255.255.0
default-router 192.168.60.1
dns-server 192.168.60.1
exit
!
router bgp 4000
neighbor 192.168.40.1 remote-as 2000
neighbor 192.168.50.0 remote-as 3000
address-family ipv4
redistribute connected
neighbor 192.168.40.1 activate
neighbor 192.168.40.1 next-hop-self
neighbor 192.168.50.0 activate
neighbor 192.168.50.0 next-hop-self
exit
!
end
wr

ISP3#
*Mar  5 17:09:08.387: %BGP-5-ADJCHANGE: neighbor 192.168.50.0 Up
*Mar  5 17:09:09.011: %BGP-5-ADJCHANGE: neighbor 192.168.40.1 Up
ISP3#

Run “ip dhcp” on Host-A, Host-B and Web-Server, so that they get IP assigned.

Host-A> ip dhcp
DDORA IP 192.168.10.2/24 GW 192.168.10.1 

Host-B> ip dhcp
DDORA IP 192.168.20.2/24 GW 192.168.20.1

Web-Server> ip dhcp
DORA IP 192.168.60.2/24 GW 192.168.60.1

Let us do some verifications on the routes taken when we have not modified any attributes. BGP will go through all attributes one by one in selecting the best route to reach the destination.

Host-A> ping 192.168.60.2
84 bytes from 192.168.60.2 icmp_seq=1 ttl=61 time=91.788 ms
84 bytes from 192.168.60.2 icmp_seq=2 ttl=61 time=92.158 ms
84 bytes from 192.168.60.2 icmp_seq=3 ttl=61 time=91.214 ms
84 bytes from 192.168.60.2 icmp_seq=4 ttl=61 time=91.939 ms
84 bytes from 192.168.60.2 icmp_seq=5 ttl=61 time=92.687 ms
Host-A>

The PING results show that the connectivity is established between Host-A and the Web-Server. Now we will check the BGP routing table on R1 to see what path it takes to reach the webserver.

R1#show ip bgp
BGP table version is 9, local router ID is 192.168.30.0
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 *   45.45.45.0/31    45.45.45.0               0             0 2000 ?
 *>                   0.0.0.0                  0         32768 ?
 *>i 54.54.54.0/31    192.168.30.1             0    100      0 ?
 *>  192.168.10.0     0.0.0.0                  0         32768 ?
 *>i 192.168.20.0     192.168.30.1             0    100      0 ?
 * i 192.168.30.0/31  192.168.30.1             0    100      0 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  192.168.40.0/31  45.45.45.0               0             0 2000 ?
 *   192.168.50.0/31  45.45.45.0                             0 2000 4000 ?
 *>i                  192.168.30.1             0    100      0 3000 ?
 * i 192.168.60.0     192.168.30.1             0    100      0 3000 4000 ?
 *>                   45.45.45.0                             0 2000 4000 ?
R1#

R1#show ip bgp 192.168.60.2
BGP routing table entry for 192.168.60.0/24, version 9
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 1
  3000 4000
    192.168.30.1 from 192.168.30.1 (192.168.30.1)
      Origin incomplete, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  2000 4000
    45.45.45.0 from 45.45.45.0 (192.168.40.1)
      Origin incomplete, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
R1#

The BGP routing table on R1 tells us that to reach 192.168.60.0/24 network it is going through ISP1 route. This is because according to the BGP attribute it has selected the best path external over the internal path as shown above.

Condition-2: BGP configurations with modified attributes

Let’s assume that our network is not stable through ISP01 because we are experiencing a packet loss beyond ISP01.

Now  let focus on outbound traffic flow. So, if we want Host-A to take the ISP02 path instead of ISP01, we can manipulate it using Local Preference for the inbound traffic on R2 for ISP02 neighbor.

Configuration for R2
configure terminal
router bgp 1234
address-family ipv4
neighbor 54.54.54.1 route-map INBOUND in
exit
exit
route-map INBOUND permit 10
set local-preference 200
!
end
wr

Now if we see the path from Host-A to Webserver, it will take the path from ISP02 instead ISP01, as the local preference value is higher for ISP02 path.

Host-A> trace 192.168.60.2
trace to 192.168.60.2, 8 hops max, press Ctrl+C to stop
 1   192.168.10.1   15.462 ms  15.850 ms  16.167 ms
 2   192.168.30.1   47.279 ms  47.549 ms  46.231 ms
 3   54.54.54.1   61.104 ms  76.163 ms  77.495 ms
 4   192.168.50.1   91.609 ms  92.555 ms  92.682 ms
 5   *192.168.60.2   106.949 ms (ICMP type:3, code:3, Destination port unreachable)
Host-A>

R1#show ip bgp 192.168.60.2
BGP routing table entry for 192.168.60.0/24, version 29
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     5
  Refresh Epoch 1
  3000 4000
    192.168.30.1 from 192.168.30.1 (192.168.30.1)
      Origin incomplete, metric 0, localpref 200, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  2000 4000
    45.45.45.0 from 45.45.45.0 (192.168.40.1)
      Origin incomplete, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
R1#

But now the issue is the inbound traffic from Webserver to Host-A is still coming from ISP01 circuit as from below trace:

Web-Server> trace 192.168.10.2
trace to 192.168.10.2, 8 hops max, press Ctrl+C to stop
 1   192.168.60.1   15.396 ms  15.341 ms  15.842 ms
 2   192.168.40.1   46.686 ms  45.724 ms  45.938 ms
 3   45.45.45.1   91.782 ms  90.778 ms  90.307 ms
 4   *192.168.10.2   105.879 ms (ICMP type:3, code:3, Destination port unreachable)
Web-Server>

So, to manipulate the inbound traffic flow, we can use AS Prepend so that the traffic will get diverted through ISP02, as ISP02 will have shortest AS path.

Configuration for R1
configure terminal
router bgp 1234
address-family ipv4
neighbor 45.45.45.0 route-map OUTBOUND out
exit
exit
route-map OUTBOUND permit 10
set as-path prepend 1234 1234 1234
!
end
wr

So, now if we check on ISP01 for route towards Host-A, it will show  the other path as best paths instead of ISP01 circuit

ISP1#show ip bgp 192.168.10.2
BGP routing table entry for 192.168.10.0/24, version 33
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  4000 3000 1234
    192.168.40.0 from 192.168.40.0 (192.168.60.1)
      Origin incomplete, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  1234 1234 1234 1234
    45.45.45.1 from 45.45.45.1 (192.168.30.0)
      Origin incomplete, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
ISP1#

We can also verify through traceroute on Webserver to reach the Host-A.

Web-Server> trace 192.168.10.2
trace to 192.168.10.2, 8 hops max, press Ctrl+C to stop
 1   192.168.60.1   15.593 ms  15.446 ms  15.611 ms
 2   192.168.50.0   47.276 ms  48.049 ms  46.417 ms
 3   54.54.54.0   76.942 ms  77.174 ms  77.605 ms
 4   192.168.30.0   107.766 ms  108.474 ms  106.352 ms
 5   *192.168.10.2   122.066 ms (ICMP type:3, code:3, Destination port unreachable)
Web-Server>

In my scenario, I have selected Local Preference and Prepend AS-PATH metric to influence the inbound and outbound routes for the hosts in ASN1234 to reach the Webserver because these metrics can be configured on the edge routers within the ASN-1234 and we don’t have to tell our ISP to influence the BGP routes for us because mostly the ISPs are not responsible to route the traffic within our ASN-1234.

Thank you for following my Blog and let me know if you have any questions?