Teneo !!!

Aaron’s blog on Networking, and Enterprise Technology

Cisco PIX/ASA VPN access to DMZ ?

4 Comments Posted by Aaron Paxson on October 24, 2007

How many times has someone wanted to access the DMZ (or some other network other than "inside") from the VPN? Why didn’t it work? Did you figure it out?

Well, the problem stems from IPSec. See, IPSec and NAT just do not get along. Mainly due to the security inherit in the protocol. So, how do you get around it? Well, you tell the ASA/PIX not to NAT your VPN traffic.

Let’s assume I have two networks: (inside) 10.10.10.0/24 and (dmz) 172.16.1.0/24 and let’s also assume that the VPN is being attached to the inside interface.

Create an access-list to match the VPN Traffic to the DMZ:

access-list DMZnoNAT permit ip 172.16.1.0 255.255.255.0 10.10.10.0 255.255.255.0

Now, apply the access-list to the NAT statement on the interfaced named ‘dmz’, so it will not be nat’d (i.e. 0)

nat (dmz) 0 access-list DMZnoNAT

Done! You should now be able to pass VPN traffic from 10.10.10.0 to the DMZ on 172.16.1.0, because we are no longer NAT’ing the traffic, and IPSec is happy again!

Powered by Qumana

Security, Switching/Routing

← Swearing at your co-workers? Good? Microsoft Project on Linux! →

4 responses to “Cisco PIX/ASA VPN access to DMZ ?”

Anthony October 24, 2007 at 1:07 pm
Speaking of IPSEC and NAT…

What is the rule in which you would need to implement NAT-T for a VPN tunnel? I always hear it’s when a NAT device is sitting inbetween the two devices participating in the tunnel, however, I have seen that work without NAT-T as well. Or maybe NAT-T was on by default and I didn’t know it?

Thoughts?

Reply
Aaron Paxson October 24, 2007 at 1:32 pm
It’s been my understanding, that you are correct. See, IPSec does not like any device messing with it’s packets. To do so, would break the security that IPSec implements. Not only that, but NAT uses ports to map the global connection to the local connection. However, IPSec doesn’t have ports, only a protocol number (protocol 50 if memory serves). Since IPSec doesn’t use ports, how can NAT properly NAT it?

So, now comes NAT-T (or NAT Traversal). This is where the peer encapsulates the IPSec packets inside a UDP Packet, and UDP CAN traverse through NAT, but both sides must be configured for it, as the remote peer would have to decapsulate it, in order to read the packet.

The only time I’ve not used NAT-T, and it still work across NAT’d routers is because I would configure the Cisco VPN CLient (and concentrator) to use TCP Port 80 to establish all the sessions (in that case, I’m not encapsulating in UDP, but rather TCP, and port 80 is usually allowed through most firewalls). Doing so would not require NAT-T. Could that be it?

Reply
Dion December 14, 2007 at 10:38 pm
Dear Aaron,

Thanks for your posting.

I have really been struggling with having a remote access vpn client terminate on the outside interface of an ASA 5505 and am battling to implement your suggestion here to give the client strict access to the dmz. Would it be possible to post a portion/entire configuration of what you posted initially to give me a better idea?

Blessings,
Dion

Reply
Tiago Durante November 9, 2009 at 9:03 am
Great tip! Thanks!

Reply