I found out from our Cisco account team that the IPS will inspect non encrypted traffic from vpn connections that terminate on the ASA.

I'm still waiting feedback on the content filter wccp/url-filter redirection.

Anyone have any input on this capability?

Did you ever get an answer on this, specifically with WCCP redirection to a Bluecoat?? I've come across the same issue.

Thanks!

-lloyd

Hi Lloyd,

So the immediate answer is no, I never got a response on my inquiry, but I did some tests and will share the results with you. I was able to setup a Bluecoat SG on the same subnet as the internal interface of our ASA, and was able to transparently proxy/redirect web traffic for internal LAN users inside the firewall via WCCP.

I then tested proxy functions from the full tunneled, hairpinned remote vpn users, but was unable to have them redirect to the Bluecoat. I then removed/reconfigured the WCCP redirection configurations on the ASA, and associated the redirection with the outside interface (to attempt to get the remote users hairpinned traffic to WCCP proxy first).

No luck with that, however, I had to be delicate as to not break other traffic functions, so it could be that I did not properly configure the ASA. I tested this out a couple months ago and have not had a chance to revisit this yet, however, in thinking about the configuration and the process of operation, in theory the WCCP functions should be able to be configured to proxy/tranparently redirect both internal and remote vpn connected users.

One thought which I did not try was to configure WCCP instances for each interface I am attempting to proxy. So in essence, establish two separate WCCP instances between the ASA and the Blucoat.

For example, my working config for an internal user subnet is as follows:

wccp 99 redirect-list Content-Filter-Inside

wccp interface inside 99 redirect in

access-list Content-Filter-Inside extended permit ip 10.10.99.0 255.255.255.0 any

My thoughts are that a second redirect list could be made for the external vpn users, so there would be two redirect instances between the ASA and the BlueCoat.

Possibly something like the following:

wccp 98 redirect-list Content-Filter-VPN

wccp interface outside 98 redirect in

access-list Content-Filter-VPN extended permit ip 10.10.98.0 255.255.255.0 any

If you are able to test this out I would have an interest in your results.

Otherwise, anyone else care to respond with ideas?

-Scott

Thanks Scott for the response.

I was thinking of using something like the Tunnel Default Gateway feature so that I can route VPN tunnel traffic inside and it would then be subject to WCCP redirection. A few extra hops for traffic to go through but I'm talking about a Catalyst 3750 and an ASA 5510 so any extra latency most likely won't be noticed. Not sure if it would work yet but I'm hoping to do a proof of concept on it next week.

http://www.cisco.com/en/US/products/ps6635/products_white_paper0900aecd805f0bd6.shtml

I'll let you know what I find.

Thanks!

-lloyd

Hi Lloyd,

Interesting concept and I believe it will most likely work. In thinking about the manner in which WCCP works, and the location of the Bluecoat, I can see where the Tunnel Default Gateway would ensure that the remote vpn user traffic is processed by WCCP since the remote traffic would first be passed through the firewall to the inside 3750 then back out to the firewall where WCCP kicks in. The only caviate I see (which I may be mistaken) is that you are moving the external vpn user traffic through the firewall four times: 1)outside traffic to inside 3750, 2)inside 3750 traffic back out to asa, 3)asa wccp to Bluecoat, 4) Bluecoat wccp back to ASA) :)

The packets will be dizzy from all this! But I think the configuration should work and is less complex than attempting the two WCCP instances on the ASA and the Bluecoat that I proposed (if that is even feasible).

Please let me know if my understanding of your proposal is correct, and how your tests turn out!

-Scott

One way I have accomplished what you are looking for with L2L VPN connections is via GRE. If the remote device is a router, you can use GRE to create a circuit inside your network, which will allow you to hairpin the traffic back out to the internet.

Attached is an example of the relevant configurations, and a link to a topology diagram:

Other than this, the only way I know to accomplish what you are looking for is with non-transparent proxy. ie. configuring the user's browser to connect directly to the proxy server for all content.

http://i6.photobucket.com/albums/y213/suparice/VPN_GRE_alt.jpg

Following message will have the config example, this message is too long :(

Configuration example:

==========================

START Remote Router

==========================

crypto isakmp policy 10

hash md5

authentication pre-share

crypto isakmp key ahstest1 address 4.4.4.4

!

!

crypto ipsec transform-set TranSet esp-des esp-md5-hmac

!

crypto map SecureVPN 10 ipsec-isakmp

set peer 4.4.4.4

set transform-set TranSet

match address 102

!

!

!

interface Tunnel0

description Tunnel To 6513-R1

ip address 172.31.200.202 255.255.255.252

ip mtu 1395

ip ospf mtu-ignore

tunnel source 172.31.125.125

tunnel destination 172.31.200.142

!

interface Tunnel1

description Tunnel To 6513-R2

ip address 172.31.200.206 255.255.255.252

ip mtu 1395

ip ospf mtu-ignore

tunnel source 172.31.125.125

tunnel destination 172.31.200.143

!

interface Loopback0

ip address 172.31.125.125 255.255.255.255

ip ospf mtu-ignore

!

interface FastEthernet0

description Outside

ip address 4.4.4.2 255.255.255.0

no ip redirects

no ip proxy-arp

duplex auto

speed auto

crypto map SecureVPN

!

interface FastEthernet1

description LAN ACCESS PORT - VLAN2

switchport access vlan 2

no ip address

!

interface FastEthernet2

description LAN ACCESS PORT - VLAN2

switchport access vlan 2

no ip address

!

interface FastEthernet3

description LAN ACCESS PORT - VLAN2

switchport access vlan 2

no ip address

!

interface FastEthernet4

description LAN ACCESS PORT - VLAN2

switchport access vlan 2

no ip address

!

interface Vlan2

description LAN

ip address 10.99.99.1 255.255.255.0

no ip redirects

no ip proxy-arp

!

interface Vlan1

no ip address

!

interface Async1

no ip address

!

router ospf 100

router-id 172.31.125.125

log-adjacency-changes

auto-cost reference-bandwidth 1000

area 0 authentication message-digest

passive-interface Vlan2

passive-interface FastEthernet0

network 10.99.99.0 0.0.0.255 area 2

network 172.31.200.200 0.0.0.3 area 0

network 172.31.200.204 0.0.0.3 area 0

maximum-paths 2

!

ip route 67.109.188.0 255.255.252.0 4.4.4.1

ip route 140.221.8.88 255.255.255.255 4.4.4.1

ip route 172.31.200.142 255.255.255.255 4.4.4.1

ip route 172.31.200.143 255.255.255.255 4.4.4.1

ip route 192.5.41.40 255.255.255.255 4.4.4.1

ip route 192.5.41.41 255.255.255.255 4.4.4.1

ip tacacs source-interface Vlan2

!

logging source-interface Vlan2

access-list 102 permit gre host 172.31.125.125 host 172.31.200.142

access-list 102 permit gre host 172.31.125.125 host 172.31.200.143

access-list 102 permit ip host 172.31.125.125 host 172.31.200.142

access-list 102 permit ip host 172.31.125.125 host 172.31.200.143

access-list 187 remark *** DENY SPOOFING

access-list 187 deny ip 10.0.0.0 0.255.255.255 any

access-list 187 deny ip 172.16.0.0 0.15.255.255 any

access-list 187 deny ip 192.168.0.0 0.0.255.255 any

access-list 187 deny ip 0.0.0.0 0.255.255.255 any

access-list 187 deny ip 224.0.0.0 0.255.255.255 any

access-list 187 deny ip host 207.65.222.200 any

access-list 187 remark *** END DENY SPOOFING

access-list 187 remark .

access-list 187 remark *** START PERMISSIONS VPN

access-list 187 permit esp host 4.4.4.4 any

access-list 187 permit ip host 4.4.4.4 any

access-list 187 remark *** END PERMISSIONS VPN

access-list 187 remark ..

access-list 187 remark *** START PERMISSIONS EST

access-list 187 permit tcp any any established

access-list 187 deny ip any any log

==========================

END Remote Router

==========================

==========================

Core Device 1

==========================

interface Loopback1

description Loopback For GRE Tunnel To 1720

ip address 172.31.200.142 255.255.255.255

ip ospf mtu-ignore

!

interface Tunnel0

description Tunnel To 1720 Int T0

ip address 172.31.200.201 255.255.255.252

ip mtu 1395

ip ospf mtu-ignore

tunnel source 172.31.200.142

tunnel destination 172.31.125.125

!

router ospf 100

router-id 172.31.200.140

log-adjacency-changes

auto-cost reference-bandwidth 1000

area 0 authentication message-digest

network 172.31.200.140 0.0.0.0 area 0

network 172.31.200.142 0.0.0.0 area 0

network 172.31.200.200 0.0.0.3 area 0

maximum-paths 2

!

ip route 172.31.125.125 255.255.255.255 ASA

==========================

End Core Device 1

==========================

==========================

Core Device 2

==========================

interface Loopback1

description Loopback For GRE Tunnel To ARTP-806-R1

ip address 172.31.200.143 255.255.255.255

ip ospf mtu-ignore

!

interface Tunnel0

description Tunnel To 1720 Int T1

ip address 172.31.200.205 255.255.255.252

ip mtu 1395

ip ospf mtu-ignore

tunnel source 172.31.200.143

tunnel destination 172.31.125.125

!

router ospf 100

router-id 172.31.200.141

log-adjacency-changes

auto-cost reference-bandwidth 1000

area 0 authentication message-digest

network 172.31.200.141 0.0.0.0 area 0

network 172.31.200.143 0.0.0.0 area 0

network 172.31.200.204 0.0.0.3 area 0

maximum-paths 2

!

ip route 172.31.125.125 255.255.255.255 ASA

==========================

End Core Device 2

==========================

Thanks Paul for looking at this and considering possible solutions. Unfortunatley all the remote sites are ASA5505's, so GRE with the router example is out, and honestly I'm not a proponent of bringing the traffic all the way inside to reroute it back out the firewall.

Your comment about pointing the users browsers to a proxy would work aslo, but we are wanting transparent proxy services, hence our investigations into WCCP.

Here's a thought/question: Could a WCCP capable content filter (Bluecoat, Webwasher, etc) be setup on a separate interface from the inside and outside interfaces (say for example, a dedicated proxy interface), then a WCCP redirects be pointed to that interface for both the outside and inside source requests? This could then redirect both internal and external (vpn) users to the content filter, and would not have to bring outside traffic up inside for filtering.

Thoughts on this?

Thanks,

-Scott

Anyone get this working?