ASA 5510 Issue with NAT and Internal Network Routing

[shumanick]

Hi, I am having a problem getting my ASA to work properly.  I attached a diagram for reference and most of the config is below.

When I finally got it to route properly between 2 subnets on the internal network, the NONAT statement broke routing for the VPN Clients who rely on a NAT statement for the same subnet that is listed in NONAT access list.  I can get one of the 2 to work by replacing NAT statements but can't figure out a combinaton to allow routing for both the internal subnets and the VPN clients to work.  If more details are needed, please let me know.  I'd really appreciate some help with this, it's been about 5 days of tweaking this thing just to get the internal routing to work correctly and when I finally did I broke VPN client access.  To note, the VPN clients can still log in and get a session going, they just can't get anywhere once they are in.  I also think there's alot of stuff in this config that is not needed like a lot of the object groups, etc. but I am being very careful about removing anything.  I took over support of this ASA after someone else put it in place and over this past weekend we moved it to a new building and new ISP and that is when I had to get it to route between subnets.  The main point of this move was to remove building 1's reliance on building 2 for Internet and outside email access in the event that building 2 is not available (it is close to water and this has happended more than once over the past year).  So that is why I can't go with the smartest option of just keeping the routes on the router in the other building.  I also know the 1600s are ancient but they're all we have for now.  I can provide those router configs also but they are VERY basic, all static routing. The IP for the Cisco router on the same subnet as the ASA is 192.168.42.254.

This is the statement that allows the routing to work between the 2 internal subnets but breaks VPN clients:

nat (INSIDE) 0 access-list NONAT

This is the statement that allows the VPN clients to work but breaks the internal routing:

nat (INSIDE) 0 access-list INSIDE_nat0_outbound

The rest of the config is below the diagram.

ASA Version 8.2(2)

!

hostname ciscoasa

domain-name default.domain.invalid

enable password - encrypted

passwd - encrypted

names

dns-guard

!

interface Ethernet0/0

nameif OUTSIDE

security-level 0

ip address X.X.X.X 255.255.255.248

!

interface Ethernet0/1

nameif INSIDE

security-level 100

ip address 192.168.42.1 255.255.255.0

!

interface Ethernet0/2

shutdown

no nameif

no security-level

no ip address

!

interface Ethernet0/3

shutdown

no nameif

no security-level

no ip address

!

interface Management0/0

nameif management

security-level 100

ip address 192.168.1.1 255.255.255.0

management-only

!

boot system disk0:/asa822-k8.bin

ftp mode passive

clock timezone EST -5

clock summer-time EDT recurring

dns server-group DefaultDNS

domain-name default.domain.invalid

same-security-traffic permit intra-interface

object-group network obj-192.168.42.0

object-group network obj-10.1.1.0

object-group network obj-192.168.42.42

object-group network obj-192.168.42.5

object-group network obj-192.168.42.40

object-group network obj-192.168.0.0

object-group network obj-192.168.43.0

object-group protocol DM_INLINE_PROTOCOL_2

protocol-object ip

protocol-object icmp

protocol-object udp

protocol-object tcp

access-list INSIDE_nat0_outbound extended permit ip 192.168.42.0 255.255.255.0 10.1.1.0 255.255.255.0

access-list X_splitTunnelAcl standard permit 192.168.42.0 255.255.255.0

access-list 101 extended permit tcp any host X.X.X.X eq smtp

access-list 101 extended permit tcp any host X.X.X.X eq https

access-list NetTech21_splitTunnelAcl standard permit 192.168.42.0 255.255.255.0

access-list NONAT extended permit ip 192.168.42.0 255.255.255.0 192.168.43.0 255.255.255.0

access-list NONAT extended permit ip 192.168.43.0 255.255.255.0 192.168.42.0 255.255.255.0

access-list INSIDE_access_in extended permit object-group DM_INLINE_PROTOCOL_2 192.168.42.0 255.255.255.0 any

access-list tcp_bypass extended permit tcp 192.168.43.0 255.255.255.0 192.168.42.0 255.255.255.0

access-list tcp_bypass extended permit tcp 192.168.42.0 255.255.255.0 192.168.43.0 255.255.255.0

pager lines 24

logging enable

logging monitor informational

logging asdm informational

mtu OUTSIDE 1500

mtu INSIDE 1500

mtu management 1500

ip local pool IPPool 10.1.1.1-10.1.1.254 mask 255.255.255.0

ip verify reverse-path interface OUTSIDE

icmp unreachable rate-limit 1 burst-size 1

asdm image disk0:/asdm-625.bin

no asdm history enable

arp timeout 14400

global (OUTSIDE) 1 X.X.X.X

nat (INSIDE) 0 access-list NONAT

nat (INSIDE) 1 192.168.0.0 255.255.0.0

static (INSIDE,OUTSIDE) X.X.X.X 192.168.42.5 netmask 255.255.255.255

static (INSIDE,OUTSIDE) X.X.X.X 192.168.42.42 netmask 255.255.255.255

access-group 101 in interface OUTSIDE

access-group INSIDE_access_in in interface INSIDE

route OUTSIDE 0.0.0.0 0.0.0.0 X.X.X.X 1

route INSIDE 192.168.43.0 255.255.255.0 192.168.42.254 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

dynamic-access-policy-record DfltAccessPolicy

http server enable

http 192.168.42.0 255.255.255.0 INSIDE

http 192.168.1.0 255.255.255.0 management

http 0.0.0.0 0.0.0.0 OUTSIDE

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

crypto dynamic-map OUTSIDE_dyn_map 20 set transform-set ESP-3DES-SHA

crypto map OUTSIDE_map 65535 ipsec-isakmp dynamic OUTSIDE_dyn_map

crypto map OUTSIDE_map interface OUTSIDE

crypto isakmp identity hostname

crypto isakmp enable OUTSIDE

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

ssh 192.168.0.0 255.255.0.0 INSIDE

ssh 0.0.0.0 0.0.0.0 OUTSIDE

ssh timeout 5

console timeout 0

dhcpd address 192.168.1.2-192.168.1.254 management

dhcpd enable management

!

threat-detection basic-threat

threat-detection scanning-threat

threat-detection statistics port

threat-detection statistics protocol

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

webvpn

group-policy StDvPn internal

group-policy StDvPn attributes

wins-server value 192.168.42.40

dns-server value 192.168.42.40

vpn-tunnel-protocol IPSec

default-domain value X

group-policy NetTech21 internal

group-policy NetTech21 attributes

wins-server value 192.168.42.40

dns-server value 192.168.42.40

vpn-tunnel-protocol IPSec

split-tunnel-policy tunnelspecified

split-tunnel-network-list value NetTech21_splitTunnelAcl

default-domain value X

group-policy X internal

group-policy X attributes

dns-server value 192.168.42.40

vpn-tunnel-protocol IPSec

split-tunnel-policy tunnelspecified

split-tunnel-network-list value X_splitTunnelAcl

default-domain value X

*** A bunch of user name and tunnel group statements here

!

class-map inspection_default

match default-inspection-traffic

class-map tcp_bypass

match access-list tcp_bypass

!

!

policy-map global_policy

class inspection_default

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect rsh

  inspect rtsp

  inspect sqlnet

  inspect skinny 

  inspect sunrpc

  inspect xdmcp

  inspect sip 

  inspect netbios

  inspect tftp

  inspect ip-options

policy-map tcp_bypass_policy

class tcp_bypass

  set connection advanced-options tcp-state-bypass

!

service-policy global_policy global

service-policy tcp_bypass_policy interface INSIDE

prompt hostname context

call-home

profile CiscoTAC-1

  no active

  destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService

  destination address email callhome@cisco.com

  destination transport-method http

  subscribe-to-alert-group diagnostic

  subscribe-to-alert-group environment

  subscribe-to-alert-group inventory periodic monthly

  subscribe-to-alert-group configuration periodic monthly

  subscribe-to-alert-group telemetry periodic daily

Cryptochecksum:-

: end

[Jouni Forss]

Hi,

Its totally possible that I might have missed something but couldnt you just add the VPN Client NAT0 ACL statement to the ACL used in the above configuration for traffic between 2 LANs?

access-list NONAT permit ip 192.168.42.0 255.255.255.0 10.1.1.0 255.255.255.0

Probably better to get some coffee and look this through once more incase I missed something

- Jouni

[shumanick]

I just gave that a shot and the VPN clients still can't get anywhere.  Were there statements you were recommending I remove in addtion to adding that one?

[Jouni Forss · Accepted solution]

Hi,

Have you monitored the ASA logs through ASDM while connected with a VPN Client and attempting to connect to some host on the 192.168.42.0/24 network?

Are you testing with some TCP connection or just ICMP?

- Jouni

[shumanick]

Now I am having some mixes results after re-connecting so that definetely did something.  I need to go somewhere with better reception for my air card to test this out because it's terrible wher eI am now.  I will get back to you with the results soon.  Thank you for your help!

[shumanick]

Jouni,

I think that did the trick, on my laptop running through my iPhone everything works just about as good as I think it could over that connection but I never really use it.  Another user who has been testing over his sprint air card says that it seems much slower to him now but I am not sure how much he actually uses this card for access.  I can say that it was pretty painful on his device but don't know for sure that isn't how it always worked.  The additional access list statement definitely fixed the routing issue. I am just wondering if the ASA is now doing way more processing or the routing is not ideal.  I will know for sure later when I can test from a good wifi network.  It doesn't much sense that it would be slower because we moved it to a MUCH faster internet connection and all of our outbound Internet access has been remarkably faster since then.

So if you want to mark this as answered that is no problem with me.  If I seem to have a performance issue now I could try to get some help on that separately.  Thanks again for your help.

-Steve

[Jouni Forss]

Hi,

Actually I cant mark the question as answered. You can mark my replys as correct answer with the "button" that shows at the bottom of the reply.

I imagine it will be harder to determine the the cause of slowness in connection rather than determining a cause when something doesnt work at all.

Naturally the routing setup isnt ideal at the moment as you have stated yourself.

If the hosts on 192.168.42.0/24 are using ASA as their default gateway then you have asymmetric routing between the 2 LANs for example.

Connections from 192.168.42.0/24 to 192.168.43.0/24 would at the moment go like this

• Host 192.168.42.100 attempts to connect 192.168.43.100
• Host 192.168.42.100 sends traffic to its default gateway
• ASA sends it back to the internal router
  • This is achieved with "same-security-traffic permit intra-interface"  and NAT0 configuration
• Connection attempt reaches the host 192.168.43.100
• Host 192.168.43.100 sends reply to host 192.168.42.100
• The reply will get forwarded from the router directly to the host and therefore leaving the ASA totally out of the picture with regards to this reply. Therefore the ASA would normally just teardown the connection and any TCP connection would fail. But the TCP State Bypass is allowing the traffic.

Naturally this shouldnt relate to the VPN Clients connections

Maybe one approach would be to both monitor the logs while testing and also taking traffic capture to determine how TCP connections are working. Traffic capture can be done directly on the ASA if needed.

- Jouni

Message was edited by: Jouni Forss Edited the above description a bit since it was partly missleading

[shumanick]

Thanks for the detail on that, I spent a lot of time figuring that out and then finally finding the actual problem and resolution after reading Cisco Document ID: 111986.  I was concerned about the routing between those 2 subnets also but that is actually working well with no complaints on noticable performance hit at least from a user perspective.  The only thing that "seems" like it MIGHT be slower is client VPN access once you have a seesion enabled.  I will be able to have a good handle on that later this evening but from what I've seen so far I'm not convinced this is the case.