Thursday, February 27, 2014

Bye Bye Windows XP you will be missed

Microsoft has started to dropped the  axe on XP.



XP has to be the best success story for  Windows. It probably the longest living desktop OS that windows has put on the market.

If you compare my 1st experience windows 3.0 to XP ,  than XP was the cadillac of Desktop OS from windows.

XP you will be missed. I hope windows 7 or 8 ( cough ) will do as good :)

You can find more about MS/windows lifecycle on their web site;

http://windows.microsoft.com/en-us/windows/products/lifecycle

Ken Felix
Freelance Network / Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   ^   ^  )=
          o
       /     \


Dual VPC terminate on Fortigate firewall

If you remember this earlier posting on my cisco 1941,  and with dual AMAZON VPC-VPNs, will here's the same setup for the fortigate  series of firewalls.

1st To recap the design;


NOTE: This is not ideal in that both tunnels are terminated to the same  device, but due to the satefull inspection we are limited on a firewall. You could terminate the tunnels on 2 unique firewall and run a iBGP session between, but you will need to be cautious on  asymmetrical routing issues and the statefull inspection failures. Please see import/export route policies included in my bgp configuration section YMMV


The configuration is broken down to interfaces, crypto, bgp and firewall  & misc configurations. YMMV and your outcome could be different. This was tested on 5.0.X code

1st the interfaces;

==================== INTERFACES ======================

config system interface
    edit "wan1"
        set vdom "root"
        set ip 12.126.x.x 255.255.255.252

        set allowaccess ping 
        set ident-accept enable
        set type physical
        set alias "WAN-ISP1 ATT-pl"
    next

    edit "wan2"
        set vdom "root"

        set ip 38.x.x.x 255.255.255.252
        set allowaccess ping 
        set ident-accept enable
        set type physical
        set alias "WAN-ISP2 PSINET"
    next

 end

tunnels  configurations;

config system interface
    edit "AWSvpc1"
        set vdom "root"
        set ip 169.254.255.2  255.255.255.255
        set type tunnel
        set remote-ip 72.21.209.225
        set interface "wan1"

        set tcp-mss  1412       
        set alias "VPC_TUN1"
     next
    edit "AWSvpc2"
        set vdom "root"
        set ip 169.254.255.6  255.255.255.255
        set type tunnel
        set remote-ip 169.254.255.6
        set interface "wan2"      

        set tcp-mss  1412
        set alias "VPC_TUN2"
     next
end




==================== VPN CRYPTO STUFF  ======================


WARNING: It's suggested to use  interface mode. If you deviated from this, than your on your own DO NOT contact me !


( interface mode vpns  aka  route-based )

config vpn ipsec phase1-interface
    edit "AWSvpc1"
        set interface "wan1"
        set dpd enable
        set dhgrp 2
        set proposal aes128-sha1
        set remote-gw 72.21.209.225
        set psksecret 1blahblahblahmyPSKkey
        set dpd-retryinterval 15
    next


    edit "AWSvpc2"
        set interface "wan2"
        set dpd enable
        set dhgrp 2
        set proposal aes128-sha1
        set remote-gw 72.21.209.193
        set psksecret 2blahblahblahmyPSKkey
        set dpd-retryinterval 15
    next
end







NOTE: phase2 quick-modes selectors defaults to 0.0.0.0/0:0 which is okay for AWS

config vpn ipsec phase2-interface
    edit "AWSvpc1"
        set dhgrp 2
        set pfs enable
        set phase1name "AWSvpc1"
        set proposal aes128-sha1
        set replay enable
    next
    edit "AWSvpc2"
        set dhgrp 2
        set pfs enable
        set phase1name "AWSvpc2"
        set proposal aes128-sha1
        set replay enable
    next
end


==================== BGP CONFIGURATIONS  ======================

1st we build a few import/export policies via  a common route-maps that we will call-out for our peers


We need to adjust the local_pref on 1 peer only
We need to set metrics on the 1 peer that we want to be carrying our traffic


config router route-map
    edit "import"
        set comments "my import policy apply to one peer"
            config rule
                edit 1
                    set set-local-preference 600
                next
            end
    next
    edit "export1"
        set comments "my export policy apply to one peer only and on the primary tunnel peer"
            config rule
                edit 1
                    set set-metric 1147400
                next
            end
    next
  edit "export2"
        set comments "my export policy apply to one peer only on the path you don't want to use"
            config rule
                edit 1
                    set set-metric 2147400
                next
            end
    next

 end


And now for  the fun stuff our  bgp configs ;


config router bgp

    set as 6500

        config neighbor

            edit "169.254.255.1"

                set description "VPC1"

                set interface " AWSvpc1"

                set remote-as 7224

                set route-map-in "import"

                set route-map-out "export1"

            next

            edit "169.254.255.5"

                set description "VPC2"

                set interface " AWSvpc2"

                set remote-as 7224

                set route-map-out "export2"

            next
          end

          config network
            edit 1
                set prefix 10.10.0.0 255.255.255.0
            next
        end

NOTE:  If it's not clear here, we are setting the local_preference higher on tunnel1 to force our traffic out tunnel1 always. 

Likewise we are forcing metrics to ensure AWS steer traffic down tunnel1 over tunnel2. This helps maintain  our statefull checks. If we didn't do this, we would have to enable asymmetrical routing which is a bad bad things for firewalls


If tunnel1 fails, goes down or if AWS conduct maintenance on the datacenter that houses the  VPN termination, we revert to  tunnel2.



==================== FWPOLCIES  ======================

For the firewall-policies,  it's all up to you & on how you want to define traffic to allow. You even can opt to not advertise anything via  BGP,  and just  SNAT all traffic behind the 169.254.X.X APIPA address. I haven't tried this approach, but it should work

( a simple fwpolicies )

config firewall policy
    edit 0
        set srcintf "internal"
        set dstintf "AWSvpc1"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
    next
    edit 0
        set srcintf "AWSvpc1"
        set dstintf "internal"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
    next
    edit 0
        set srcintf "internal"
        set dstintf "AWSvpc2"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
    next
    edit 0
        set srcintf "AWSvpc2"
        set dstintf "internal"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
    next
end



==================== STATIC ROUTES  ======================

And lastly, it's best practices to place static /32 routes to the AWS vpn-terminate for the respective ISP interfaces;


config router static
    edit 99
        set device "wan1"
        set dst 72.21.209.225 255.255.255.255

        set gateway 12.x.x.x
    edit 100
        set device "wan2"
        set dst 72.21.209.193 255.255.255.255

        set gateway  38.x.x.x
    next
end
 

 

NOTE: Amazon seems strange in not wanting to support you if you use a device that's not a router.  So YMMV on how well your approach and design  & the support you get from the open community.


I hope to have a working for a Juniper/SRX in a few days,  so stay tuned :)


If your in the need for a cloud based solution,  please reach out to these fine folks at  Turing Group. They have been providing cloud based solutions with Amazon for over a year and have over  8 years within the cloud datacenter technologies and strategies

http://www.turinggroup.com
info  @   turinggroup  <dot>  com

If you need remote access solutions please contact me at email below.

Ken Felix
Freelance Network / Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   ^   ^  )=
          o
       /     \

Cisco Lanlite 2960 concerns


A look at some restrictions on lanlite  software  as of 15.0(2)SE5   C2960-LANLITEK9-M 

Cisco has confused the enterprise community with the deployment of  lanlite software supported 2960 series switches.  A lot of network engineers have been burn due to their lack of understanding differences beween lanlite and lanbase.

I’m going to reference some of the differences via the http-link here & the FAQ;



Lanlite was meant for cisco to sell a cheaper switch & with less features support. It's considered a entry level switch at best & a upgrade from their basic business model 500s series or the linksys series.

It's very restrictive, and not upgrade by any means. A lot of networks ended up forklift'ing a new switch in place if they decide that they need an important feature. I hoping to prevent you from being one of those people.



Using pricing from  CDW ,  a WS-C2960-48TT-L cost just right at 1,500.00 usd. This comes with lanbase no stacking support. A similar  2960-48TT-S with lanlite cost just over 1,000.00 usd.

If a enterprise-network engineer teams are looking at 2960s,  than you will have some limitations that you should be made aware of. I hope this post will help you recognize some of these limitations with lanlite.

The 1st  item , lanlite-codeset lack  support for the feature of stacking. This means you can not stack multiples of  2960 into a cluster. As a matter of fact, these switches that supports lanlite, has no stacking-module slot. So you have no upgrade strategy if you later need stacking support. I 've been pushing the stacking feature & you should place that on your radar.

STACKING:  reduces the number of manage ip_address devices, scales very well.


Next, security features like dynamic  arp inspection ( DAI ) are not available and the same holds true on vlan filtering. If you need these two features, you will not find them in lanlite.

Next, the 2960s models that supports 10GIG interface, are not available within  lanlite codeset.

QoS features such as "auto qos" are not support on a lanlite switch as of this code and at this time of my posting. 

Certain  QoS strategies are different between lanbase & lanlites, I'm not 100% sure of these differences but you should be & if you have voice or realtime data QoS in your  network.

Lanlite does support ipv6 addressing and management & after you've changed the sdm template to that of a dual-role support for ipv4 and ipv6. So on a good note, you have some degree of Ipv6 support for management.

But

You have no  ipv6 security filter features such as these;

  •    ipv6 neighbor protection
  •    ipv6 snooping
  •    MLD snooping
  •    ipv6 neighbor binding ( similar to what DAI does but for ipv6 btw )

Lanlite also support a limit number of vlans  when compared to the lanbase code. What 's the max number are between the two license is going to be based on the sdm template that you select. But with  lanlite it's normally 64 vlans max vrs 255 for lanbase series.

if you  have more than 64vlans or every plan on a big number of VLANs skip the lanlite. I had a customer of mine that ran into this and they struggle to realize what the root problem was



One interesting thing that I just found out recently, lanlite  has no support for  cisco "ip sla" monitoring and diagnostics. This could suck for those that are using ip sla diagnostics like myself.

And finally,  a lanlite switch is ALWAYS going to be a lanlite switch. These switches are not software upgradable. Cisco imho, screw themselves with regards to this. I personally think they should have made this a pay-as-you-go and with a license activate process. So this way you could buy a entry level switch and purchase enhancement without forklift'ing a new switch in due to you just now realize you need auto qos, more than 64 vlans or the need for more than 1 monitor span session :)



Lanlite switches do have a place in some situations, and this thread should  not be " a written in stone that all lanlite deployments are bad ". A SOHO or Small business would do great with lanlite vrs lanbase software.


So those are the things to consider when doing  lanlite or selecting the new idf-floor switch for you network


Ken Felix
Freelance Network / Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   ^   ^  )=
          o
       /     \




Wednesday, February 26, 2014

Dual VPC setup AWS cisco 1941 router

In this blog I'm sharing a dual VPC setup that was done with cisco1941 & the AWS cloud. This provides greater access to resources located in the cloud.


1st here's how a single VPC will be present in the  customer portal for Amazon Web Srvcs



With a dual VPC we have the ability to  craft redundant access. The portal will now have 2 VPCs after you configure the  2nd path.


Now after you walk thru the steps you will have a 2nd vpn gateway defined;





The cisco 1941 cfg is also quite easy to build either as either a one or two  router setup. The former is not recommended dual to a single point of failure. Either way, you will download the configurations from the AWS portal. If using 2 routers, the 2 configs will be split between the 2 routers. If your using one single router, just apply the correct vpn key-rings and  tunnel/bgp configurations.



I 'm breaking up the  configurations  in three major steps ( crypto cfg, tunnel & BGP )


==========CRYPTO STUFF===================


!  AWS gateway #1

crypto keyring keyring-vpn-7a6f8b13-0

  pre-shared-key address 72.21.209.225 key ####



! AWS gateway #2

crypto keyring keyring-vpn-7a6f8b13-1

  pre-shared-key address 72.21.209.193 key ####

!

crypto isakmp policy 200

 encr aes

 authentication pre-share

 group 2

 lifetime 28800

!

crypto isakmp policy 201

 encr aes

 authentication pre-share

 group 2

 lifetime 28800

crypto isakmp keepalive 10 10


crypto isakmp profile isakmp-vpn-7a6f8b13-0

   keyring keyring-vpn-7a6f8b13-0

   match identity address 72.21.209.225 255.255.255.255

crypto isakmp profile isakmp-vpn-7a6f8b13-1

   keyring keyring-vpn-7a6f8b13-1

   match identity address 72.21.209.193 255.255.255.255

!

crypto ipsec security-association replay window-size 128

!

crypto ipsec transform-set ipsec-prop-vpn-7a6f8b13-0 esp-aes esp-sha-hmac

crypto ipsec transform-set ipsec-prop-vpn-7a6f8b13-1 esp-aes esp-sha-hmac

crypto ipsec df-bit clear

!

crypto ipsec profile ipsec-vpn-7a6f8b13-0

 set transform-set ipsec-prop-vpn-7a6f8b13-0

 set pfs group2

!

crypto ipsec profile ipsec-vpn-7a6f8b13-1

 set transform-set ipsec-prop-vpn-7a6f8b13-1

 set pfs group2

!

!






==========TUNNEL STUFF===================





!

interface Tunnel1

 ip address 169.254.255.2 255.255.255.252
 description tunnel to AWS  gateway #1   72.21.209.225

 ip nat inside

 ip virtual-reassembly

 ip tcp adjust-mss 1396

 ip policy route-map nat_vpn

 tunnel source < your public addres here  for the ISP provider >

 tunnel mode ipsec ipv4

 tunnel destination 72.21.209.225

 tunnel protection ipsec profile ipsec-vpn-7a6f8b13-0

 !

!

interface Tunnel2

 ip address 169.254.255.6 255.255.255.252
 description tunnel to AWS  gateway #2  72.21.209.193

 ip nat inside

 ip virtual-reassembly

 ip tcp adjust-mss 1396

 ip policy route-map nat_vpn

 tunnel source < your public addres here  for the 2nd ISP provider>

 tunnel mode ipsec ipv4

 tunnel destination 72.21.209.193

 tunnel protection ipsec profile ipsec-vpn-7a6f8b13-1

 !





==========BGP PEERING STUFF=================== 
!

router bgp 65000

 bgp log-neighbor-changes
!
! we define the 2  bgp peers that are being used across the tunnels
!

 neighbor 169.254.255.1 remote-as 7224

 neighbor 169.254.255.1 timers 10 30 30

 neighbor 169.254.255.5 remote-as 7224

 neighbor 169.254.255.5 timers 10 30 30

 !

 address-family ipv4

  no synchronization

  network 0.0.0.0

  neighbor 169.254.255.1 activate

  neighbor 169.254.255.1 default-originate

  neighbor 169.254.255.1 soft-reconfiguration inbound

  neighbor 169.254.255.5 activate

  neighbor 169.254.255.5 default-originate

  neighbor 169.254.255.5 soft-reconfiguration inbound

  no auto-summary

 exit-address-family

!

Things to keep in mind, you have to source the tunnels from 2 unique  sources. 

Ideally you would   buy 2 upstream links & install them  in one of these fashions;


NOTE: the solution on the right is the better of the 2. In the 2nd solution, you would also direct a iBGP session between the 2 peers in your  private BGP-ASN#





Ken Felix
Freelance Network / Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   ^   ^  )=
          o
       /     \