Outside traffic to either inside host or host on existing site-to-site IPsec VPN

[petes]

I have an ASA 5510 that is setup in the following manner.

Internet ----->  "outside" ASA interface ----> [ASA] -->  "private" ASA Interface -- 192.168.1.1/24 network --> Router --> 10.0.0.0 network

I have a web server that sits on the 10.0.0.0/24 network.  HTTP traffic hits the public IP address 1.1.1.1 and which gets translated to the 10.0.0.1 IP address of the web server.  After the NAT takes place, there is a route to the 10.0.0.0/24 network pointing to the private interface and the traffic is routed to the web server.

This works fine and is how our normal behavior occurs.  I also have a site-to-site VPN established between the outside interface of the ASA and another private network that also has routes to the 10.0.0.0/24 network via other routing devices.  This is setup as redundancy in case anything happens to the router between the 192.168.1.1/24 and 10.0.0.0/24 networks.

If that router was to go down, the ASA will receive a new route to the 10.0.0.0/24 network that points traffic to the VPN connection.  This works fine for communication between the 192.168.1.1/24 and 10.0.0.0/24 networks.

My problem is that web traffic originated from the Internet will not go across the VPN to take the new path to the web server.  I want the traffic to arrive at the outside interface of the firewall, have the destination address translated to 10.0.0.1, see that the route to this network is over the VPN and sent across the VPN.

Has anyone setup something like this before?  Most of the examples I see are related to clients connecting to the VPN and then hairpinning back out the outside interface for internet traffic.

When I view the logs on the ASA I see that the traffic is NAT'd to the 10.0.0.1 IP but then it says that no route can be found.  I think this has to do with the fact that the static NAT rule goes from OUTSIDE to PRIVATE but the route on the ASA shows the destination accessible via the Outside interface.

Hopefully I've explained my predicament well enough for you to understand exactly what I'm trying.  I've not had any luck finding the correct search phrase to find others with this same problem on google

I would greatly appreciate any insights or assistance.

[Yudong Wu]

I think you have the following static NAT command for your web server

static (private,outside) 1.1.1.1 10.0.0.1

I tested it on ASA, when the traffic to 1.1.1.1 makes a U-turn on outside interface, the above STATIC entry is applied twice. So, the destination IP was translated from 1.1.1.1 to 10.0.0.1 when the traffic reach outside interface. Then since route points 10.0.0.1 to outside interface, the packet will make U-turn here (you need enable "same-security-traffic permit intra-interface"), the above static NAT is applied again and IP is translated back to 1.1.1.1.

Here is the output.

ciscoasa# sh run static
static (inside,outside) 1.1.1.1 10.0.0.1 netmask 255.255.255.255
ciscoasa#
ciscoasa#
ciscoasa# sh run route
route outside 0.0.0.0 0.0.0.0 172.16.182.65 1
route outside 10.0.0.1 255.255.255.255 172.16.182.88 1
ciscoasa#
ciscoasa# packet-tracer input outside tcp 172.16.182.88 2222 1$

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (inside,outside) 1.1.1.1 10.0.0.1 netmask 255.255.255.255
  match ip inside host 10.0.0.1 outside any
    static translation to 1.1.1.1
    translate_hits = 0, untranslate_hits = 2
Additional Information:
NAT divert to egress interface inside
Untranslate 1.1.1.1/0 to 10.0.0.1/0 using netmask 255.255.255.255

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside in interface outside
access-list outside extended permit ip any any
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:     
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (inside,outside) 1.1.1.1 10.0.0.1 netmask 255.255.255.255
  match ip inside host 10.0.0.1 outside any
    static translation to 1.1.1.1
    translate_hits = 0, untranslate_hits = 2
Additional Information:

Phase: 5
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) 1.1.1.1 10.0.0.1 netmask 255.255.255.255
  match ip inside host 10.0.0.1 outside any
    static translation to 1.1.1.1
    translate_hits = 0, untranslate_hits = 2
Additional Information:

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 41, packet dispatched to next module

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow

ciscoasa#

I could not see any way not to let Static NAT be applied again on the U-turn traffic.

So, you can try the workaround by including the traffic from any to 1.1.1.1 in VPN tunnel and then translate 1.1.1.1 to 10.0.0.1 at the other end of the vpn tunnel.

[Shrikant Sundaresh]

Hi,

The static NAT is not actually applied again to the traffic.

What you see in the packet tracer is it checking host-limits and rpf. There will be no sub-type mentioned if the NAT is applied, and also there will be an increment on the translate_hits.

The way to get this working, I think, would be to append the crypto ACLs with permit ip any host 10.0.0.1 on this ASA, and the reverse on the other.

That way the traffic would match the crypto map after being un-natted.

Hope this helps.

-Shrikant

P.S.: Please mark the question resolved if it has been aswered. Do rate helpful posts. Thanks

[Shrikant Sundaresh]

Hi,

In addition to what i mentioned above, we would also need to change the static nat.

The current static nat would be: static (inside,outside) 1.1.1.1 10.0.0.1

On router failure, this should be replaced by: static (outside,outside) 1.1.1.1 10.0.0.1

Sadly, I don't think this can be automated.

Note: Both statics can be added together, however, the first one in the output of "show nat" will always be hit first.

-Shrikant

P.S.: Please mark the question resolved if it has been aswered. Do rate helpful posts. Thanks

[Yudong Wu]

Shrikant is correct. I mis-read the packet-tracer output.

[petes]

I hear what you're saying about not being able to automate the different static NAT statements.  What's strange is that even if I alter the static NAT to (outside,outside) it still doesn't work.  If I leave it (private,outside) then I get some error about the inability to locate a route.  This is because the route is pointing to the outside interface.

I was hoping that it would NAT the traffic to the private IP address and then consult it's routing table and see the path is actually accross the VPN.  I guess that would have been too easy.  Instead, because it's NAT'ing to a Private IP address it wants to send out that interface at all costs.

It seems strange that this firewall doesn't provide the ability that I'm trying to obtain.  Am I the only person that has configured a VPN to provide an alternate path to a web server?  I guess I'm going to have to install another ASA on the same segments and run the site-to-site VPN through this appliance.  It will participate in OSPF advertisements and when the traffic comes in the primary ASA, it will always have a route via the Private interface.  That would will either be to my router or to my new ASA that is providing the VPN connection.

What are your thoughts???

Thanks again guys,

Pete

[Shrikant Sundaresh]

Hi Pete,

I managed to get your scenario working in the lab.

The static un-nat always forces traffic out of the other interface configured within parenthesis.

Please confirm that you removed the original static (private, outside) before adding the static (outside,outside).

Also run the packet-tracer after adding static (outside,outside)

packet-tracer input outside tcp 4.2.2.2 8888 detail

and attach the output. If we see a phase called VPN, means the traffic was categorized to go over the VPN.

Did you also modify the crypto maps, as i had mentioned in the previous post?

-Shrikant

[petes]

Yes, I'll double check the crypto map ACL.  This may be a stupid question but when I run the packet capture and have to specify the

source port, how can I control that being that it is dynamically generated when I hit refresh on the browser?  Does the 8888 signify

any port?

[Shrikant Sundaresh]

Nah. I chose 8888 randomly

You can use any port above 1024..

-Shrikant

[petes]

Can you specify a range of ports?  How can I pick the correct port if I don't know what value my lab machine is going to choose for the source port?

[Shrikant Sundaresh]

You can choose any port from 1024-65535. A test packet is generated and its flow moniotred across the ASA.

It doesn't matter which port the test PC uses when you test from it.

When you run the packet-tracer command, it creates a packet with those specifications and assumes it came on the interface mentioned after input in the packet-tracer. Then it traces how the packet moves across various phases in the ASA.

Hope this clarifies how the packet-tracer works.

-Shrikant

[petes]

Wow, I am super excited about that packet-tracer command.  That's going to make my life a lot easier, thanks!  I thought you had to tell it what to look for and then generate the packets yourself.  I can see that it tries to get to the VPN but I've got an outbound NAT rule that is dropping the connection.

So, it's good to know that this problem can be solved with hairpinning.  Anybody have any ideas on how I could allow normal traffic to flow from the outside to the inside and eventually to the web server while all links are up and then have that traffic dynamically start using the VPN as an alternate path when there is a disruption that blocks the traditional path to the server?

Thanks again for your assistance!

[Shrikant Sundaresh]

Hi Pete,

For traffic to return from inside, you would need to have a device which does routing on the inside.

This router, should have the failover routes too, and send device back to the ASA.

The ASA can then send the traffic over the vpn. However, you would need to disable reverse path check, since outside ip addresses would be seen to appear from the inside, and ASA would drop them thinking those packets are spoofed.

-Shrikant

P.S.: Please mark the question resolved, if it has been answered. Do rate helpful posts. Thanks.