cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5553
Views
0
Helpful
3
Replies

Hairpin routing ASA5505

Phil Williamson
Level 1
Level 1

I need to configure hairpin routing on the inside interface.

The ASA is the default gateway for hosts on its 10.1.1.0 inside segment.

There are nets behind a 3rd party router 10.1.1.254.

The 3rd party will not allow its router to be the default gateway.

I have this config in place.

I can create a TCP connection (RDP) and get ping replies from a host on 10.1.1.0 to a host on 10.2.2.0.

Connections from 10.2.2.0 to 10.1.1.0 fail.

What am I missing from the config that prevents the connections from 10.2.2.0 to 10.1.1.0?

Will this work on a non-security plus box??

Would this work on v8.0(4) OS?

ASA Version 8.2(2)
This platform has an ASA 5505 Security Plus license.
!
show run all sysopt
no sysopt connection timewait
sysopt connection tcpmss 1380
sysopt connection tcpmss minimum 0
sysopt connection permit-vpn
sysopt connection reclassify-vpn
no sysopt connection preserve-vpn-flows
no sysopt nodnsalias inbound
no sysopt nodnsalias outbound
no sysopt radius ignore-secret
no sysopt noproxyarp inside
no sysopt noproxyarp outside
!
show run all failover
no failover
failover lan unit secondary
failover polltime unit 1 holdtime 15
failover polltime interface 5 holdtime 25
failover interface-policy 1
failover timeout -1
!
!
interface Vlan1
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/1
!
same-security-traffic permit intra-interface
!
access-list TCP-BYPASS extended permit ip 10.2.2.0 255.255.255.0 10.1.1.0 255.255.255.0
access-list TCP-BYPASS extended permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0
!
ip verify reverse-path interface inside
ip verify reverse-path interface outside
no failover
failover timeout -1
!
nat-control
global (inside) 1 interface

nat (inside) 1 10.1.1.0 255.255.255.0
route inside 10.2.2.0 255.255.255.0 10.1.1.254 1

!
class-map TCP-BYPASS
match access-list TCP-BYPASS
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
  message-length maximum 512
policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect pptp
  inspect ip-options
policy-map TCP-BYPASS
class TCP-BYPASS
  set connection advanced-options tcp-state-bypass
!
service-policy global_policy global
service-policy TCP-BYPASS interface inside
!

Thx

Phil

1 Accepted Solution

Accepted Solutions

praprama
Cisco Employee
Cisco Employee

Hi,

The problem seems to be with the NAT configuration that we have.

global (inside) 1  interface

nat  (inside) 1 10.1.1.0 255.255.255.0

So, when you initiate a connection from the 10.1.1.0/24 subnet to the 10.2.2.0/24 subnet, the packet is going to be PATed to the inside interface IP address of 10.1.1.1. Hence, when the reply packet comes, it is going to be destined to this IP (10.1.1.1) and hence the connection will work fine.

When you initiate the connection from the 10.2.2.0/24 subnet to the 10.1.1.0/24 subnet (say RDP from 10.2.2.10 to 10.1.1.10), the initial packet (SYN) will be sent directly to the 10.1.1.0 host by the 3rd party router. But when the reply is sent by that host (SYN/ACK), it is going be destined to the ASA since it is the default gateway for the host. So, now this packet is going to be PATed by the ASA to it's inside interface IP address of 10.1.1.1.

So when this reply SYN/ACK reaches the 10.2.2.10 host, it is going to have a source IP of 10.1.1.1 though it sent initial packet to 10.1.1.10!!!!!!!

This is where the problem arises. To workaround this, i would suggest removing the "global (inside) 1 interface" and adding the static as below:

static (inside,inside) 10.2.2.0 10.2.2.0 netmask 255.255.255.0

static (inside,inside) 10.1.1.0 10.1.1.0 netmask 255.255.255.0

sysopt noproxyarp inside

Now, if we add this, we also need to disable TCP sequence number randomization using the below command:

policy-map TCP-BYPASS
class TCP-BYPASS
  set connection advanced-options tcp-state-bypass

    set connection random-sequence-number disable

Let me know if this helps!!

Thanks and Regards,
Prapanch

View solution in original post

3 Replies 3

praprama
Cisco Employee
Cisco Employee

Hi,

The problem seems to be with the NAT configuration that we have.

global (inside) 1  interface

nat  (inside) 1 10.1.1.0 255.255.255.0

So, when you initiate a connection from the 10.1.1.0/24 subnet to the 10.2.2.0/24 subnet, the packet is going to be PATed to the inside interface IP address of 10.1.1.1. Hence, when the reply packet comes, it is going to be destined to this IP (10.1.1.1) and hence the connection will work fine.

When you initiate the connection from the 10.2.2.0/24 subnet to the 10.1.1.0/24 subnet (say RDP from 10.2.2.10 to 10.1.1.10), the initial packet (SYN) will be sent directly to the 10.1.1.0 host by the 3rd party router. But when the reply is sent by that host (SYN/ACK), it is going be destined to the ASA since it is the default gateway for the host. So, now this packet is going to be PATed by the ASA to it's inside interface IP address of 10.1.1.1.

So when this reply SYN/ACK reaches the 10.2.2.10 host, it is going to have a source IP of 10.1.1.1 though it sent initial packet to 10.1.1.10!!!!!!!

This is where the problem arises. To workaround this, i would suggest removing the "global (inside) 1 interface" and adding the static as below:

static (inside,inside) 10.2.2.0 10.2.2.0 netmask 255.255.255.0

static (inside,inside) 10.1.1.0 10.1.1.0 netmask 255.255.255.0

sysopt noproxyarp inside

Now, if we add this, we also need to disable TCP sequence number randomization using the below command:

policy-map TCP-BYPASS
class TCP-BYPASS
  set connection advanced-options tcp-state-bypass

    set connection random-sequence-number disable

Let me know if this helps!!

Thanks and Regards,
Prapanch

Prapanch - Yes, that did the trick - now its bi-directional.  I also verified that the 'failover timeout -1' cmd is not relevant.

Should this not be a tech-tip on CCO?  I've seen many queries about it, but yours is the most definitive response I've seen.

A big thanks for your help.  It will make my customers happy  too.

Phil

Hey Phil,

Glad i could be of help. Will try creating a document with such scenarios

cheers,

Prapanch

Review Cisco Networking products for a $25 gift card