Wednesday, August 23, 2017

Do not be scared from WCCP

I would like to try with you (my readers) explanation in a format of Q&A , hopefully that will make it easier to understand as WCCP is not that hard.

Q:What is WCCP (web cache communication protocol)?

A:To make it simple WCCP is a protocol running between a router and a network appliance for allowing safer and smarter redirection of traffic.

Q:When you say network appliance what do you mean?

A: In WCCPv1 the protocol was used only for redirection of web traffic (and only TCP port 80) so it was clearly very limited for web application (hence the name), however since WCCPv2 the usage and capability expended and WAN optimization devices (WAAS, Riverbed SteelHead etc.) Security Appliances (Cisco WSA, Bluecoat WAF etc.) are using WCCP to receive traffic for optimization or content security handling.

Q: What are the main components of WCCP?

A: That is an Excellent Question :-) , well

  • Redirector - The Router or group of routers
  • Web Cache - That is the misleading part as is called a web cache but as mention above the network appliance can be also appliance that is performing MAPI or CIFS optimization, note that also the web cache function can be a cluster of Web Cache Engines that get traffic based on assignment method (lets elaborate on that later...)
Q: What are the responsibilities of the Redirector and Web Cache?

A: It seems like we are on the same page as you have some grate questions
  • Redirector Jobs
    • Listen for Web Cache Registration/s
    • Intercept trafic according to configuration
    • Redirect to the relevant Cache Engine according to the calculated assignment (again, we will elaborate later) in case there are multiple
      • There are 2 redirection methods (L2/GRE) 
    • Maintain state by simply exchange control messages
  • Web Cache Jobs
    • Register to a Redirector list (one or more)
    • Maintain state by simply exchange control messages
    • Receive traffic from Redirector handle and send it to its destination
Q: What do you mean by "Maintain State"?

A: When redirector want to redirect traffic first he need to know to who he can send the traffic and if the web cache is active and ready to receive the traffic, and from the other end the web cache want to know who is going to send him traffic and tell him what he allowed to send (if he want to limit him)
That state is maintained with messages that are exchanged    

Web Cache - send HERE_I_AM
Redirector - react with I_SEE_YOU

pic1: in the following you can see and example of packet capture between Redirector to Web Cache Engine


Q: You mention also something about redirection method (GRE/L2)?

A: I see you keep tracking , so yes! there are 2 Redirection methods L2 and GRE

GRE - as it sounds the router will create a GRE tunnel it will use to send traffic over to the Web Cache, the Web Cache return traffic can be L2 or Generic GRE (WAAS implementation)

L2 - simply mean traffic that need to be redirected the router will re-write the MAC destination to the Web Cache MAC address.

Show command over the router, you can see that Service ID 61 there is 1 Web Cache 1 Router Assignment HASH and redirection is GRE:


C881-K9-IL1#sh ip wccp summary
WCCP version 2 enabled, 2 services

Service     Clients   Routers   Assign      Redirect   Bypass    
-------     -------   -------   ------      --------   ------    
Default routing table (Router Id: 172.24.190.113):
61          1         1         HASH        GRE        GRE       
62          0         0         HASH/MASK   GRE/L2     GRE/L2    

C881-K9-IL1#



Q: What is HASH and MASK ?

A: The WCCP was intended to provide a scalable and robust way of redirection traffic allowing high amount of traffic to load share between multiple Cache Engines and the Algorithm used to perform load sharing is either by HASH (default in most routers) or MASK (default mostly in L3 Switches)

Q: Almost forgot , what is service ID 61 62...?

A: As you remember the WCCP started to allow only TCP port 80 redirection however as there requirement modified there was a need to make it more flexible by allowing what is called dynamic service groups, the service group can define  ports and redirection assignments based on source / destination... 

Q: Why do I need 2 or more groups?

A: Some of the Cache Engines like WAAS are doing what is called transparent proxy , that mean that traffic sent from Client to Origin (Web Server) will keep the IP SRC/DST, so if traffic will be redirected only when sent from Client to Origin the return traffic will not be intercepted and it will be an asymmetric TCP connection that will be eventuality terminated as although the session is transparent TCP ports and seq/ack are not and both Client and Server will see that they are not actually talking to each other both directions, so now you will ask me so why not just set the same Service to intercept both direction, that is a good question and the answer is each Service Group has an assignment that determine to which Web Cache to Send the traffic , if you set the same HASH to both sides your traffic may return to the Wrong Web Cache so in order for traffic to return to the same Cache Engine you need to have the flip side of the Assignment 

Sample Configuration:


ip wccp source-interface Loopback0
ip wccp 61
ip wccp 62
!
!
interface Loopback0
ip address 20.255.255.4 255.255.255.255
!
interface GigabitEthernet1
description DIRECT_WAN
ip address 20.200.0.2 255.255.255.252
ip wccp 62 redirect in
!
interface GigabitEthernet4
description "SITE_LAN"
ip address 20.2.0.1 255.255.255.0
ip wccp 61 redirect in
!
interface GigabitEthernet6
description “WAAS Segment”
ip address 20.100.0.1 255.255.255.252
 Note: That Cisco have a default preconfigured behavior for SID 61 and 62 
61 : hash is based on source IP

62 : hash is based on destination IP


OK Folks hope that provide some clarity and understanding, WCCP is really not very scary and very useful protocol :-)

Note: there are some excellent info in Cisco and also some limitation with platforms but I wanted to make sure first that there is clarity to the fundamentals

https://www.cisco.com/c/en/us/td/docs/app_ntwk_services/waas/waas/v501/configuration/guide/cnfg/traffic.html 

 

Tuesday, August 22, 2017

DNS Proxy with Juniper SRX

It is often when you come across deployments where branch users need reach an internal resource that is also mapped for external users via DNS however the problem start when user inside the corp is resolving that address over the public DNS he will get response of the public address of that resource and in order for him to reach that address packet will need to go out form the internal trust zone to outside and back in , this is what is called a DNS Split Horizon problem!

to fix that you can either use some static host configuration that is very unscaleable or use a DNS proxy and Internal forwarders, for that there are 2 main methods (with Juniper SRX):

Method 1 

Split DNS configuration where all DNS traffic is default to 8.8.8.8 with the exception of sguez.net that is using 198.168.1.200 (Internal DNS)
root@SRXv01# show system services dns | display set 
set system services dns dns-proxy interface ge-0/0/1.0
set system services dns dns-proxy default-domain * forwarders 8.8.8.8
set system services dns dns-proxy default-domain sguez.net forwarders 198.168.1.200


[edit]
root@SRXv01#
Important part when configuring dns-proxy over SRX is to enable the dns system service  

root@SRXv01# show security zones security-zone trust host-inbound-traffic | display set
set security zones security-zone trust host-inbound-traffic system-services dns

[edit]
root@SRXv01#

Method 2


Split DNS configuration where all DNS traffic is default to 8.8.8.8 with the exception of sguez.net that is using 198.168.1.200 (Internal DNS) and for external resolve via (external DNS) based on request source (clients IP's):

root@SRXv01# show system services dns dns-proxy | display set 
set system services dns dns-proxy interface ge-0/0/1.0
set system services dns dns-proxy view internal match-clients 192.168.0.0/16
set system services dns dns-proxy view internal domain sguez.net forwarders 192.168.1.200
set system services dns dns-proxy view external match-clients 172.24.190.114/28
set system services dns dns-proxy view external domain sguez.net forwarders 192.168.1.201

[edit]
root@SRXv01#

Also with that configuration do not forget the enable for dns system services

root@SRXv01# show security zones security-zone trust host-inbound-traffic | display set
set security zones security-zone trust host-inbound-traffic system-services dns

[edit]
root@SRXv01#

Verification for both:


Clear Cache:
root@SRXv01# run clear system services dns-proxy cache
Show Cache:
root@SRXv01# run show system services dns-proxy cache 
Clear Statistics:
root@SRXv01# run clear system services dns-proxy statistics 
Show Statistics: 
root@SRXv01# run show system services dns-proxy statistics  

Further Reference: