Posts

Posted on

Cisco Policy Based Routing Example

This time not something about Cisco ASAs or Citrix NetScaler 😉 Here a little example how to redirect traffic with policy based routing.

The workstation in the client network 192.168.0.0/24 wants to access systems in the remote network 10.1.1.0/24, its just an example the remote network can be somewhere else. So I want to redirect the traffic to the Citrix Branch Repeater in the server network 192.168.1.0/24.

Here the configuration you need to apply on the router:

interface GigabitEthernet1/0/1
ip address 192.168.0.254 255.255.255.0
ip policy route-map client-policy-map

interface GigabitEthernet1/0/2
ip address 10.1.1.1 255.255.255.0
ip policy route-map remote-policy-map

interface GigabitEthernet1/0/3
ip address 192.168.1.254 255.255.255.0

ip access-list extended client-acl permit ip 192.168.0.0 0.0.0.255 10.1.1.0 0.0.0.255
ip access-list extended remote-acl permit ip 10.1.1.0.0 0.0.0.255 192.168.0.0 0.0.0.255

route-map remote-policy-map permit 20
 match ip address remote-acl
 set ip next-hop 192.168.1.200

route-map client-policy-map permit 10
 match ip address client-acl
 set ip next-hop 192.168.1.200

Here route maps with health checking over Cisco IP SLA, see my post: Cisco IP SLA Configuration

route-map remote-policy-map permit 20
 match ip address remote-acl
 set ip next-hop verify-availability 192.168.1.200 20 track 123

route-map client-policy-map permit 10
 match ip address client-acl
 set ip next-hop verify-availability 192.168.1.200 10 track 123
Posted on

NetScaler HTTP-to-HTTPS Redirect Configuration Example

Here an easy quick example how to redirect HTTP to HTTPS, you can also do the redirect within the virtual server but then the virtual server is shown as down.

The following example is a nicer way to implement the redirect.

add responder action responder-HTTP-HTTPS redirect "\"https://\"+http.REQ.HEADER(\"Host\").HTTP_HEADER_SAFE+http.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE"
add responder policy responder-POLICY-EXCHANGE "http.REQ.HOSTNAME.EQ(\"owa.domain.com\") && client.TCP.DSTPORT.EQ(80)" responder-HTTP-HTTPS
set responder param -undefAction NOOP

add serviceGroup service-EXCHANGE-OWA_80 HTTP -maxClient 0 -maxReq 0 -cip DISABLED -usip YES -useproxyport YES -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP YES -appflowLog DISABLED
bind serviceGroup service-EXCHANGE-OWA_80 EXCHANGE-CAS01 80 -CustomServerID "\"None\""
add lb vserver vserver-EXCHANGE-OWA_80 HTTP 192.168.0.1 80 -persistenceType NONE -cltTimeout 180
bind lb vserver vserver-EXCHANGE-OWA_80 service-EXCHANGE-OWA_80
bind lb vserver vserver-EXCHANGE-OWA_80 -policyName responder-POLICY-EXCHANGE -priority 100 -gotoPriorityExpression END -type REQUEST
Posted on

Howto Update Citrix NetScaler Firmware

Log on to the NetScaler appliance with SSH, such as PuTTY. Use the nsroot credentials to log in to the appliance.

Switch to the shell prompt.

Last login: Tue Mar  4 00:03:13 2014 from 10.49.9.110
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.  All rights reserved.
 Done
> 
> shell
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
root@NetScaler01#

Run the following command to change to the default installation directory:

root@NetScaler01# cd /var/nsinstall/
root@NetScaler01# ls
10.1nsinstall   installns_state
root@NetScaler01# cd 10.1nsinstall/
root@NetScaler01# ls
build_123.9
root@NetScaler01# mkdir build_124.13

Upload new firmware in the build directory build-10.1-124.13_nc.tgz

Run the following command to extract the firmware:

root@NetScaler01# cd build_124.13/
root@NetScaler01# ls
build-10.1-124.13_nc.tgz
root@NetScaler01# tar xzvf build-10.1-124.13_nc.tgz 
.ns.version
ns-10.1-124.13.gz
ns-10.1-124.13.sha2
installns
nsconfig
bootloader.tgz
help.tgz
CitrixNetScalerManagementPackSCOM2012.msi
CitrixNetScalerLoadBalancer.msi
BaltimoreCyberTrustRoot.cert
BaltimoreCyberTrustRoot_CH.cert
Citrix_Access_Gateway.dmg
macversion.txt
apidoc.tgz
NSConfig.wsdl
NSStat.wsdl
ns-10.1-124.13-gui.tar
ns-10.1-124.13-nitro-java.tgz
ns-10.1-124.13-nitro-csharp.tgz
ns-10.1-124.13-nitro-rest.tgz
ns-10.1-124.13-nitro-perl-samples.tgz
ns-10.1-124.13-nitro-python-samples.tgz
vmware-tools.tgz

Run the following command to install the software you have downloaded:

root@NetScaler01# ./installns 

installns version (10.1-124.13) kernel (ns-10.1-124.13.gz)

  The Netscaler version 10.1-124.13 checksum file is located on 
  http://www.mycitrix.com under Support > Downloads > Citrix NetScaler.
  Select the Release 10.1-124.13 link and expand the "Show Documentation" link
  to view the SHA2 checksum file for build 10.1-124.13.

  There may be a pause of up to 3 minutes while data is written to the flash.
  Do not interrupt the installation process once it has begun.

Installation will proceed in 5 seconds, CTRL-C to abort
Installation is starting ...
VPX platform. Skipping CallHome checks.

Copying ns-10.1-124.13.gz to /flash/ns-10.1-124.13.gz ... 
.......................................................
Installing XML API documentation...
Installing NSConfig.wsdl...
Installing NSStat.wsdl...
Installing online help...
Installing SCOM Management Pack...
Installing LoadBalancer Pack...
Installing GUI...
Installing Mac binary and Mac version file...
Installing NITRO...
Installing Jazz certificate ...
Installing Call Home certificate ...
Creating after upgrade script ...

Installation has completed.

Reboot NOW? [Y/N] Y
Rebooting ...
Posted on

Common DNS errors

Something a bit different now from what I posting normally, this time about common DNS errors.

One of colleagues tried to configure basic DNS load balancing over two web platforms but instead of using two A records he were using one A record and one CNAME. Ones that was configured the problems started because some DNS server (google DNS cache) were only replying with the IP of the configured CNAME, other DNS servers from service providers were replying with nothing.

Bind per default would only add the CNAME into the configuration and ignore all other records but my colleague were using TinyDNS so I cannot say if TinyDNS load the configuration with both CNAME and A records. But the main reason of the problems was that the DNS configuration got inconsistent and the RFC for common DNS errors explained it very clearly:

A CNAME record is not allowed to coexist with any other data.  In other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record.

Have a look at the RFC about common DNS errors, very interesting!
http://tools.ietf.org/html/rfc1912

From my side I would have used GSLB (Global Server Load Balancing) and not basic DNS round-robin 😉

Posted on

Block RFC1918 and RFC3330 IP ranges

I found on the Cisco website an interesting page about protecting core infrastructure which some of the network engineers do like blocking all RFC1918 private IP address ranges. But I never thought about blocking as well all RFC3330 special use IP address ranges.

I think it is worth sharing this information, see below the overview of all RFC1918 and RFC3330:

0.0.0.0/8            "This" Network
10.0.0.0/8           Private Use Networks
14.0.0.0/8           Public-Data Networks
24.0.0.0/8           Cable Television Networks
39.0.0.0/8           Reserved but subject to allocation
127.0.0.0/8          Loopback
128.0.0.0/16         Reserved but subject to allocation
169.254.0.0/16       Link Local
172.16.0.0/12        Private-Use Networks
191.255.0.0/16       Reserved but subject to allocation
192.0.0.0/24         Reserved but subject to allocation
192.0.2.0/24         Test-Net
192.88.99.0/24       6to4 Relay Anycast
192.168.0.0/16       Private-Use Networks
198.18.0.0/15        Network Interconnect Device Benchmark Testing
223.255.255.0/24     Reserved but subject to allocation
224.0.0.0/4          Multicast
240.0.0.0/4          Reserved for Future Use

I got the information directly from the RFC3330 page and it is worth having a look.

If you are a good network engineer you should block externally not only RFC1918 but as well RFC3330 address ranges because they should not traverse the public internet. Even blocking them for outbound traffic would be very useful.

Here an ASA object group:

object-group network rfc3330-subnets
  description Group of all rfc3330 subnets incl private and special use
  network-object 0.0.0.0 255.0.0.0
  network-object 10.0.0.0 255.0.0.0
  network-object 14.0.0.0 255.0.0.0
  network-object 24.0.0.0 255.0.0.0
  network-object 39.0.0.0 255.0.0.0
  network-object 127.0.0.0 255.0.0.0
  network-object 128.0.0.0 255.255.0.0
  network-object 169.254.0.0 255.255.0.0
  network-object 172.16.0.0 255.240.0.0
  network-object 191.255.0.0 255.255.0.0
  network-object 192.0.0.0 255.255.255.0
  network-object 192.0.2.0 255.255.255.0
  network-object 192.88.99.0 255.255.255.0
  network-object 192.168.0.0 255.255.0.0
  network-object 198.18.0.0 255.254.0.0
  network-object 223.255.255.0 255.255.255.0
  network-object 224.0.0.0 240.0.0.0
  network-object 240.0.0.0 240.0.0.0
  exit

Creating access-list entry on your outside and inside interface:

access-list acl_outside-inbound remark Blocking all rfc3330 ip address ranges
access-list acl_outside-inbound extended deny ip object-group rfc3330-subnets any

access-list acl_inside-outbound remark Blocking all rfc3330 ip address ranges
access-list acl_inside-outbound extended deny ip object-group rfc3330-subnets any

Here the links to both RFC1918 and RFC3330:

https://tools.ietf.org/html/rfc1918

https://tools.ietf.org/html/rfc3330