Tag Archives: routing

Bypass stateful firewall on a Sophos XG

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Usually, bypassing a firewall is not the best idea. But sometimes you have to. One case, where you want to bypass a firewall, is asymmetric routing.

MichaelGaida/ pixabay.com/ Creative Commons CC0

What is asymmetric routing? Imagine a scenario with two routers on the same network. One router offeres access to the internet, the other router provides access to other sites with site-2-site VPN tunnels.

Asymmetric Routing

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Host 1 uses R1 as default gateway. R1 has static routes configured to the networks reachable over the VPN, or it has learned them dynamically using a routing protocol from R2. A packet from host 1 arrives at R1, is routed to R2, and is sent over the VPN tunnel. The answer to this packet arrives at R2, and is sent directly to host 1, because host 1 is the destination. This works because R2 and host 1 are on the same network. This is asymmetric routing, because request and answer go different ways.

In case of routing, this is not a problem. But if R1 is a firewall, this firewall might be stubborn, because it does not see the whole traffic.

Bypass the stateful firewall

I recently had such a setup due to some technical debts. The firewall dropped that “Invalid Traffic”. Fortunately, there is a way to bypass the statefull firewall. You can create advanced firewall rules using the CLI. There is no way to create these rules using the GUI. And this only applies to the Sophos XG (former Cyberoam products).

Login to the device console and select option 4. Then enter on the console the following commands, one per destination:

Console> set advanced-firewall bypass-stateful-firewall-config add source_network 192.168.99.0 source_netmask 255.255.255.0 dest_network 192.168.20.0 dest_netmask 255.255.255.0

Make sure that you have a static or dynamically learned route to the networks. This is not a routing entry, it only tells the firewall what traffic should bypass the stateful firewall.

I’m routing on the edge…

This posting is ~7 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

In my last post (Routed Port vs. Switch Virtual Interface (SVI)), I have mentioned a consequence of using routed ports to interconnect access and core switches:

You have to route the traffic on the access switches.

Routing on the network access, the edge of the network, is not a question of performance. It is more of a management issue. Depending on the size of your network, and the number of subnets, you have to deal with lots of routes. And think about the effort, if you add, change or remove subnets from your network. This is not what you want to do with static routes. You need a routing protocol.

The experiment of the week

We have a core switch C1, consisting of two independent switches (C1-1 and C1-2) forming a virtual chassis. S1 and S2 are two switches at the network access. This is a core-edge design. There is no distribution layer. Each switch at the network access has two uplinks: One uplink to C1-1 and one uplink to C1-2. The ports on each end of the links are configured as routed ports.

Please ignore the 40 GbE ports (FGE) between C1-1 and C1-2. These ports are used for the Intelligent Resilient Framework (IRF), which is used to create a virtual chassis.

routed_links_1

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

These are the interfaces on the core switch, that are working in route mode. GE1/0/1 and GE2/0/1 are the uplinks to S1, and GE1/0/2 and GE2/0/2 are the uplinks to S2.

[C1]display interface brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP       10.0.0.1
GE1/0/2              UP   UP       10.10.0.1
GE2/0/1              UP   UP       10.1.0.1
GE2/0/2              UP   UP       10.11.0.1
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)    1.1.1.1
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   --       --

These are the interfaces on the access switch S1, that are working in route mode. GE1/0/1 and GE1/0/2 are the uplinks to C1. As you can see, GE1/0/1 on C1 and  GE1/0/1 on S1 belong to the same /30 network. The same applies to GE2/0/1 on C1 and GE1/0/2 on S1. There are also two SVIs, one on VLAN 1 (192.168.1.0/24) and another on VLAN 2 (192.168.2.0/24). These VLANs are used for client connectivity.

[S1]display interface brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP       10.0.0.2
GE1/0/2              UP   UP       10.1.0.2
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)    1.1.1.2
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   --       --
Vlan1                UP   UP       192.168.1.1
Vlan2                UP   UP       192.168.2.1

These are the interfaces on S2, that are working in route mode. GE1/0/1 and GE1/0/2 are the uplinks to C1. The interfaces GE1/0/2 on C1, and  GE1/0/1 on S2 belong to the same /30 network. The same applies to GE2/0/2 on C1 and GE1/0/2 on S2. There are also two SVIs, one on VLAN 1 (192.168.10.0/24) and another on VLAN 2 (192.168.20.0/24).

You might wonder, because the same VLAN IDs are used on both access switches. They don’t care, because there is no layer 2 connectivity between these two switches. The only way from S1 to S2 is over the routed links to the core switch.

[S2]display interface brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP       10.10.0.2
GE1/0/2              UP   UP       10.11.0.2
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)    1.1.1.3
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   --       --
Vlan1                UP   UP       192.168.10.1
Vlan2                UP   UP       192.168.20.1

Now let’s have a look at the Open Shortest Path First (OSPF) routing protocol.

Single Area OSPF

The Open Shortest Path First (OSPF) routing protocol is an interior gateway protocols (IGP), and also a link-state routing protocol. The calculation of the shortest path for each route is based on Dijkstra’s algorithm. I don’t want to annoy you with details. Take a look at the Wikipedia article for OSPF.

The simplest OSPF setup is a “Single Area OSPF”. This is an OSPF configuration, which has only a single area. This is the area 0, or the backbone area.

The configuration on the core switch looks like this:

[C1]ospf 1
[C1-ospf-1]display this
#
ospf 1
 area 0.0.0.0
  network 1.1.1.1 0.0.0.0
  network 10.0.0.0 0.255.255.255
#

The networks, that should be associated with this area, are specified with a wildcard mask. The wildcard mask is the opposite of the subnet mask. The wildcard mask 0.255.255.255 corresponds to the subnet mask 255.0.0.0. Because I have used multiple /30 subnets at the core switch, I can summarize them with a single entry for 10.0.0.0.

The same configuration applies to the access switches S1 and S2.

[S1]ospf 1
[S1-ospf-1]display this
#
ospf 1
 area 0.0.0.0
  network 1.1.1.2 0.0.0.0
  network 10.0.0.0 0.255.255.255
  network 192.168.0.0 0.0.255.255
#
[S2]ospf 1
[S2-ospf-1]display this
#
ospf 1
 area 0.0.0.0
  network 1.1.1.3 0.0.0.0
  network 10.0.0.0 0.255.255.255
  network 192.168.0.0 0.0.255.255
#

With this simple configuration, the switches will exchange their routing information. They will synchronize their link-state databases, and they will be fully adjacent. If a link-state change occurs, OSPF will handle this.

The core switch has two links to each access switch. The router ID represents the access switches. 1.1.1.2 is a loopback interface IP address on S1, 1.1.1.3 is a loopback interface IP address on S2.

<C1>display ospf peer

         OSPF Process 1 with Router ID 1.1.1.1
               Neighbor Brief Information

 Area: 0.0.0.0
 Router ID       Address         Pri Dead-Time  State             Interface
 1.1.1.2         10.0.0.2        1   37         Full/DR           GE1/0/1
 1.1.1.3         10.10.0.2       1   36         Full/DR           GE1/0/2
 1.1.1.2         10.1.0.2        1   38         Full/DR           GE2/0/1
 1.1.1.3         10.11.0.2       1   35         Full/DR           GE2/0/2

The same applies to the access switches, in this case S1. The access switches have also two active links to the core switch.

<S1>dis ospf peer

         OSPF Process 1 with Router ID 1.1.1.2
               Neighbor Brief Information

 Area: 0.0.0.0
 Router ID       Address         Pri Dead-Time  State             Interface
 1.1.1.1         10.0.0.1        1   31         Full/BDR          GE1/0/1
 1.1.1.1         10.1.0.1        1   32         Full/BDR          GE1/0/2

If one of the links fail, the access switch has another working link to the core switch, and OSPF will recalculate the shortest paths, taking the link-state change (link down between core and an access switch) into account.

This is the OSPF routing table of the core switch, based on the example above.

<C1>display ospf routing

         OSPF Process 1 with Router ID 1.1.1.1
                  Routing Table

 Routing for network
 Destination        Cost     Type    NextHop         AdvRouter       Area
 192.168.10.0/24    2        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 192.168.10.0/24    2        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 10.10.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.11.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.0.0.0/30        1        Transit 0.0.0.0         1.1.1.2         0.0.0.0
 10.1.0.0/30        1        Transit 0.0.0.0         1.1.1.2         0.0.0.0
 1.1.1.1/32         0        Stub    0.0.0.0         1.1.1.1         0.0.0.0
 1.1.1.2/32         1        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 1.1.1.2/32         1        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 1.1.1.3/32         1        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 1.1.1.3/32         1        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 192.168.20.0/24    2        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 192.168.20.0/24    2        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 192.168.1.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.1.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 192.168.2.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.2.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0

 Total nets: 17
 Intra area: 17  Inter area: 0  ASE: 0  NSSA: 0

What if I add a new subnet on S1? Let’s create a new VLAN and add a SVI to it (VLAN 3 and 192.168.3.1).

[S1]dis int brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP       10.0.0.2
GE1/0/2              UP   UP       10.1.0.2
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)    1.1.1.2
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   --       --
Vlan1                UP   UP       192.168.1.1
Vlan2                UP   UP       192.168.2.1
Vlan3                UP   UP       192.168.3.1

Without touching the OSPF configuration, the core switch C1, and the other access switch S2, added routes to this new subnet.

<C1>display ospf routing

         OSPF Process 1 with Router ID 1.1.1.1
                  Routing Table

 Routing for network
 Destination        Cost     Type    NextHop         AdvRouter       Area
 192.168.3.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.3.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 192.168.10.0/24    2        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 192.168.10.0/24    2        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 10.10.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.11.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.0.0.0/30        1        Transit 0.0.0.0         1.1.1.2         0.0.0.0
 10.1.0.0/30        1        Transit 0.0.0.0         1.1.1.2         0.0.0.0
 1.1.1.1/32         0        Stub    0.0.0.0         1.1.1.1         0.0.0.0
 1.1.1.2/32         1        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 1.1.1.2/32         1        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 1.1.1.3/32         1        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 1.1.1.3/32         1        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 192.168.20.0/24    2        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 192.168.20.0/24    2        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 192.168.1.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.1.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 192.168.2.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.2.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0

 Total nets: 19
 Intra area: 19  Inter area: 0  ASE: 0  NSSA: 0
<S2>display ospf routing

         OSPF Process 1 with Router ID 1.1.1.3
                  Routing Table

 Routing for network
 Destination        Cost     Type    NextHop         AdvRouter       Area
 192.168.3.0/24     3        Stub    10.10.0.1       1.1.1.2         0.0.0.0
 192.168.3.0/24     3        Stub    10.11.0.1       1.1.1.2         0.0.0.0
 192.168.10.0/24    1        Stub    0.0.0.0         1.1.1.3         0.0.0.0
 10.10.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.11.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.0.0.0/30        2        Transit 10.10.0.1       1.1.1.2         0.0.0.0
 10.0.0.0/30        2        Transit 10.11.0.1       1.1.1.2         0.0.0.0
 10.1.0.0/30        2        Transit 10.10.0.1       1.1.1.2         0.0.0.0
 10.1.0.0/30        2        Transit 10.11.0.1       1.1.1.2         0.0.0.0
 1.1.1.1/32         1        Stub    10.10.0.1       1.1.1.1         0.0.0.0
 1.1.1.1/32         1        Stub    10.11.0.1       1.1.1.1         0.0.0.0
 1.1.1.2/32         2        Stub    10.10.0.1       1.1.1.2         0.0.0.0
 1.1.1.2/32         2        Stub    10.11.0.1       1.1.1.2         0.0.0.0
 1.1.1.3/32         0        Stub    0.0.0.0         1.1.1.3         0.0.0.0
 192.168.20.0/24    1        Stub    0.0.0.0         1.1.1.3         0.0.0.0
 192.168.1.0/24     3        Stub    10.10.0.1       1.1.1.2         0.0.0.0
 192.168.1.0/24     3        Stub    10.11.0.1       1.1.1.2         0.0.0.0
 192.168.2.0/24     3        Stub    10.10.0.1       1.1.1.2         0.0.0.0
 192.168.2.0/24     3        Stub    10.11.0.1       1.1.1.2         0.0.0.0

 Total nets: 19
 Intra area: 19  Inter area: 0  ASE: 0  NSSA: 0

Pretty cool, isn’t it?

Any downsides?

This is only an example with a single core switch and two access switches. OSPF can be pretty complex, if the size of the network increases. The Dijkstra’s algorithm can be really CPU intensive, and the size of the link-state databases (LSDB) increase with adding more routers and networks. For this reason, larger networks have to be divided into separate areas. It depends on the network size and the CPU/ memory performance of your switches/ routers, but a common practice is a maximum of up to 50 switches/ routers per area. If you have unstable links, the area should be smaller, because each link-state change is flooded to all neighbors and consumes CPU time.

You need a good subnet design, otherwise you have to touch your OSPF configuration too often. You should be able to summarize subnets.

Conclusion

Routing at the network access is nothing for small networks. There are better designs for small networks. But if your network has a decent size, routing at the edge of the network can offer some benefits. Instead of working with SVIs and small transfer VLANs, a routed port is more simple to implement. Routed links can also have a shorter convergence delay, and you can reduce the usage of Spanning Tree Protocol to a minimum.

Redundancy on the first hop – VRRP

This posting is ~7 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

The Virtual Router Redundancy Protocol (VRRP) was developed in 1998 as an open standard protocol. VRRP is the result of an Internet Engineering Task Force (IETF), and it’s described in RFC 5798 (VRRPv3). VRRP was designed as an open standard protocol, but it uses some patents from Cisco. Its function is comparable to Cisco Hot Standby Router Protocol (HSRP), or to the Common Address Redundancy Protocol (CARP). VRRP solves a very specific problem at the network edge: It offers highly available virtual router interfaces, or in simple words: A highly available default gateway. Its home is the network edge, and because of this, VRRP is a so called first hop redundancy protocol. When moving towards network core, VRRP loses importance. If you move from the network edge to the core, redundancy is primarily offered by dynamic routing protocols and redundant links.

Fun fact: Its home is the network edge, but most edge switches, doesn’t support VRRP…

As already mentioned, VRRP is comparable to HSRP, CARP, Cisco Gateway Load Balancing Protocol (GLBP), or the Extreme Standby Router Protocol (ESRP).

VRRPv3 supports IPv6 and IPv4.

How does it work?

 Pretty easy:

  • at least two routers or switches that support VRRP
  • a virtual IP address
  • a virtual mac address

Okay, maybe it’s not that easy.

Key point is the virtual router. A virtual router is defined on each physical router or switch that should offer high availability for a virtual IP address. A virtual router is defined on a per-vlan base, and it consists of a virtual router identifier (VRID), one or more virtual IP addresses, and a statement that declares a router or switch as a master or backup virtual router.

The virtual mac address is build upon the VRID. The mac address is always 00-00-5E-00-01-xx, in which xx is the VRID in hexadecimal format.

The interface IP address, or switch virtual interface (SVI), that is configured for a specific VLAN, and the virtual IP address of a virtual router configured for the same VLAN, must belong to the same subnet.

Master, Backup, Owner

A router or switch can have one of two roles:

  • master virtual router
  • backup virtual router

You can have one master, but multiple backup virtual router. The master virtual router answers to ARP requests and forwards packets for the virtual IP address. The backup virtual router comes into play, in case of a failure of the master virtual router. If a backup virtual router doesn’t receive packets from the master virtual router (a period longer than three times of the advertisement time), the backup virtual routers assume that the master virtual router is dead. An election process is then initiated, to select a new master virtual router.

Master and backup virtual routers communicate via multicast using the multicast IP address 224.0.0.18.

The virtual IP address must also be a real interface IP address on a router or switch. This router or switch is called IP address owner. The IP address owner has always the priority 255. Because of this. the IP address owner will always become the master virtual router, regardless what the configuration says.

vrrp_owner_master_backup

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

As you can see, R1 has the IP 10.0.0.1/24 and the virtual IP address (VIP) is also 10.0.0.1. In this case, R1 is the master virtual router and the IP address owner.

Some vendors allow a no owner design.

vrrp_no_owner_backup_backup

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

As you can see, R1 and R2 are both configured as backup virtual router, but R1 has a higher priority. In this case, R1 will answer to ARP requests and will forward packets for 10.0.0.254. Another interesting fact: The VIP is a true VIP, and it’s not a real interface IP address of any of the participating routers or switches.

Not all vendors seem to support such a design, and RFC 5798 has no references to it. According to some other vendor docs and RFC 5798, VRRP requires that the master virtual router has the virtual IP address configured as a physical IP address, which means that the master virtual router must also the IP address owner (as mentioned above).

VRRP-E – extended VRRP

Brocade and HPE offer VRRP-E, an extended and proprietary version of VRRP. Extended means, that it overcomes limitations of VRRP (told by Brocade and HPE).

VRRP-E doesn’t know the concept of master and backup virtual routers. All routers are acting as backup virtual routers. A priority value is used to determine, which router will act as master virtual router. Furthermore, VRRP-E doesn’t know the concept of the IP address owner.

Brocade states in one of their docs:

The most important difference is that all VRRP-E routers are Backups. There is no Owner router. VRRP-E overcomes the limitations in standard VRRP by removing the Owner.

VRRP and dynamic routing protcols

If VRRP is used together with dynamic routing protocols, like OSPF, there’s a worth mentioning fact: Not a single dynamic routing protocol like it, if the IP address, which is used to build adjacencies, moves to another router. It’s not the IP address that is the problem, but perhaps the not matching routing protocol configuration, a changed router ID or similar. Because of this, the VRRP VIP must not be used in the configuration for dynamic routing protocols. A no owner design can have some benefits if you have to use VRRP and dynamic routing protocols on the same router or switch. In this case, the real interface IP addresses can be used for the dynamic routing protocol configuration, and not the floating VIP.