Sunday, March 27, 2011

Bricked Linksys WRT54GS v1.1

I recently managed to pseudo brick an old Linksys WRT54GS (the specifications of the various WRT54 series wireless routers are here : Wikipedia article

Anyway, I accidentally broke it with an OpenWRT update that went badly. I did not want to have to create a Jtag for it, if I could avoid it. I tried a  30/30/30 reset. That failed. The router would power on and the DMZ light would turn on for five seconds and then turn off. This continued indefinitely.

After looking it, up it appeared that the boot loader was working, but that the firmware image was missing or corrupt. I followed the advice I found on several locations:

Attempt to push the stock Linksys firmware to the device using TFTP. It looked like the simplest way to do that would be to use the DrayTek Vigor router tools. Specifically, I used their "firmware upgrade utility." It worked on the first try. It's a simple process:


  • I set the ethernet interface on my laptop to be on the stock 192.168.1.0/24 network. I could ping the host with no problems.

  • I pointed the firmware upgrade utility to the latest official Linksys/Cisco firmware for the WRT54GS hardware version 1.1 router.

  • After the router rebooted, I had the stock firmware running on the default address (192.168.1.1) with the default password (no username, admin as the password.)

    I later installed DD-WRT using the built-in Linksys firmware update page. DD-WRT. I could have used Tomato or OpenWRT again, but I wanted to try out DD-WRT. I'll likely write a post or two about my experience with DD-WRT.








     
  • Thursday, February 10, 2011

    Upgrading Cisco Catalyst Switch Firmware Using Archive Command

    I had to upgrade some old Cisco Catalyst switches to the latest firmware. The problem was that the flash contained the old firmware... and the delete command did not seem to honor the /r/f flags (at least in this old version from the year 2000.)

    To clear out the html dir on the Cisco switch:

    delete /force /recursive flash:html/*


    Assuming my tftp server's IP is 172.18.27.40 and I have a cisco firmware tar file called "c35xx-new-version.tar" in the root of the tftp server, I upgrade like so:

     archive tar /extract tftp://172.18.27.40/c35xx-new-version.tar flash:
    (or archive tar /xtract tftp://172.18.27.40/c35xx-new-version.tar flash:  - depending on version)
    (later versions of IOS use the flag /xtract instead of /extract.)

    As always, try this at your own risk.

    Thursday, January 27, 2011

    Checkpoint UTM Firewall Clusters Part 4 - NoNAT Rules

       Cisco ASA administrators will be well familiar with noNAT rules... those NAT ACLs listed under NAT 0. It's a similar configuration for the Checkpoint. Using the network groups I created in part 2 of this series,
    Checkpoint UTM Firewall Clusters Part 2: Anti-Spoofing

    One can create individual NoNAT rules like so:

    To prevent NATing between the corp_net (192.168.6.0/23) and the DMZ, you can create a pair of rules (make sure they are above your implied rules!):








    Of course, you might want to avoid any NATing between internal VLANs/subnets. Using our previously created simple group, inside_networks (it contains corpnet, eng_net, qa_net, and router net):






    That should do it.

    Checkpoint UTM Firewall Clusters Part 3 - Overloading NAT and PAT, Proxy Arp

       In this instance, we're going to cover a 1 to 1 NAT (a bi-NAT) and an overload of a single port for the same address. Refer to the first part in this series to get a better idea of the topology:
    Checkpoint UTM Firewall Clusters Part 1


    In this case, we have a web host (172.31.22.80) and an SSH server (172.31.22.22) in the DMZ. We want to create a 1 to 1 NAT (outside address 10.10.80) for the web host, but we also want port 3322 on the outside address to NAT to port 22 on the SSH server. Here's a diagram:



    You will note that I left out some of the infrastructure in this drawing - simply for clarity.
        Anyway, we should create a host node for the web server, set up the NAT, and then create the NAT rule to override port 3322 on the same external address.


    1. Create the node:



    2. Now, set the NAT on external address 10.10.10.80:


    3. Now, create an override rule for the SSH server (we just created a node for the external address, the internal ssh address, as well as a new TCP object - port 3322):
     Here's the override:



    4. We'll follow up by adding a rule to allow traffic in on the firewall. This requires 1 rule:






    That's basically it. If you do not have a static entry, but have a bunch of PATs, you'll notice that the firewall will not automatically proxy arp for the external address. This can be fixed by using the method above for a single 1 to 1  NAT or by editing local.arp on each firewall. This file is in $FWDIR.

    Checkpoint UTM Firewall Clusters Part 2 - Anti-Spoofing

    The first problem I ran into with the Checkpoints is the built in anti-spoofing technology. Refer to my last post to get a sense of the topology: Checkpoint UTM Firewall Clusters Part 1

    Here's the diagram again:













    Anyway, the problem is internal routes. In my example, I have a layer 3 switch handling internal routing. The steps are:

    1. Log into each Checkpoint cluster member and add static routes. You can use either ssh with the sysconfig utility, or use a web browser and go to each firewall (typically port 4434.) In this example case, you'll add:

    subnet netmask gateway
    172.17.16.0 255.255.252.0 192.168.5.200
    192.168.6.0 255.255.254.0 192.168.5.254
    192.168.8.0 255.255.254.0 192.168.5.254
    192.168.10.0 255.255.254.0 192.168.5.254

    Note that 192.168.5.254 is the layer 3 switch.




    2. Create subnet objects for each of the internal networks/VLANs.

    Ignore CP_default_Office, it's part of the demo network config.





    3. If you look at the cluster interface topology, you'll see:



    And if we drill down further:




    And further into the internal interface (where our corp, eng, QA, and colo interfaces reside behind:


    And now to the "Topology tab"

    Topology anti-spoofing config


    This configuration will block the eng, qa, and corp subnets. Depending on the configuration, the Co-Lo net may never need to talk to anything that the firewall manages (DMZ1, etc.) But, better safe than sorry.
    4. Create a simple group and include all four subnets:
















    5. Now, go back to the topology anti-spoofing config in step 3 and modify it to use the group you created.























    There, anti-spoofing should work correctly. Make sure NAT is configured properly!

    Checkpoint UTM Firewall Clusters Part 1

        I recently spent some time setting up a Checkpoint Firewall cluster using UTM firewall appliances. I'm going to post several configuration tips I learned the hard way. I did not find the documentation to be all that useful, though I was in a bit of a rush, so I might have missed something.
       Anyway, I'm laying out the topology in this post. Here are our nets:


                                                                                                                                                                                                                                                                                                                   
    Interface NameSubnetComments
    ext10.10.10.0/24external network
    int192.168.5.0/24router net
    LAN1172.31.24.0/28sync network
    LAN2172.31.23.0/24network management subnet
    LAN3172.31.22.0/24DMZ1
    N/A192.168.6.0/23Corporate LAN (behind L3 switch)
    N/A192.168.8.0/23Engineering LAN (behind L3 switch)
    N/A192.168.10.0/23QA LAN (behind L3 switch)
    N/A172.17.16.0/22subnet from CO-LO - from VPN tunnel




    Note that there is a layer 3 switch behind the inside interface on the Checkpoint cluster, and that at least three VLAN/subnets are behind that switch. Note that there is an IPSec tunnel to the co-lo facility, and that tunnel terminates on the L3 switch in the router network (the endpoint is 192.168.5.200.)
    Here is a simple diagram of the configuration:

    Thursday, December 2, 2010

    vchanger, Bacula, and "ERR=Unknown error during program execvp"

     After upgrading Bacula to 5.0.3, I started getting an error message when attempting to load a tape:


    ERR=Unknown error during program execvp


    I suspected it was a problem with vchanger, as it couldn't load/unload tapes, either. After looking in the disk that vchanger happened to be using, I discovered that drive0 obviously had a tape in it, but the file loaded0 was empty. I determined which "tape slot" was empty, added the name of the slot to the file loaded0, and unloaded it. Everything worked after that.