Deployment Method Questions

Kelvin Willacey · ‎06-09-2009

After going through the deployment section of the user guide to try and have a better understanding of how to deploy the appliance, I find myself needing some answers, if I were to deploy the device as a transparent proxy. I hope someone can oblige.

1. The appliance can be deployed using WCCPv2 or a L4 switch, I understand that with WCCP traffic will be redirected to the appliance. Should this be all traffic or should it be http and/or https traffic only? The other method is to simply connect it to a L4 switch and the guide provides no explanation of how this works. How is this accomplished? Is it feasible to configure WCCP on the L4 switch and redirect traffic to the appliance as well?

2. L4 traffic monitoring can be accomplished by using a span port, network tap or a hub. If I am to also enforce blocking and not just monitoring it says that the Web proxy and the L4 monitor must be on the same network. I don't understand, why is this so? Does the L4 traffic monitor port need an IP address?

Thanks a lot and I hope someone can help.

jowolfer · ‎06-10-2009

1. The appliance can be deployed using WCCPv2 or a L4 switch, I understand that with WCCP traffic will be redirected to the appliance. Should this be all traffic or should it be http and/or https traffic only?

WCCP requires the specification of up to 8 ports to redirect. At a minimum you would need to redirect port 80. If you intend to do HTTPS proxy as well, you'd need to redirect port 443 as well as 80.

The other method is to simply connect it to a L4 switch and the guide provides no explanation of how this works. How is this accomplished? Is it feasible to configure WCCP on the L4 switch and redirect traffic to the appliance as well?

Each L4 switch will need it's own customized configuration, in order to redirect traffic. On a Cisco switch, you'd need to use policy based routing.

It's an either / or situation. You would use either WCCP or L4 policy based routing, never together.

If your switch supports WCCP, I'd highly recommend using it over policy based routing.

2. L4 traffic monitoring can be accomplished by using a span port, network tap or a hub. If I am to also enforce blocking and not just monitoring it says that the Web proxy and the L4 monitor must be on the same network. I don't understand, why is this so? Does the L4 traffic monitor port need an IP address?

the L4TM interfaces (T1/T2) are passive listening ports. They just see where your clients are accessing. In order to block this traffic, the L4TM will use the proxy interface (M1 or P1) in order to send a TCP RST packet to the offending client and server.

If the P1 interface is not on the same network as the L4TM passive ports, the RST sent out P1 will never get to the client.

Kelvin Willacey · ‎06-11-2009

Thanks a lot for your response, I know understand why it has to be in the same network I don't understand how it would work. Is it that in a multiple vlan environment a remote span vlan has to be setup for the L4TM port so that it can see all the traffic and ensure that both it and the P1 port are in the same vlan?

jowolfer · ‎06-12-2009

Multiple VLANs will work fine as long as the P1 interface has a route to the clients, so that the TCP RST is received.

scraig84_ironport · ‎06-16-2009

Each L4 switch will need it's own customized configuration, in order to redirect traffic. On a Cisco switch, you'd need to use policy based routing. 

It's an either / or situation. You would use either WCCP or L4 policy based routing, never together. 

If your switch supports WCCP, I'd highly recommend using it over policy based routing. 

the L4TM interfaces (T1/T2) are passive listening ports. They just see where your clients are accessing. In order to block this traffic, the L4TM will use the proxy interface (M1 or P1) in order to send a TCP RST packet to the offending client and server. 

If the P1 interface is not on the same network as the L4TM passive ports, the RST sent out P1 will never get to the client.

Interesting. This isn't my understanding of the L4 Monitor. This is from the admin guide:

L4 Traffic Monitor (L4TM) deployment is independent of the Web Proxy deployment. When
connecting and deploying the L4 Traffic Monitor, consider the following:
• Physical connection. You can choose how to connect the L4 Traffic Monitor to the
network. For more information, see “Connecting the L4 Traffic Monitor” on page 27.
• Network address translation (NAT). When configuring the L4 Traffic Monitor, connect it
at a point in your network where it can see as much network traffic as possible before
getting out of your egress firewall and onto the Internet. It is important that the L4 Traffic
Monitor be ‘logically’ connected after the proxy ports and before any device that performs
network address translation (NAT) on client IP addresses.
• L4 Traffic Monitor action setting. The default setting for the L4 Traffic Monitor is monitor
only. After setup, if you configure the L4 Traffic Monitor to monitor and block suspicious
traffic, ensure that the L4 Traffic Monitor and the Web Proxy are configured on the same
network so that all clients are accessible on routes that are configured for data traffic.

It wouldn't make much sense in my mind to do the L4 without the proxy as you would have no way of gathering user info etc. Also, my understanding is that the L4 monitor is for malware - not category-based blocking.

Last, I don't believe any of this requires policy based routing at all. The proxy uses WCCP or explicitly forwarded browsers. The L4 monitor uses a SPAN port or similar - generally sniffing traffic going to the firewall at the point of ingress.

jowolfer · ‎06-17-2009

scraig84,

You're confusing the difference between using an L4 switch (PBR) to route client HTTP traffic to the WSA proxy versus the Layer 4 traffic monitor (L4TM) functionality within the WSA.

The WSA proxy can receive HTTP traffic from clients via one of the following methods:

WCCP
L4 Switch PBR
Explicit browser configuration (includes .pac files)

The L4TM is a completely separate service that promiscuously sniffs traffic to learn DNS values, match IP black/white lists, and TCP RST 'bad' traffic'.