Archive for the 'Networking' Category

SpeedStream 5260 with Qwest DSL

Published on 2009-12-02 in Networking. 0 Comments

Having just relocated to Colorado with three of these modems (I accumulated them after years of SBC/AT&T DSL service back in Connecticut), I decided that I might as well try getting one of them to work on my new Qwest circuit before spending money on a Qwest-approved modem.

Since Qwest does not support the SpeedStream 5260, I turned to the Internet to see if anyone else had done anything like this before. What I discovered is that every DSL provider seems to use its own specific VPI/VCI settings, and “ISP approved” modems are usually just pre-configured with the correct settings. For example, the correct VPI/VCI values for AT&T DSL are 0/35, while Qwest uses 0/32. So it seems that all you need to do is find out the correct VPI/VCI values for your ISP and reconfigure your modem to match.

But how do you manage a SpeedStream 5260 when it’s just acting as a bridge? As it turns out, you can always access it via telnet at its default IP address (10.0.0.1). Just give your PC a static IP address (e.g. 10.0.0.2/255.0.0.0) and plug it directly into the modem with a regular straight-through cable. Once at the command prompt, type the following command:

show vc

This will list the current VCI/VPI settings on the modem. To change them for Qwest DSL, set the VPI to 0 and the VCI to 32:

set vc 0 32 llc max

These commands appear to take effect immediately (i.e. there doesn’t seem to be a command to save the config).

Port Mapping on the Cisco PIX (Intro to Static NAT and Access Lists)

Published on 2009-01-28 in Networking. 0 Comments

I’ve found that people who have never configured a “real” firewall before often seem to get confused with the multi-step process involved in configuring port mapping on something like a Cisco PIX. But it’s really very simple when you understand the purpose of each step.

The first thing you need to do is create a static NAT rule. This is how you map a “virtual” address (i.e. a public IP address on the “outside” interface of your firewall) to a “real” address (i.e. a private IP address behind your firewall). In the following example, I’ll create a static NAT rule for a typical HTTP server:

static (inside,outside) tcp interface 80 192.168.180.2 80 netmask 255.255.255.255

This command breaks down as follows:

  • static: The command to modify static one-to-one NAT rules.
  • (inside,outside): The “real” IP address of the server is attached to the interface named “inside,” and the “virtual” IP address of the server is attached to the interface named “outside.”
  • tcp: This rule matches TCP traffic.
  • interface 80: This rule matches traffic sent to port 80 on the “virtual” IP address. Note that the “interface” keyword is like a variable that holds whatever IP address is assigned to the interface. You can use an actual IP address instead, but I like to use “interface” when possible, because it allows the access lists to keep working even if the PIX’s public IP address changes.
  • 192.168.180.2 80 netmask 255.255.255.255: Map the incoming traffic to port 80 on 192.168.180.2 with a netmask of 255.255.255.255. You always use “netmask 255.255.255.255″ when referring to a single host.

Static NAT rules allow you to direct incoming traffic to the appropriate servers behind your firewall. However, they do not say anything about who is allowed to send traffic to your servers, and the PIX will deny everything by default. This is where access lists come in. An access list asks four main questions:

  • What kind of traffic are we talking about?
  • Where is the traffic originating?
  • Where is the traffic going?
  • What do you want to do with the traffic (permit/deny)?
access-list outside_access_in permit tcp any interface outside eq http

The access command breaks down as follows:

  • access-list: The command to modify access lists.
  • outside_access_in: The name of this particular access list.
  • permit: This rule will permit traffic.
  • tcp: Match TCP traffic.
  • any: Match any source IP address. You could also specify a host or network here.
  • interface outside: Match traffic destined for the IP address associated with the outside interface. Again, you could also specify a host or network here.
  • eq http: Match traffic destined for the “http” port. Note that I could have used the port number (80) here as well.

Once the access list is created, we need to bind it to the appropriate interface. In this case, I want to bind it to the “outside” interface, since that’s where my public port 80 traffic will be destined:

access-group outside_access_in in interface outside

Virtual Private Networking on the Cisco PIX

Published on 2006-09-30 in Networking. 0 Comments

This took me a while to figure out, but now that I know all the steps, I’ve been able to set up Site-to-Site VPNs from the PIX to all kinds of different devices. The important thing to remember is that the ISAKMP and IPsec settings need to match exactly on both sides of the tunnel.

The first thing I do is create object groups for my local and remote networks. I use these object groups throughout my configuration:

object-group network VpnLocal
network-object 192.168.180.0 255.255.255.0
exit
object-group network VpnRemote
network-object 192.168.1.0 255.255.255.0
exit

Enable IKE on the outside interface.

isakmp enable outside
isakmp identity address

You need to create at least one ISAKMP policy. Note that if you create multiple ISAKMP policies, the PIX will just cycle through them (from lowest to highest priority) until it finds a match. I like to use the settings below:

isakmp policy <priority> authentication pre-share
isakmp policy <priority> encryption 3des
isakmp policy <priority> hash sha
isakmp policy <priority> group 2
isakmp policy <priority> lifetime 28800

Configure the ISAKMP key for this tunnel. The key is basically like a password that needs to be the same on both sides of the tunnel. The “remote IP” here is the IP address of the device on the other side of the tunnel:

isakmp key <the key> address <remote ip> netmask 255.255.255.255

Allow IPsec traffic to traverse the PIX.

sysopt connection permit-ipsec

Since I like to use 3DES and SHA, I create the following IPsec transform set:

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

Create an access list so that the PIX knows what traffic to send over the tunnel. Note that the “VPN ID” can be whatever you want. Since I might have several tunnels configured on the same PIX, this is just a convention I use so that I know which access list goes with which crypto map (see below):

access-list outside_cryptomap_<vpn id> permit ip object-group VpnLocal object-group VpnRemote

Configure a static crypto map for this tunnel. Just like in the ISAKMP config above, the “remote IP” here is the IP address of the device on the other side of the tunnel:

crypto map outside_map <vpn id> ipsec-isakmp
crypto map outside_map <vpn id> match address outside_cryptomap_<vpn id>
crypto map outside_map <vpn id> set peer <remote ip>
crypto map outside_map <vpn id> set transform-set ESP-3DES-SHA

Prevent VPN traffic from being NAT’ed:

access-list inside_outbound_nat0_acl permit ip object-group VpnLocal object-group VpnRemote
nat (inside) 0 access-list inside_outbound_nat0_acl

Apply the crypto map to outside interface:

crypto map outside_map interface outside

And that’s it for a typical site-to-site VPN! You can test it by pinging a device on one side of the tunnel from the other.

Now one thing you may have noticed is that the IP address of the remote VPN device is hard-coded throughout the config. This may lead you to believe that a static IP address is required on both sides of the tunnel, but that’s not the case! It’s also possible to create something called a Dynamic-to-Static VPN, in which the central endpoint does not know the IP addresses of the peer endpoints. All you need is a dynamic crypto map instead of the usual static maps for each peer. Notice that in the example below, the crypto map has a priority of 65535, which puts it at the end of the list. In other words, it’s a “catchall” for peers that don’t have a static crypto map:

crypto dynamic-map outside_dyn_map 10 set transform-set ESP-3DES-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map

You also need to create a dynamic ISAKMP key (i.e. one that applies to all hosts).

isakmp key <the key> address 0.0.0.0 netmask 0.0.0.0

Lastly, you may find the following commands useful for troubleshooting:

  • show isakmp sa – Displays the current status of ISAKMP SAs
  • show crypto ipsec sa – Displays the current status of IPSec SAs (useful for ensuring traffic is being encrypted)
  • clear crypto isakmp sa – Clears ISAKMP SAs
  • clear crypto ipsec sa – Clears IPSec SAs
  • debug crypto isakmp – Displays ISAKMP (IKE) communications between the PIX Firewall and IPSec peers
  • debug crypto ipsec – Displays IPSec communications between the PIX Firewall and IPSec peers

Permitting Minimal ICMP Traffic on a Cisco PIX

Published on 2006-09-14 in Networking. 0 Comments

By default, a Cisco PIX will not accept ICMP traffic originating from the outside interface. This means you will not be able to ping or traceroute to anything through the PIX, which will obviously make troubleshooting very difficult. The following access list will enable some useful ICMP replies.

object-group icmp-type IcmpReplies
icmp-object echo-reply
icmp-object time-exceeded
icmp-object unreachable
exit
access-list outside_access_in permit icmp any any object-group IcmpReplies
access-group outside_access_in in interface outside

A PIX will also not allow you to ping/traceroute to the outside interface by default, which means nobody will be able to ping or traceroute to you. The following commands will allow this.

icmp permit any traceroute outside
icmp permit any echo outside
icmp permit any echo-reply outside
icmp permit any unreachable outside

Enabling Remote Management on a Cisco PIX

Published on 2006-08-30 in Networking. 0 Comments

The following commands with enable the SSH server on a Cisco PIX. Note that the last command can be used multiple times in order to allow access from different networks. Alternatively, you can use “0.0.0.0 0.0.0.0″ to allow access from anywhere. Also note that when you connect to the PIX via SSH, the default username is “pix.”

ca zeroize rsa
ca generate rsa key 1024
ca save all
ssh <network> <mask> <interface>

The telnet server is enabled like this:

telnet <network> <mask> <interface>

And for you cheaters out there, the web interface is enabled like this:

http server enable
http 0.0.0.0 0.0.0.0 inside