We made some additional engineering changes to this router over time. We added a new network interface to the router but WCCP was not affected with the changes. When the WCCP connection was broken, the router negoiated the GRE tunnel using a new source for the tunnel. After much searching on the Cisco site I found the white paper below spelling out what I believed to be the issue with the source of the GRE tunnel being redefined on the router. I added a loopback interface on the router and removed and reapplied the WCCP configuration on the router. As expected, the new source for the GRE tunnel was the loopback address. Changes were made on the Bluecoats and the firewalls to allow traffic to traverse using the loopback address and full WCCP operation was restored.

From White Paper:

When using GRE encapsulation for WCCP redirection, the router uses the router ID IP address as its source IP address. The router ID IP address is the highest loopback address on the router, or if the loopback interface is not configured, the router ID IP address is the highest address of the physical interfaces.

Source:
Deploying WAAS Using WCCP Paper v3

ACE-1/onearm# sho run
Generating configuration….

access-list ALLOW line 8 extended permit ip any any
access-list ALLOW line 16 extended permit icmp any any

rserver host one
ip address 2.2.2.2
inservice
rserver host two
ip address 2.2.2.3
inservice

serverfarm host web
rserver one
inservice
rserver two
inservice

class-map match-all slb-vip
2 match virtual-address 1.1.1.254 any

policy-map type management first-match remote-access
class class-default
permit

policy-map type loadbalance first-match slb
class class-default
serverfarm web

policy-map multi-match client-vips
class slb-vip
loadbalance vip inservice
loadbalance policy slb
nat dynamic 1 vlan 100

interface vlan 100
description “Client-Server VLAN”
ip address 1.1.1.2 255.255.255.0
access-group input ALLOW
service-policy input client-vips
service-policy input remote-access
nat-pool 1 1.1.1.20 1.1.1.21 netmask 255.255.255.0 pat
no shutdown

ip route 0.0.0.0 0.0.0.0 1.1.1.1

After working with both vendors, we were able to determine that the router was forwarding the requests to the proxy with GRE encapsulation and the firewall was allowing the GRE traffic to traverse the firewall with ACL’s. The proxy was spoofing the IP address of the remote server but did not GRE encapsulate the traffic. The firewall denied that traffic because the packed is a SYN ACK and there was no corresponding SYN recorded. The original SYN packet was in a GRE tunnel.

The fix that we came up with was to ignore the TCP state for the web traffic. Using MPF, we were able to uniquely identify the traffic that we wanted to ignore state. This service policy gets applied on the DMZ interface where the proxy lives which means my outside interface to the Internet is not a risk and still stateful.  Below is a rough outline of what we needed to do to get this to work.  It is not the final secured version, so tweak for your environment, but we did get WCCP to work across our firewall.  The last question that I have is should the Bluecoats encapsulated the response in a GRE tunnel?  If so, then we would not have to perform the extra steps and the magic would have just happened.


access-list proxy-bypass extended permit ip any 10.0.0.0 255.0.0.0
!
class-map proxy-bypass
match access-list proxy-bypass
!
policy-map proxy-bypass
class proxy-bypass
set connection advanced-options tcp-state-bypass
!
service-policy proxy-bypass interface DMZ
!
access-list DMZ-ACL extended permit ip any 10.0.0.0 255.0.0.0
access-group in interface DMZ-ACL
! need a ACE entry to allow the traffic into the firewall after ignoring state


• BGP : Runs on TCP/179 between the neighbors

access-list 101 permit tcp any host 192.168.0.1 eq 179

• EIGRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.10

access-list 101 permit eigrp any host 224.0.0.10

• OSPF : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.5; also talks to 224.0.0.6 for DR/BDR routers

access-list 101 permit ospf any host 224.0.0.5
access-list 101 permit ospf any host 224.0.0.6

• HSRP : Runs on UDP from the source interface IP to the multicast address of 224.0.0.2. I’ve seen in the past that it runs on UDP/1985, but I didn’t find any evidence of that in a quick Google for it. Can someone verify?

access-list 101 permit udp any host 224.0.0.2

• RIP : Runs on UDP/520 from the source interface IP to the multicast address of 224.0.0.9

access-list 101 permit udp any host 224.0.0.9 eq 520

• VRRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.18

access-list 101 permit 112 any host 224.0.0.18

• GLBP : Runs on UDP from the source interface IP to the multicast address of 224.0.0.102

access-list 101 permit udp any host 224.0.0.102

• DHCPD (or bootps) : Runs on UDP/67 from 0.0.0.0 (since the client doesn’t have an address yet) to 255.255.255.255 (the broadcast).

access-list 101 permit udp any host 255.255.255.255 eq 67

Cisco Link

PDF Version

You can do an in-place upgrade on a FWSM without booting into cf:1 but if you lock yourself out of the application partition, you will be locked out of the whole FWSM if you can not get into the maintenance partition.

PDF VERSION
ONLINE VERSION

• http://www.cisco.com/web/about/security/intelligence/worm-mitigation-whitepaper.html

Application Networking: convertor to migrate CSM config to ACE
Posted by: wim.juste@kbc.be
Jun 29, 2007, 6:18am PST

Does anyone knows where to find the config convertor tool to migrate config from CSM to ACE ?

Thanks, Wim

| Outline | Subscribe | E-Mail this Message

Conversation Rating: 5.0 (1 vote)

——————————————————————————–

Replied by: gdufour – CISCO SYSTEMS, CCIE – Jun 29, 2007, 7:22am PST

it comes with the onboard http server.
Enable http in the management policy, then open an http browser the the ACE interface ip.
You should see the tool there.

Gilles.

• http://ioshints.blogspot.com/2007/11/type-7-decryption-in-cisco-ios.html

• Tim Riegert sent me an interesting hint: you don’t need password crackers to decode type-7 passwords, you just need access to a router. Here’s how you do it:

  We’ll turn on type-7 encryption for local passwords and generate a test username

  R1(config)#service password-encryption
  R1(config)#username test password t35t:pa55w0rd

  Next we’ll inspect the generated username with the show running command

  R1(config)#do show run | include username
  username test password 7 08351F1B1D431516475E1B54382F

  Now we’ll create a key chain and enter the type-7 encrypted password as the key string …

  R1(config)#key chain decrypt
  R1(config-keychain)#key 1
  R1(config-keychain-key)#key-string 7 08351F1B1D431516475E1B54382F

  … and the show command does the decryption for us.

  R1(config-keychain-key)#do show key chain decrypt
  Key-chain decrypt:
      key 1 -- text "t35t:pa55w0rd"
          accept lifetime (always valid) - (always valid) [valid now]
          send lifetime (always valid) - (always valid) [valid now]