topic Re: IPS and Content Filtering for Hairpinned Remote VPN Users in Network Security

IPS and Content Filtering for Hairpinned Remote VPN Users

swharvey — Mon, 11 Mar 2019 09:26:53 GMT

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?

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

swharvey — Thu, 01 Feb 2007 22:36:54 GMT

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.

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

swharvey — Fri, 02 Feb 2007 17:28:43 GMT

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?

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

lloyd_andrew — Thu, 24 May 2007 02:44:27 GMT

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

Thanks!

-lloyd

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

swharvey — Thu, 24 May 2007 14:58:47 GMT

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

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

lloyd_andrew — Thu, 24 May 2007 17:17:27 GMT

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

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

swharvey — Thu, 24 May 2007 17:57:43 GMT

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

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

NotMeHere — Tue, 21 Aug 2007 13:46:17 GMT

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 😞

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

NotMeHere — Tue, 21 Aug 2007 13:48:28 GMT

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

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

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

NotMeHere — Tue, 21 Aug 2007 13:49:01 GMT

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

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

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

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

rigoberto.cintron — Tue, 21 Aug 2007 14:04:13 GMT

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.

Re: IPS and Content Filtering for Hairpinned Remote VPN Users

swharvey — Wed, 22 Aug 2007 18:35:42 GMT

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

IPS and Content Filtering for Hairpinned Remote VPN Users

Steven Williams — Thu, 11 Apr 2013 03:39:51 GMT

Anyone get this working?