Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

PIX/ASA NAT and IPSEC tunnelling

I've got several sites with IPSEC tunnels built between PIX firewalls to encrypt/sign the traffic moving between the "inside" networks on those firewalls.  These sites use identity nat where every inside address is directly natted to the same address on the outside i.e. STATIC(inside, outside) netmask

But I've just added a new site where things are different.  The WAN link terminates on the inside of the firewall and there are hosts on the outside we want to reach.  These remote hosts are statically NATed to inside addresses, and our inside interfaces are Dynamically NATed to an outside address, i.e.
static (outside, inside) netmask
global (oustside) 15 netmask
nat (inside) 15

Can I define an IPSEC tunnel that terminates on the inside interface that carries traffic to/from an address on the same subnet as the interface?

The attached diagram may make this clearer.

Assuming this is possible I would think on the "local" PIX firewall I could create an acl to define the interesting traffic:
access-list newsite-vpn permit ip 255 255.255.0 host
and use it for VPN.

on the "remote" firewall, would the access-list look like:
access-list newsite-vpn permit ip host

I'm just not clear on where in the "flow" the IPSEC tunnel handling is.  I'm assuming it's between the interface and any NATing and access rules.



Re: PIX/ASA NAT and IPSEC tunnelling

It looks like the local network that you want to encrypt is in front of the ASA, relative to the subnet.  If someone on the subnet wants to send data to the subnet, I imagine they send it to the next hop router, not to the ASA.

I don't think the NAT comes into play, as it is used to make the .100 server on the inside network appear to have an address on the outside network of the ASA.  

Given the current infrastructure, the most logical place to put the VPN tunnel endpoint on the local side is on the router (.97).  The cleanest solution, if possible, is to use the routers as VPN tunnel endpoints on both ends, given that the PIX running v6.3 at the remote site is obsolete.  The routers would have to support VPN with hardware encryption.

If you have to make it work with what you already have, could you create a separate subnet connecting the ASA to the .97 router?  That way, devices on the subnet could use the ASA as the (new) default gateway for everything, then you could create a VPN tunnel using the new interface on the ASA as a tunnel endpoint.


New Member

Re: PIX/ASA NAT and IPSEC tunnelling

We don't control the router, so the configuration is sort of stuck as it is.

I was hoping that since the is not a physical device, but a NAT of the actual server we are trying to reach, that the tunnel would work.

The connection flow would be initiates a connection to

Firewall A sees the traffic, builds the tunnel with, and ships the encapsulated packet along.

Firewall B decrypts the packet, and says "oh, this is for, which is a NAT address.  So it checks ACLs and then does it's NATing, so the source and destination are now and

Server gets the packet and sends a reply.

Firewall sees the reply, and translates the source and destinations back to

Firewall sees the outbound traffic matching a VPN rule, builds the tunnel to, and ships the encapsulated packet along.


Re: PIX/ASA NAT and IPSEC tunnelling

The .100 address is NAT'd for those on the outside of the ASA, not for those on the other side of the WAN.  Clients on the subnet see the actual network address,  If you set up a VPN tunnel between these subnets I don't see the need for an additional NAT.

If there is any way to create a new subnet between the router and the ASA, I still think that is your best bet.

If you need to make things work as they are, there is a command on the ASA that allows you to send traffic out the same interface as it was received.

same-security-traffic permit intra-interface

However, this will not solve the issue of getting the devices on the subnet to send their traffic to the ASA when they want to reach the subnet.  They will be sending traffic in the opposite direction to reach this subnet via the VPN tunnel as they do now.

The ASA may not have as much routing information as the router so you may need to configure static routes or dynamic routing on the ASA to make this work.


New Member

Re: PIX/ASA NAT and IPSEC tunnelling

Sorry, you still don't understand that there is no DEVICE at  The actual DEVICE is on the "outside" network and it's NATed to the inside network.

More explicitly, the "inside" and "outside" networks here refer to the security levels of the interfaces, but EVERY bit of traffic through the firewall in either direction is NATed.

This is done so that the two sides don't really know each other exists.  Each side has local addresses that represent physical devices on the other side.  In this case, the web server at is represented to the "inside" nets as  If you shut down the firewall, there would be nothing to respond to


Re: PIX/ASA NAT and IPSEC tunnelling

Sorry Tim, I see now that your diagram was meant to illustrate that .100 is a virtual device associated with the actual outside host.

I believe your design will work using the .100 address in your IPSEC interesting traffic ACL.  VPN only cares that you are using the source and destination addresses that correspond to your IPSEC interesting traffic ACL, whether or not they really exist.  The static NAT should then translate the decrypted traffic destined for .100 to the .36 outside address.  The reverse should happen for traffic returning from the .36 address.

If there are any real host devices on the subnet they should point to the ASA instead of the router as their default gateway in order to traverse the VPN tunnel, and I believe you would also need the same-security-traffic permit intra-interface command to allow LAN traffic and VPN traffic through the same interface.