ASA as default gw causing apps to fail

[tato386]

I have two gateways at my office.  1.1.1.1 is an ASA that is the default gw assigned to all clients and is the device used for Internet access and to NAT external public IPs to internal public servers.  I have a second device 1.1.1.2 used for IPSec VPN to a handful of remote/home offices.  The ASA has a static route to 1.1.1.2 for these remote subnets.  Proxy ARP on internal private interface of ASA is disabled.

My problem is that users on the remote networks have trouble accessing applications on clients on the 1.1.1.0/24 network.  They can ping and traceroute OK to them but when they try to use RDP or file sharing they get erratic results.  Sometimes they can connect but most of the time the apps fail.

If I manually configure the internal clients to use 1.1.1.2 as their gateway all trouble clears up and remote users report no problems.  Obviously this is not a solution because the internal guys lose Internet access.

The ASA is a 5505 model running 8.4(4)1.

Any ideas?

Thanks,
Diego

[jocamare]

Why is proxy-arp disabled on the inside?

Does it make any difference if you enable it?

[dcambron]

You have these option.

change DG to 1.1.1.2 and add a default route to 1.1.1.1 in your 1.1.1.2 device.

or In your ASA nat trafic from remote networks when going to 1.1.1.0/24 and nat trafic from 1.1.1.0/ when going to remote networks.  These is called u-turn you should permit traffic from same-sec int.

Your last option that could work is disable TCP state check at the ASA or disable the stateful check at the ASA.

saludos

[Gabriel Hill]

How many clients do you have behind your 5505? Can you post a show version, due to the volatile nature of your situation (sometimes it works, and sometimes it doesn't) it could be related to a license limitation with "inside hosts". Should be able to better tell once you provide this information.

[tato386]

When I first installed the ASA I had all sorts of problems until I turned off the proxy arp on the inside interface. Except for this VPN/routing issue its been working well so I left it like that.  I can test enabling it during off hours I guess.

I have a Security Plus license with unlimited inside hosts among other feautres.

dcambron: I already have permit traffic from same security interface enabled.  Are you sure I have to use NAT for this to work???  Seems like a lot of trouble and the traffic is not crossing the ASA, just bouncing off it and sent to another device.

Thanks,

Diego

[jocamare]

The issue is Assymetric routing.

You can try to configure u-turn on the 1.1.1.1 ASA so it will send the traffic to the 1.1.1.2 when the destionation is one of the addresses on the other side of the tunnel.

As dcambron mentioned, we have to configure u-turn on the unit.

[tato386]

Not clear what "u-turn" is.  Could there be another name for that technique?  Wouldn't the static route on the ASA cause it to send the traffic to 1.1.1.2? 

Thanks,

Diego

[dcambron]

Hairpinning

[jocamare · Accepted solution]

Basically the issue is that the traffic is coming from 1.1.1.2, the return traffic sent to 1.1.1.1, which will then forward it to 1.1.1.2.

This setup is definitely not the best, and will need some configuration on the 1.1.1.1 ASA to get it working.

U-turn aka Hairpinning will let the return traffic reach the 1.1.1.1 ASA and then forward that traffic to 1.1.1.2. Basically, the traffic enters and leaves the internal interface of the 1.1.1.1 unit.

It will be necessary to configure TCP state-bypass on the 1.1.1.1 unit so we won't check the flags on the packet and avoid drops due to Asymmetric routing.

U-turn/Hairpinning

http://packetpushers.net/cisco-asa-8-38-4-hairpinning-nat-configuration/

TCP state-bypass

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080b2d922.shtml

[jocamare]

Config should look like this:

Remote netwoks [example]

10.10.10.0

10.10.11.0

10.10.12.0

1.1.1.1 ASA

same-security permit intra-interface

object group Hairpinning

sub 1.1.1.0 255.255.255.0

nat (inside,inside) dynamic interrface

Object-group network Remote-nets

network-object 10.10.10.0 255.255.255.0

network-object 10.10.11.0 255.255.255.0

network-object 10.10.12.0 255.255.255.0

nat (inside,inside) source static Remote-nets Remote-nets

                    TCP-state Bypass [still on the 1.1.1.1 ASA]

Access-list TCP-BYPASS permit ip any object-group Remote-nets

class-map TCP-BYPASS

match access-list TCP-BYPASS

Policy-map global_policy

class TCP-BYPASS

set connection advanced-options tcp-state-bypass

[dcambron]

here is the solution

[dcambron · Accepted solution]

Problem is that TCP is stateful and the first packet (SYN) is beeing sent to the ASA. however the returning trafic (SYN Ack) is not, this packet is beeing sent to the clients directly (since the vpn device knows them). So from the ASA perspective only 1 packet from the 3way handshake TCP proccess was received. That is the reason why the TCP conexions are not working. ICMP is not stateful so it doesn't matter if the ASA doesn't see the ICMP Reply.

To solve the issue you should understand what is happening first.

So if you enable nat as I told you the returning traffic will be sent to the ASA (because only the ASA knows the nated network and the vpn device has a route to sent the traffic to the ASA) then the ASA will unNat and sent the traffic to the client at 1.1.1.0/24  and there you go the ASA is not terminating the tcp conections since it is seeing the whole transaction now.

try this

object group U-TURN

net 1.1.1.0

sub 1.1.1.0 255.255.255.0

nat (inside,inside) dynamic U-TURN interface

same-security permit intra-interface

I think that will allow trafic from 1.1.1.0 to remote networks but if you generate traffic from the remote networks I think you have to nat both networks

there are some other option check this if that not works

https://supportforums.cisco.com/docs/DOC-17810

[tato386]

Thanks to dcambron and jocamare for the TCP bypass examples which fixed my problem.  I did not have to do any NAT stuff since my existing NAT statements use very specific interfaces and ACLs.

Thanks,

Diego