Publish a server with NAT hairpinned across a VPN tunnel with ASA

[johnk]

Hi All,

Thanks in advance for helping me out - I know someone has done this and I'm having difficulty finding how to do it.  I'm sure I'm missing something simple.

I have a customer who wants to view a DVR device across a VPN tunnel published through the public firewall at the colocation facility.  The DVR endpoint is a dynamically assigned ip endpoint that tunnels home on demand (I know the tunnel could drop).

So, I think/thought I could hairpin/policy nat this, but I'm not the best at this. 

Let's see if I can draw this

public ip  1.1.1.1\

                              >Outside Interface of ASA

Private ip 2.2.2.2/

My config as far as I know that is pertinant is as follows:

same-security-traffic permit intra-interface

access-list inbound extended permit ip any host 168.215.x.x

access-group inbound in interface outside

static (outside,outside) 168.215.x.x 10.10.x.xnetmask 255.255.255.255

I'm running version 8.2.5 of the ASA image.

If you could take a look and let me know what I'm missing please.

Thanks,

[Jouni Forss]

Hi,

In an L2L VPN setup this should be possible to do with some adjustment to the connection if it only servers the traffic between the 2 sites.

You say the remote site where the actual device resides is a Dynamic connection? You mean that there is a Hardware VPN Client device which automatically connects to the central site when it has Internet connectivity?

Just out of interest I just tested this setup on your software (have only tried it on 8.3 and newer before) and with a static L2L VPN setup it works like a charm.

So I would need some more information (perhaps configurations) to be able to say more.

- Jouni

[johnk]

So yes, the remote device is an ASA 5505 with a dynamic address tunneling home.

I'm using 8.2.5, and I'm wondering if the answer is as simple as an upgrade...

There are additional sites, if the software upgrade doesn't cure it, I'll post the configs.

It's an idea, I'll give it a try after hours tonight.

Thanks!

[Jouni Forss]

Hi,

I dont think the software level factors into the fact if this can work or not. I had both of my test ASAs at home (ASA5505 and 5520) on software 8.2. And in my previous test case the central ASA was running newer software with the new NAT format.

I am more interested in the fact that was this a Dynamic VPN connection between 2 ASAs or a static Site to Site VPN.

Although naturally your original post pointed towards the fact that it was a Dynamic VPN

To my understanding this type of VPN typically has the remote device with the Dynamic IP typically tunnel all the traffic from its LAN to the VPN no matter what the destination network of the traffic.

So on the basis of that it should also accept traffic entering the VPN tunnel from public IP addresses which come through the central site and then enter the VPN connection.

What you should try is that the VPN between these devices should be up and then you should test an example connection with the "packet-tracer" command on the central device

packet-tracer input outside tcp 1.2.3.4 12345 168.215.x.x

As I said confirm the the VPN is up and have the configurations you mention in your original post and THEN use the "packet-tracer" command and post the output here on the forums.

- Jouni

[johnk]

The tunnel is up and passing traffic no problems.  I can access the DVR device from a system at the colocation across the tunnel so that test it positive.

I do indeed have the configs metioned about and I ran the packet trace and came back with the following that looks to me like the packet is allowed, but I'm not used to looking at this in this fashion.

Thanks for your help.

trioasa# packet-tracer input outside tcp 1.2.3.4 12345 168.215.x.x http

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (outside,outside) 168.215.x.x 10.10.2.253 netmask 255.255.255.255
  match ip outside host 10.10.2.253 outside any
    static translation to 168.215.x.x

    translate_hits = 0, untranslate_hits = 1568
Additional Information:
NAT divert to egress interface outside
Untranslate 168.215.x.x/0 to 10.10.2.253/0 using netmask 255.255.255.255

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inbound in interface outside
access-list inbound extended permit ip any host 168.215.x.x

Additional Information:

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

Phase: 4
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (outside,outside) 168.215.x.x 10.10.2.253 netmask 255.255.255.255
  match ip outside host 10.10.2.253 outside any
    static translation to 168.215.x.x
    translate_hits = 0, untranslate_hits = 1568
Additional Information:

Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (outside,outside) 168.215.x.x 10.10.2.253 netmask 255.255.255.255
  match ip outside host 10.10.2.253 outside any
    static translation to 168.215.x.x
    translate_hits = 0, untranslate_hits = 1568
Additional Information:

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

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

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

trioasa#

[Jouni Forss]

Hi,

Everything seems fine on the that output

Things to look out for are

• There is an UN-NAT which means that the switches the public destination NAT IP to the Real IP
• There is an ACL phase which is passed
• We see a VPN Phase

There is some things we could check now still on the central site

Use the command

show conn | inc 10.10.2.253

During the connection attempt from the public network and post that output here regarding to the connection that is coming from your external test host

Alternatively use the ASDM or a Syslog server if you are sending log messages to a server and monitor a single test connection from the Internet towards this server and find and post the "Built TCP connection" and "Teardown TCP connection" messages for the connection attempt. The logs messages should also list the same ID number for the connection.

In this situation I however thing that the problem is probably on the remote site. Would it be possible to see its configurations?

- Jouni

[johnk]

Aha! Thank you for the help.  You made me realize the traffic for the local device behind the remote network is being returned to the public internet through the local gateway causing a disjointed connection.

I will have to get the remote config and post for you, I'm sure it's in my access-list.

I have to take a break from this project for a while (a day or so), but I know we are on the right path.

The access-list I have would look something like

access-list no-nat permit ip 10.10.2.0 255.255.255.0 192.168.1.0 255.255.255.0

access-list no-nat permit ip 10.10.2.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list forvpn permit ip 10.10.2.0 255.255.255.0 192.168.1.0 255.255.255.0

access-list forvpn permit ip 10.10.2.0 255.255.255.0 192.168.2.0 255.255.255.0

which would return the request for an internet connect locally - can I ask how to push this through the tunnel?

Thanks again.

John

[Jouni Forss · Accepted solution]

Hi,

The problem here is naturally the fact that we cant configure NAT0 without causing all the Internet traffic from the remote site to flow through the VPN connection.

So I wonder if a different kind of NAT configuration might do the trick actually.

I would call it Static Policy Identity NAT If such a name even exists.

Something like this

access-list DVR-POLICY-NAT remark Direct HTTP return traffic to VPN

access-list DVR-POLICY-NAT permit tcp host 10.10.2.253 eq 80 any

static (inside,outside) 10.10.2.53 access-list DVR-POLICY-NAT

What this should essentially do is

• When the DVR is sending any TCP traffic source from TCP/80 (essentially return traffic for the connection coming from main site) towards ANY destination address (The Internet) then the host should be translated to itself.
• When we consider that the NAT is done before VPN rules are processed this should mean that since we NATed the address to itself, it should match the VPN rule only in this special case where the traffic is source from TCP/80 which could only result from it replying to some TCP/80 destination connection)
• Which leads me to believe it shouldnt cause problems with the connection from central to remote site (NAT0 is processed before Static Policy NAT) or from the DVR to the Internet
• UNLESS the DVR needs to be accessed directly through the Internet connection of the remote site. (It would send its replys to those HTTP connections out with the original souce IP address) Or perhaps even fail the connection altogether before that phase. I havent tested.

Hope this helps

Remember to mark the question as answered if it did. And/or rate helpfull answers.

Ask more if needed.

EDIT: Typos

- Jouni

[johnk]

Hi Jouni,

I added the info below, but when I dropped the Static in - it gave me a protocol mismatch.

So I changed the command to be as follows but it doesn't work (and I probably need to deliver all protocols to the remote destination, not just http)

static (inside,outside) tcp 10.10.2.253 http access-list DVR-POLICY-NAT

The good news is the DVR is a piece of garbage so that has bought us a little time...

Thanks for letting me pick your brain.

John