cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1301
Views
0
Helpful
8
Replies

traffic filtering for webvpn is not working while hairpinning

Dikkia
Level 1
Level 1

Hi All,

as per subject i have a problem with hairpinning and webvpn

 

my gears:

HQ with asa5525x  9.6.4.10

cisco anyconnect 4.5.03040 for client to site remote access

 

design:

remote users connect FROM outside interface using ssl webvpn anyconnect client.

They are able to reach internal resource ( throught inside interface ) and External resources  (through outside interface ) cause hairpinning is enabled ( same-security-traffic permit intra-interface ) and nat is performed (outside to outside )

all the traffic is tunnelized via sslvpn (no  split tunnel).

 

what is the problem?

well....problem is that, with this design,  i'm not able to filter vpn traffic that reach outside resource. everthing is permitted ( CISO is not happy with that )

if i configure an outside to outside rule ( for example a DENY acl  with source "vpn ip pool"  and destination " public Google server" ) .....the ACL is simply ignored.

it seem is not possible to filter outside to outside traffic with "normal" acl using "regular" interfaces.

 

I tried to learn why it doesn't work and it seem because the "usual" acl are not hit in this scenario.

does anyone know a way to accomplish outside to outside  filtering in a SMART way?

it seem there are a couple of ways using:

1)ldap attributes +identity management services...

or

2) split the user and internet traffic on different phisical interfaces

 

but 

a) first solution  require a strong user profiling and system integration

and

b) second solution require re-design of the network and thus downtime.

 

my constraints here are the "time to implement" and the "no-downtime" because is a live production environment wth 600 users  and currently they are allowed to do everithing towards outside ( internet )....

 

any help would be appreciated

1 Accepted Solution

Accepted Solutions

Marvin Rhoads
Hall of Fame
Hall of Fame

Assuming you are doing full tunnel for your users, you could simply add a vpnfilter.

An ACL won't work as that applies to the interface and not to the unencrypted traffic.

See this document (old but still valid) for more details:

https://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/99103-pix-asa-vpn-filter.html#anc4

View solution in original post

8 Replies 8

Marvin Rhoads
Hall of Fame
Hall of Fame

Assuming you are doing full tunnel for your users, you could simply add a vpnfilter.

An ACL won't work as that applies to the interface and not to the unencrypted traffic.

See this document (old but still valid) for more details:

https://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/99103-pix-asa-vpn-filter.html#anc4

Hi Marvin,
thx, this is really a good start point that will adress the big security hole i have at the moment...but....what about if i want to be more granular?

i elaborate:
yes...i perform full tunnelling ( no Split T )...and if i apply the vpnfilter.... that specific filter will be applied to ALL 600 users because its applied at the common "Group-Policy"....
i also need to differentiate users grant...so i assume i have to differentiate them ( via static ip or user identity such username ) and than apply proper rights/acl's.

as you can immagine i can't provide same level of access to all 600 users, i have to differentiate them somehow.
in your opinion is there a SMART (again) way to accomplish this?

what comes in my mind now are:
a) downloadable acl pushed by the ACS and the LDAP grouping...
b) different "Group-policy" ( and thus different vpnfilters ) ...but this still require user identity grouping...
c) assign ip's statically to users and than "play" with source and destinations in vpnfilters...

again. many thx for your support.

btw, i think i'm gonna pursue the vpnfilter suggestion...even if....a new problem arise.
for several reasons my internal routing table is composed by approx 2000 entries ( some contractors inject several global network to my routing table and is not possible to filter them )......and if i use the vpnfilter conf....i guess i have to create 2000 entries at least ( for sure i can summarize some but....i expect a reduction of 20 or 30 % max )

is there a way to add the rouing table (as destination) dinamically to the filter created for vpn traffic? this would speed up the implementation and it will avoid blocks while routing table changes due to external factor ( new received routes or deletion of some ).

many thx

Unique vpnfilters can be set per user or per group-policy. Yes it does get unwieldy for large numbers of users.

 

I would suggest you step back and think is a VPN with all of this filtering really the best technology for the business use case. You haven't shared what that is so I can't suggest any alternatives.

sure, but i guess that unique vpn filter may contain several ACE ( destinations ) within the filter .....right?...so is there a way to fullfill the vpnfiler with the entries collected by the device routing table...automatically? if not,  i will do with my hands...line per line....!

about hte "step back" you are obviusly right but...due to Coronavirus i had to increase the number of users vpn's to let people work from home for a long period of time..so i started with the "normal" 20 users ( usually managers who require no restrictoins ) to approx 650 users that have eterogeneous needs.....and i can't give them an "allow any" policy....so...i'm in the situation that i have to restrict access with  the gears currently owned.


the vpn increase  was simply NOT planned   ;)

 

for better understandings
i also have ACS and LDAP that can be handy (and ISE that is under installation ) with a proper planning but....this approach ( that i consider the best ) will require deeper planning and longer time.
that's why i've asked for a quick solution that is able to adress as much as cases as possible,  knowing that it WON'T cover everithing

my plan for the NEXT FUTURE is to use ACS/ISE and LDAP user groups attributes to identify the users and thus properly authorize them...but...for shorter term..i'm looking for a smart solution that ( as said before ) restrict ( as much as possible ) the hole created by hairpinning and lack of interface based control .


hope it makes sense for you.
again...thx for your help and suggestions

How do you restrict what systems the users can reach when they are on-site?

in several ways.

 

l2 segregation

L3 ACL applied on inside asa interface for internet access + proxy for web traffic

L3 ACL applied on inside asa interface for internet access using other protocols

AD "logon to" on each user to provide access from specific machines and specific users to specific destination servers

AD Group access

application  autentication ( 2 factor auth or multilayer auth )

and probably Others ways that are not  coming in my mind.

btw...

the main question ( using vpn filters ) is if it's possible to dyanic populate  the ACE that build the vpnfilter or not.

i repeat...this is not the best solution...i'm aware of that.....it's just the fastest one that provide an acceptable ( for now ) level of security without modify current design, integrate several systems and effort in identify users needs.

thx

i've just realized that i do not really need to populate the vpnfilter with the routes included in the routing table ( my mistake )

what need to be done is to configure the vpnfilters exactly as current inside to outside acl's are configured right now. 

i have to add also the inside to outside acl currently configured in another firewall that the LAN users hit when they have to reach other internal destinations and i've to add also the local lan network in the vpn filters.

 

this way i should cover ALL the use cases with approx 350 acl instead of 2500 entries :)

 

than i will re-design the solution with calm and i will implement the users-identity access with ldap..ise and so on.

@Marvin Rhoads i want to thank you for the help provided.  you gave me the starting point for the technical feasibility.

thx again and keep safe   ;)