Asymmetric routing with Cisco ASA firewalls

Last month I installed a new Cisco ASA 5510 for a client and came across an issue where traffic was hitting the “inside” interface of the firewall before travelling back out the same interface and into another router on the internal LAN – an issue as reported in this article Cisco ASA Deny TCP (no connection)

The diagram below demonstrates the network setup with PC1 trying to communicate with PC2. When the traffic leaves the MPLS router (RED line) it does not traverse the ASA and the next packet will follow the original route (GREEN then ORANGE lines) to get to PC2

Representing the traffic flow

Long term the resolution is to place the extra routers into their own DMZ networks on the perimeter network but as this didn’t exist at the time I needed to disable the TCP SYN checking for the traffic being routed to the MPLS routers – a process described in this article by Cisco – Configuring TCP State Bypass

First thing we do is create an ACL for all the items we want to bypass the SYN check

access-list firewall_bypass extended permit ip object Local_LAN object Remote_LAN_1
access-list firewall_bypass extended permit ip object Local_LAN object Remote_LAN_2
access-list firewall_bypass extended permit ip object Local_LAN object Remote_LAN_3

Now we create a class map to match the ACL

class-map class_firewall_bypass
match access-list firewall_bypass

Then apply this to a policy map

policy-map inside-policy
class class_firewall_bypass
set connection advanced-options tcp-state-bypass

Finally we assign that policy to the inside interface on the firewall

service-policy inside-policy interface inside

Traffic that hits the inside interface of the firewall that matches the rules on the ACL will not be checked for their tcp state and traffic should now flow.

In the long term it is recommended that this isnt the adopted approach and the firewall is configured to have the traffic traverse through from the inside to a DMZ interface to prevent the issues with the TCP SYN issue

World IPv6 day got me thinking…

… and playing with IPv6 at home and I now have a partial setup of IPv6 on my home network and my parents will be going fully IPv6 from the weekend 🙂

The issues I had to overcome were firstly part of my own stupidity and then part of a need to understand how IPv6 works. First of all my ISP (BeThere) doesn’t currently support Native IPv6 on their DSL connections so I needed to get an IPv6 tunnel and Hurricane Electric’s Tunnel Broker service (http://www.tunnelbroker.net) came in very handy here as it allowed me to have a public /64 and private /48 address range which seems like a whole load of addresses that I can play with.

To get the firewall configured they actually give you a predefined sample config based on your IPv6 allocation which needed a bit of modifying to work with the setup on my firewall. The trouble was adding the /48 range to the Trust/Internal side of my network. I had configured Router Advertisement and also set the interface to be in Router mode instead of Host mode but my PC wasn’t getting anything other than the link local fe80:: address.

Following some hair pulling and discussion with a colleague I realised the issue was that the link from my PC to the firewall had a device in between that wasn’t IPv6 enabled. I should point out here that the PC and firewall are in different rooms and because its a rented property I am unable to run a nice CAT6 cable between the two. So I improvised and took and old laptop which I wasn’t using and plugged this into the PC, connected the Wireless on the laptop to my network and bridged the two connections. This works great (for the most part) with IPv4 but was unable to bridge any of the IPv6 traffic on the network.

I added the IPv6 stack to the Windows XP machine and this broke the IPv4 bridge and I lost my Internet connection and ability to communicate with the world. A swift disabling of the IPv6 brought this back and I am going to have to resort to buying a Wireless PCI card for my PC.

Undeterred by this minor setback I looked at what other devices were on my network that I could setup IPv6 with that don’t have the same issue. I am running a number of test VMs in an ESXi lab and there is a Ubuntu server and a number of Windows Server 2003 boxes running on here. Starting with the Win2K3 box I added the IPv6 stack to the network card and the server got an IP from the /48 I had been allocated. All I had to do was manually set the DNS servers using the Open DNS IPv6 DNS Sandbox and I was online.

After the success of Server 2003 working I logged into my Ubuntu 10.04 LTS server and ifconfig showed that it had automatically picked up an address from my router. All that was left for me to do was to add the Open DNS entries to my /etc/resolv.conf and I was good to go.

IPv6 works and is clearly the way forward. What I now need to do is to fully understand the address assignment and subnetting so that I can allocate networks more clearly and understand what is happening 🙂

If you want to learn more about IP addressing then take a look at the following page from RIPE (http://www.ripe.net/internet-coordination/press-centre/understanding-ip-addressing) or alternatively the Wikipedia page on IPv6 (http://en.wikipedia.org/wiki/IPv6)

Multiple Juniper SSG clusters on same network

I ran into an issue recently with a client where we were seeing a large level of packet loss to their newly installed SSG140 cluster. There were three clients sharing the same 100Mbit Internet circuit and they all connected directly into a pair of Juniper SRX210 routers.

All three clients had a firewall cluster which was either made up of a pair of Juniper SSG 140s or Juniper SSG 5s and we were seeing the packet loss on the two SSG 140 clusters.

After some investigation and troubleshooting the following KB article from the Juniper website seemed to demonstrate what the problem was: http://kb.juniper.net/InfoCenter/index?page=content&id=KB7435

The virtual MAC address for both firewall clusters public facing interfaces were the same.

Resolution? Rebuild one of the clusters to use a different cluster ID and the MAC address generated for the firewalls is different.