- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2010 08:48 AM - edited 03-11-2019 11:55 AM
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
Solved! Go to Solution.
- Labels:
-
NGFW Firewalls
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2010 09:05 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2010 09:05 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2010 11:29 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2010 11:38 AM
Hey Phil,
Glad i could be of help. Will try creating a document with such scenarios
cheers,
Prapanch
