01-31-2007 10:16 AM - edited 03-11-2019 02:26 AM
I've setup site2site and remote cisco vpn clients to terminate full (not split) vpn tunnels on our ASA5520. Does anyone know if the ASA can do IPS inspection and web url-redirection to an external content filter server (e.g. Websense server or WCCP to a Bluecoat) for these remotely connected clients for hairpinned traffic to the Internet?
02-01-2007 02:36 PM
Anyone have thoughts on this? Hoping to not have to open another TAC case...I think I hit the Top 10 on Tac's list since we deployed our ASA.
02-02-2007 09:28 AM
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?
05-23-2007 07:44 PM
Did you ever get an answer on this, specifically with WCCP redirection to a Bluecoat?? I've come across the same issue.
Thanks!
-lloyd
05-24-2007 07:58 AM
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
05-24-2007 10:17 AM
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
05-24-2007 10:57 AM
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
08-21-2007 06:46 AM
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 :(
08-21-2007 06:48 AM
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
==========================
08-21-2007 06:49 AM
==========================
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
==========================
08-22-2007 11:35 AM
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
04-10-2013 08:39 PM
Anyone get this working?
08-21-2007 07:04 AM
I had a setup like in a previous job with the only difference that I was using Websense. I had a pair of PIX515E running version 7.X in Active/Standby. With Websense I was able to filter the web content for the remote vpn clients.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: