ASA 5505 Easy VPN & 3rd/DMZ interface

[kemahnken]

We have many new and very small remote sites that will be connecting via an ASA5505 using easy VPN.  Works without an issue and we've got the configuration and process nailed down.

The challenge I was presented with today involve non-standard remote sites where I need to configure a third interface on an ASA 5505 and allow it to pass directly to the Internet and not go through the VPN.  Configuration of the third interface, assignment and configuration of the ACLs / NAT(PAT) are straight forward.

The challenge I face and haven't been able to find a direct answer to is if it's possible to have the traffic bypass the easy vpn network extension process.  At this time the traffic is going down the tunnel which isn't what I want.

I fear I'll have to build classic site-to-site VPN configurations which isn't a huge issue though it breaks all maintenance/operations methods, processes and I'll have to spend time training the support team how to detect the differences.  I.E. yes I can build it though someone else has to support it, which means different is an issue.

Thanks,

[Jennifer Halim · Accepted solution]

What version of ASA software are you running?

I found this in the configuration guide that suggest that only the highest security level interface will be encrypted through the Easy VPN tunnel, if you are running ASA version 7.2.3 and above:

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ezvpn505.html#wp1025408

So if your DMZ does not have the same security level as your inside interface, traffic from DMZ should not pass through the tunnel.

Also, do you have split tunnel configured on the Easy VPN server for this Easy VPN client group?

[kemahnken]

Thank you for the link and insight.

The configuration I had followed what was presented in the link.  You do not need to create split tunnel defintion in the profile.

What I discovered was that UDP will fail when translated to the primary outside interface.  Of if the outside interface is 172.16.1.240 ping will fail as the IPSEC over translation handles the reply packet.  This was my issue as I started with PING instead of just going for a valid web site.  To resolve this issue and enable diagnostics using ping or traceroute you have to dynamic translate to another address.  So the IPSEC runs over 172.16.1.240 and in my lab the 3rd interface uses 172.16.1.241 so ping / traceroute work correctly.

Of course you have to add permits on the outside interface which in my case was 2 statements.

Once again thank you for your assistance and guidance!

KM:)