wccp configuration for SSL Orchestrator
Web Cache Communication Protocol (WCCP) is a Cisco-developed content-routing protocol that provides a mechanism to redirect traffic flows in real-time. It has built-in load balancing, scaling, fault tolerance, and service-assurance (failsafe) mechanisms. Cisco IOS Release 12.1 and later releases allow using either Version 1 (WCCPv1) or Version 2 (WCCPv2) of the protocol. Well that's a mouthful; to say basically that WCCP is a Cisco developed protocol designed to load balance traffic among proxy web cache servers. The beauty of it is it’s really easy to set up on a router (and Cisco Firepower) and can intercept outbound traffic and redirect it to the proxies. The proxies do not need to be in the network path. It’s basically a form of policy based routing. And if the proxy servers are down, the router will just continue to forward the traffic down the default route. This makes it relatively easy for SSL Orchestrator to receive traffic. But I can say there’s not exactly the greatest documentation from either organization. But it's really pretty simple. The fun fact is, once your device is registered with the WCCP group on the router, it just works. As in, it just starts sending any traffic that matches the ACL off to the router. Now as for HA. WCCP was designed to handle the HA. Right? I have a pool of web caches and I’m distributing the traffic among them. But if I set up the BIG-IP using its standard Active/Standby HA and configuration sync, there’s some additional thought that comes in to play. With a configuration where both devices in the BIG-IP HA pair and each designates its local self-ip as the local tunnel address. There can be a delay while the newly active device registers with the WCCP group on the router. It’s a short blip. But a blip nonetheless. But what about using the floating IP address? Isn't that used to provide a movable HA address? Yes. Yes, it is on a normal network segment. Similar to VRRP. 01070734:3: Configuration error: In wccp /Common/wccpsg service tunnel local address (192.168.8.222) cannot be a floating self IP So you’re denied from configuring the floating self-ip from being the target. The reason is, these are treated as tunnel interfaces and in the case of using the GRE configuration for WCCP, it is a tunnel! So, peering is done between each device individually in the HA group. That means, though, that only the active device will register. What that means for failover then is that the active device registers and the standby does not. When a failover event happens, the newly active device registers and the inactive device drops out. modify net wccp wccpsg { services add {90{ hash-fields {src-ip} port-type dest ports add { 443 } redirection-method l2 return-method l2 routers add { 192.168.8.128 } tunnel-local-address 192.168.8.105 tunnel-remote-addresses add { 192.168.8.128 } } } } The most important thing is that the service group number matches. In this case, I used 90 ip wccp 90 redirect-list wccp-redirect ! interface GigabitEthernet1 ip address dhcp no ip redirects ip wccp 90 redirect in negotiation auto ! interface GigabitEthernet2 ip address dhcp negotiation auto ! interface GigabitEthernet3 ip address 192.168.1.209 255.255.255.0 no ip redirects negotiation auto ! ip route 0.0.0.0 0.0.0.0 192.168.1.1 ! ip access-list extended wccp-redirect 10 permit tcp any any eq www 20 permit tcp any any eq 443 30 deny ip any any ! ip access-list extended 110 10 permit ip 192.168.1.0 0.0.0.255 any 20 deny ip any any ip access-list extended 120 10 permit ip any any ip access-list extended 130 10 deny ip any 10.0.0.0 0.255.255.255 20 deny ip any 172.16.0.0 0.15.255.255 30 deny ip any 192.168.0.0 0.0.255.255 40 permit ip any any ! end Verifying on the Cisco router: router#sh ip wccp Global WCCP information: Router information: Router Identifier: 192.168.153.128 Service Identifier: 90 Protocol Version: 2.00 Number of Service Group Clients: 1 Number of Service Group Routers: 1 Total Packets Redirected: 34390 Process: 0 CEF: 0 Platform: 34390 Service mode: Open Service Access-list: -none- Total Packets Dropped Closed: 0 Redirect access-list: wccp-redirect Total Packets Denied Redirect: 0 Total Packets Unassigned: 0 Group access-list: -none- Total Messages Denied to Group: 0 Total Authentication failures: 0 Total GRE Bypassed Packets Received: 0 Process: 0 CEF: 0 Platform: 0 Validating which client is registered router#sh ip wccp 90 clients WCCP Client information: WCCP Client ID: 192.168.8.105 Protocol Version: 2.00 State: Usable Redirection: L2 Packet Return: L2 Assignment: HASH Connect Time: 03:23:47 Redirected Packets: Process: 0 CEF: 0 Platform: 35918 GRE Bypassed Packets: Process: 0 CEF: 0 Hash Allotment: 256 of 256 (100.00%) Initiating the failover on the BIG-IP root@(bip1)(cfg-sync In Sync)(Active)(/Common)(tmos)# run sys failover standby router#sh ip wccp 90 clients WCCP Client information: WCCP Client ID: 192.168.8.59 Protocol Version: 2.00 State: Usable Redirection: L2 Packet Return: L2 Assignment: HASH Connect Time: 00:03:26 Redirected Packets: Process: 0 CEF: 0 Platform: 6522 GRE Bypassed Packets: Process: 0 CEF: 0 Hash Allotment: 256 of 256 (100.00%) Activity on the newly active device tail -f /var/log/wccpd.log <13> Mar 27 11:56:27 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You <13> Mar 27 11:56:29 bip1.local notice wccpd-1[17bb:f59af340] WccpApp.cpp:208 : Failover status active 0 <13> Mar 27 12:22:37 bip1.local notice wccpd-1[17bb:f59af340] WccpApp.cpp:208 : Failover status active 1 <13> Mar 27 12:22:37 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:503 : <<< Got: Removal Query ! <13> Mar 27 12:22:37 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0 <13> Mar 27 12:22:37 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You <13> Mar 27 12:22:38 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0 <13> Mar 27 12:22:38 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You <13> Mar 27 12:22:39 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0 <13> Mar 27 12:22:39 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You <13> Mar 27 12:22:49 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0 <13> Mar 27 12:22:49 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You <13> Mar 27 12:22:52 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:232 : WCCP ServiceGroup 90 Sending RedirectAssign <13> Mar 27 12:22:52 bip1.local notice wccpd-0[17bb:f59af340] ServiceGroup.cpp:277 : per_bucket 1600 <13> Mar 27 12:22:52 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:329 : >>>>>>>> Sending Redirect Assign ::: Service 90 Protocol 6 <13> Mar 27 12:22:59 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0 <13> Mar 27 12:22:59 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You <13> Mar 27 12:23:09 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0 <13> Mar 27 12:23:09 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You Activity on the newly standby device tail -f /var/log/wccpd.log <13> Mar 27 11:56:07 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You <13> Mar 27 11:56:17 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0 <13> Mar 27 11:56:17 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You <13> Mar 27 11:56:27 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:212 : >>> Sending Here I Am ::: Service 90 Protocol 6 ::: SecurityInfo: Opt: 0x0 <13> Mar 27 11:56:27 bip1.local notice wccpd-1[17bb:f59af340] ServiceGroup.cpp:388 : <<< Got: I See You <13> Mar 27 11:56:29 bip1.local notice wccpd-1[17bb:f59af340] WccpApp.cpp:208 : Failover status active 0
F5 AS A TRANSPARENT PROXY FOR MOBILE USERS
What configuration can be done on F5 LTM (Only LTM in use in my environment) to enable it as Transparent Proxy for mobile users. My configuration is this : Mobile Proxy Users==>F5 (TRANSPARENT PROXY) ===> MOBILE FW ==> INternet Gateway. I only have F5 LTM in my environmentF5 LTM AS A TRANSPARENT BRIDGE (PROXY) FOR HTTP/HTTPS FOR MOBILE USERS
Hello Devcentral, I have a request to make the F5 LTM act as a transparent proxy for mobile users so their requests are forwarded straight to the firewall instead of load-balancing them to Traffic servers which are being phased out. The arrangement wanted is for requests from GGSN to hit the F5,and the requests forwarded transparently to the Mobile Firewall, so users don't have to be instructed to change their proxy on their phones. Thanks.
SSL Intercept with F5 in L2 mode
I am looking for a deployment where I configure same VLAN to the ports my client and server are connected. I would like to intercept this traffic. Is this possible on F5. The current scenario explained in the F5 doc is to have self-ips for server and client vlans and route the traffic to the F5 using these IPs. Anyone is aware of deployment without these self-ips and having client and server in the same vlan?
