• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

Routing

Router versus Firewall: What are the differences?

06/22/2020 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email
router versus firewall

There seems to be some confusion about the differences between the router and firewall. One of the contributing factors to this is that device manufacturers tend to combine the functionalities into one device. Traditionally, these devices are specialized hardware that does a specific job well.

Both of these devices have advantages and disadvantages over the other, unique features, and different purposes. In this article, we will define what they are, identify their primary use in your network, and explain why you may need both.

What is a router?

A router is a device that quickly forwards data from one network to another. For example, for your devices to communicate to the Internet, you need a networking device to transmit the traffic from your home to the Internet Service Provider (ISP). Typically, this device is a router that either you purchased or provided by your ISP.

The type of router found in most homes and some small businesses is called a wireless router. The wireless router combines the functionalities of multiple devices: wireless access point, switch, and a router.

Furthermore, a lot of routers in the market provide some level of network security by including features like Network Address Port Translation (NAPT), Stateful Packet Inspection (SPI), etc.

What does a router do?

The principal function of a router is to route network traffic between networks. The job of a router is similar to the role of the United States Postal Service (USPS). The router tries its best to forward the data between the sender and the receiver in different networks.

Since the majority of routers in a lot of small businesses are wireless routers, they also allow the connection of wired and wireless devices such as computers, printers, mobile devices, etc.

What is a firewall?

A network-based firewall is a device that provides security by monitoring incoming and outgoing traffic and makes a decision whether to allow or deny specific traffic based on the rule sets.

For many years, the firewall has been an integral part of any successful security program. It serves as the first line of defense in network security.

Today’s modern operating systems, such as Windows and macOS, include a software firewall that provides added network protection. A software host-based firewall functions similarly to a traditional network-based firewall.

Nowadays, firewall manufacturers add extra features like anti-malware, Intrusion Prevention System (IPS), application awareness, URL filtering, etc. referred to as a next-generation firewall (NGFW). An NGFW offers far improved security than a router or a traditional firewall.

What does a firewall do?

The principal function of a firewall is to provide network protection by blocking unwanted traffic. A job of a firewall is similar to the role of the Transportation Security Administration (TSA). The firewall inspects network traffic to make sure everything looks good before it is allowed to pass through.

Some firewalls designed for small businesses or branch offices also combine functionalities of wireless routers, allowing both wired and wireless network connectivity.

Which one should you buy?

Unfortunately, the answer to this question is it depends. Determining the right device for your business requires an understanding of the goals and requirements.

For a small coffee shop, a wireless router from your favorite retailer may be sufficient. For some small and medium-sized businesses (SMB), they may opt to purchase NGFW for better security.

In some scenarios, you might need to purchase both a router and a firewall. For example, if a branch office has the following requirements: WAN connectivity options (both wired and wireless), VoIP, switching, NGFW, and computing. Then, buying a router that can do the majority of these requirements and a separate NGFW could be a suitable solution.

There are some instances where you don’t want to, by default, restrict network traffic. For example, in higher education space, the researchers may expect no restrictions and a fast network to transfer data between each other.

Summary

Both devices can provide a level of network security. However, NGFW gives a higher level of protection compared to a router with some firewalling features.

Choosing between a router and a firewall will vary from one company to another. The key to determining the proper device is by gathering the requirements, goals, and business and technical constraints.

If security is paramount to your company, then purchasing a next-generation firewall with a subscription to the advanced features is the right way to go.

Still unsure on what to get?

Let us answer your questions by contacting us. We’ll help you with hardware selection, design, configuration, and implementation.

LET’S TALK

NetworkJutsu provides networking and network security consulting services for startups, a more established small and medium-sized business (SMB), or large business throughout the San Francisco Bay Area.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

RIP Authentication

06/15/2014 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

I was watching INE videos about RIP and when I reached the RIP Authentication video, I apparently forgot about the key number must match requirement when using MD5. To be honest, it wasn’t the only one I forgot about RIP. Heck, I usually forget what I read last night! It’s a constant struggle that I deal with every single day. I think I need a flash drive or the “Limitless” pill so that I can remember everything I read, but I digress.

Clear Text Method

There are two methods that can be used when enabling RIP Authentication: clear text and MD5. For security purposes, cleartext should not be used in production. This method has two requirements: key string and authentication must match for it to work. That said, even if the key number doesn’t match the routers will still exchange routes just fine. For completeness sake, the example is shown below.

Router 1 configuration and verification:

R1#sh run | se key         
key chain rip
 key 1
   key-string cisco
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
      22.0.0.0/24 is subnetted, 1 subnets
R        22.22.22.0 [120/1] via 1.1.1.2, 00:00:04, GigabitEthernet1

Router 2 configuration and verification:

R2#sh run | se key         
key chain rip
 key 2
   key-string cisco
 ip rip authentication key-chain rip
R2#sh ip route rip | se sub
      11.0.0.0/24 is subnetted, 1 subnets
R        11.11.11.0 [120/1] via 1.1.1.1, 00:00:19, GigabitEthernet1

MD5 Authentication

This method is the recommended mode in-production for obvious reasons. This method has three requirements: key number, key string, and authentication must match. We all know what it looks like when it works, but what happens when we actually introduce a fault in the configuration? In theory, it shouldn’t work, right? Well, let’s take a look.

Router 1 and Router 2 are configured with two different key string:

R1#sh run | se key         
key chain rip
 key 1
   key-string cisco
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
R1#
R1#debug ip rip events
*Jun 15 22:59:02.665: RIP: ignored v2 packet from 1.1.1.2 (invalid authentication)
R2#sh run | se key
key chain rip
 key 1
   key-string systems
 ip rip authentication key-chain rip
R2#sh ip route rip | se sub
R2#
R2#debug ip rip event
*Jun 15 22:51:29.159: RIP: ignored v2 packet from 1.1.1.1 (invalid authentication)

As expected, both routers ignored the update and didn’t process the update.

Router 1 and Router 2 are configured with two different authentication mode:

R1#sh run | se mode md5|key
key chain rip
 key 1
   key-string cisco
 ip rip authentication mode md5
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
R1#
R1#debug ip rip event
RIP event debugging is on
*Jun 15 23:08:45.068: RIP: ignored v2 packet from 1.1.1.2 (invalid authentication)
R2#sh run | se mode md5|key
key chain rip
 key 1
   key-string cisco
 ip rip authentication key-chain rip
R2#sh ip route rip | se sub
R2#debug ip rip event
RIP event debugging is on
*Jun 15 23:08:40.623: RIP: ignored v2 packet from 1.1.1.1 (invalid authentication)

Again, it’s expected to not work.

Router 1 and Router 2 are configured with two different key number:

R1#sh run | se key|mode md5
key chain rip
 key 1
   key-string cisco
 ip rip authentication mode md5
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
R1#debug ip rip event
RIP event debugging is on
*Jun 15 23:20:33.452: RIP: ignored v2 packet from 1.1.1.2 (invalid authentication)

R2#sh run | se key|mode md5
key chain rip
 key 2
   key-string cisco
 ip rip authentication mode md5
 ip rip authentication key-chain rip
R2#sh ip route rip | se sub
      11.0.0.0/24 is subnetted, 1 subnets
R        11.11.11.0 [120/1] via 1.1.1.1, 00:00:18, GigabitEthernet1
R2#debug ip rip eve
RIP event debugging is on
*Jun 15 23:23:15.984: RIP: received v2 update from 1.1.1.1 on GigabitEthernet1
*Jun 15 23:23:15.984: RIP: Update contains 1 routes

Now, this is interesting output. Why did R2 process the update of R1 and installed its routing table and R1 ignored the update from R2? The only thing that makes sense is the feature of RIP (and most likely EIGRP too) that it can store multiple keys in its database to change up so that it can mitigate the keys being compromised. RFC 2082 doesn’t talk about it but it does talk about multiple keys and rollover so I think it’s related to that. I haven’t seen a Cisco doc about this specifically so please feel free to drop me a comment pointing to one that explains this behavior.

For experimentation’s sake, I decided to add another key number in R1 that matches R2’s configuration. R1 did process the RIP updates and installed it in the routing table, as one would expect since all three requirements were met.

R1#sh run | se key|md5
key chain rip
 key 1
   key-string cisco
 key 2
   key-string cisco
 ip rip authentication mode md5
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
      22.0.0.0/24 is subnetted, 1 subnets
R        22.22.22.0 [120/1] via 1.1.1.2, 00:00:17, GigabitEthernet1
*Jun 15 23:33:49.378: RIP: received v2 update from 1.1.1.2 on GigabitEthernet1
*Jun 15 23:33:49.378: RIP: Update contains 1 routes

Thoughts

I wish Cisco’s documentation and/or Cisco Press’ authors covered this but I haven’t seen one that did. Even Cisco’s configuration guide, and configuration examples didn’t explain much about the keys. Perhaps, they feel like RIP shouldn’t be covered as detailed as the other routing protocols since it’s rarely used in production. What are your thoughts?

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

OSPF Network Types

03/05/2012 By Andrew Roderos Leave a Comment

OSPF behavior using different interface types.

Interface TypeUses DR/BDR?Default
Hello
Interval
Requires a
neighbor
Command?
More than Two
Hosts Allowed
in the Subnet?
BroadcastYes10NoYes
Point-to-point 1No10NoNo
Nonbroadcast 2 (NBMA)Yes30YesYes
Point-to-multipointNo30NoYes
Point-to-multipoint nonbroadcastNo30YesYes
LoopbackNo——No

1 Default on Frame Relay point-to-point subinterfaces.
2 Default on Frame Relay physical and multipoint subinterfaces.

Reference

CCIE Routing and Switching Certification Guide 4th Edition

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

GRE Tunnel Recursive Routing

01/15/2012 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Ever seen this error message %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing? The most common reason for this error is that the router is trying to route to the tunnel destination address using the tunnel interface itself. This error message will keep flooding your router until someone fixes the misconfiguration of the router. This will also mean that your tunnel interface will keep flapping until fixed.

Let’s take a look at a scenario in which recursive routing is being experienced. In this particular environment, there are several remote branches that will need to establish a GRE tunnel to the headend. For simplicity, the diagram only shows two remote branches and the configuration only shows the headend and a remote branch. Please ignore the IP addressing as I just picked random numbers. The 172.18.0.0/16 address, however, has been assigned to be the serial interfaces of the remote branch routers.

Here are the configuration of the enterprise routers:

GRE-HEADEND

interface Loopback0
 ip address 172.17.254.254 255.255.255.255
!
interface Loopback1
 ip address 172.17.1.254 255.255.255.0
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel source Serial0/0
 tunnel destination 172.18.1.254 
!
interface Serial0/0
 ip address 172.19.0.254 255.255.255.0 
!
router eigrp 1
 network 172.0.0.0 0.255.255.255
 no auto-summary 
! 
ip route 172.18.0.0 255.255.0.0 Serial0/0
!

REMOTE-R1

interface Loopback0
 ip address 172.17.2.254 255.255.255.255
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel source Serial0/0
 tunnel destination 172.19.0.254
!
interface FastEthernet0/0
 ip address 172.24.1.254 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 ip address 172.18.1.254 255.255.255.0
!
router eigrp 1
 network 172.0.0.0 0.255.255.255
 no auto-summary
!
ip route 172.19.0.0 255.255.255.0 Serial0/0
!

Once the routers able to reach their tunnel destination IP address and when the tunnel interfaces comes up/up on both routers, then they’ve established the GRE tunnel. However, once they start exchanging EIGRP the tunnel will go down due to recursive routing. The router will automatically reestablish GRE tunnel and establish EIGRP neighborship but will eventually go down again, as shown below. This is a cycle and will never be fixed unless a human intervention.

GRE-HEADEND#
*Mar  1 03:08:46.087: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
*Mar  1 03:08:50.435: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.17.2.254 (Tunnel1) is up: new adjacency
GRE-HEADEND#show ip eigrp neigh
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.17.2.254            Tu1               14 00:00:05   32  5000  2  40
GRE-HEADEND#
*Mar  1 03:08:55.087: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Mar  1 03:08:56.087: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Mar  1 03:08:56.127: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.17.2.254 (Tunnel1) is down: interface down

So what’s the problem here? Well, it is quite simple really. The GRE-HEADEND router has a static route that is shorter prefix to reach the tunnel destination address of the remote routers – ip route 172.18.0.0 255.255.0.0 s0/0. Since this is a shorter prefix, the GRE-HEADEND router will eventually learn a better route via EIGRP and will try to use that to reach the tunnel destination address. Unfortunately, that’s not going to work since the router learned it via EIGRP which has a next hop interface of Tunnel1, as shown below.

GRE-HEADEND#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
     172.17.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.17.2.254/32 [90/297372416] via 172.17.2.254, 00:00:01, Tunnel1
C       172.17.1.0/24 is directly connected, Loopback1
C       172.17.254.254/32 is directly connected, Loopback0
     172.19.0.0/24 is subnetted, 1 subnets
C       172.19.0.0 is directly connected, Serial0/0
     172.18.0.0/16 is variably subnetted, 2 subnets, 2 masks
S       172.18.0.0/16 is directly connected, Serial0/0
D       172.18.1.0/24 [90/297756416] via 172.17.2.254, 00:00:03, Tunnel1
     172.24.0.0/24 is subnetted, 1 subnets
D       172.24.1.0 [90/297270016] via 172.17.2.254, 00:00:03, Tunnel1

The solution for this recursive routing issue is to remove the static route with a shorter prefix and add a static route with a longer prefix, so the router won’t use the route learned via the IGP, in this case EIGRP. Remember the rules of how the router places routes in the routing table: the more specific route gets placed, if it’s a tie then the route with the best AD (Administrative Distance) value, and if the AD value is a tie then the route with the best metric will be placed.

GRE-HEADEND(config)#ip route 172.18.1.0 255.255.255.0 s0/0
GRE-HEADEND#
*Mar  1 03:19:17.611: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
GRE-HEADEND#
*Mar  1 03:19:21.171: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.17.2.254 (Tunnel1) is up: new adjacency
GRE-HEADEND#sh ip eigrp neigh
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.17.2.254            Tu1               14 00:18:20   79  5000  0  81

As you can see above, the EIGRP has been stable for more than 15 minutes compared to the show ip eigrp neighbor output shown above.

I hope this has been helpful and I thank you for reading!

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Enable IPv6 on Cisco Catalyst 3560

10/08/2011 By Andrew Roderos 3 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

When you’re building a Cisco home lab, make sure to buy switches and/or routers that will satisfy the requirements of the track you’re currently studying for. You may also want to future proof your home lab for other Cisco tracks. Future proofing was one of the reasons why I didn’t buy 1841 for my lab and bought 2801 instead. 1841s will not satisfy the requirements of Voice track, which is one of the Cisco tracks that I would like to learn more about. Anyway, CCNP R&S (Routing and Switching) and CCIE R&S requires you to know IPv6. While CCNP does not specifically require to run IPv6 on 3560, it will most likely be used in the CCIE lab exam. I do know that INE materials require you to enable IPv6 on Catalyst 3560 to practice and master the topic.

By default, Catalyst 3560s does not allow you to turn on IPv6 without changing SDM (Switching Database Manager). I did not know this before, so when I tried it on my Catalyst 3560, I got the following:

3560(config)#ipv6 ?
% Unrecognized command

I wasn’t expecting that error, so I went to Cisco’s website and started practicing on how to use Cisco DOC CD – only resource during the CCIE lab exam. Luckily, I was able to find the instructions on how to do it. But, if you want more information then please visit this configuration guide.

Without further ado, here’s a tutorial on how to enable IPv6 on Catalyst 3560.

3560(config)#sdm prefer dual-ipv4-and-ipv6 default
Changes to the running SDM preferences have been stored, but cannot take effect until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.
3560(config)#do wr mem
Building configuration...
[OK]
3560#reload

To verify that SDM has been changed:

3560#sho sdm prefer
 The current template is "desktop IPv4 and IPv6 default" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 1024 VLANs.
 number of unicast mac addresses:                  2K
 number of IPv4 IGMP groups + multicast routes:    1K
 number of IPv4 unicast routes:                    3K
   number of directly-connected IPv4 hosts:        2K
   number of indirect IPv4 routes:                 1K
 number of IPv6 multicast groups:                  1K
 number of directly-connected IPv6 addresses:      2K
 number of indirect IPv6 unicast routes:           1K
 number of IPv4 policy based routing aces:         0
 number of IPv4/MAC qos aces:                      0.5K
 number of IPv4/MAC security aces:                 1K
 number of IPv6 policy based routing aces:         0
 number of IPv6 qos aces:                          0.5K
 number of IPv6 security aces:                     0.5K

To verify that IPv6 can now be issued:

3560(config)#ipv6 ?
 access-list      Configure access lists
 cef              Cisco Express Forwarding for IPv6
 dhcp             Configure IPv6 DHCP
 general-prefix   Configure a general IPv6 prefix
 hop-limit        Configure hop count limit
 host             Configure static hostnames
 icmp             Configure ICMP parameters
 local            Specify local options
 mld              Global MLD Snooping enable for Catalyst Vlans
 neighbor         Neighbor
 prefix-list      Build a prefix list
 route            Configure static routes
 router           Enable an IPV6 routing process
 source-route     Process packets with source routing header options
 unicast-routing  Enable unicast routing

To enable IPv6, issue the command below:

3560(config)#ipv6 unicast-routing

It is pretty easy to configure, but if you didn’t know anything about SDM, then you’re probably going to blame the IOS version that is installed, I certainly did.

I hope this helps and thank you for reading!

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use