cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1839
Views
0
Helpful
4
Replies

ACL - configuration help

willy moronta
Level 1
Level 1

Hello I've a newly configured 5510 would appreciate a look over of the configuration and some questions I have:  Its a long post and I appreciate anyone taking time to read through it.

My goals are the following:

     to make the inside network 10.20.145.0 to allow internet access - as long as the connection starts inside

     To allow neighbor network that comes in through outside interface origin 170.20.0.0/16 access to the 10.20.145.0 (bidirectional)

     The tunnel from neighbor lan to inside lan happens through vpn concentrator that has external ip address and 77.76.19.35

     Allow certain devices on the DMZ to access the internet and allow outside to inside connections on certain ports

Much of the settings I have configured are coming from juniper that is currently online but needs to be replaced.

The network is set up as below for a chart of traffic:

ISP ---- Internet router ---- switch (3 active connections) 1. firewall  2. internet router   3. vpn concentrator

There is an internal 3750 that I have configured with ip 10.20.145.15 since it comes up often

I'm using pub IPs on the machines on the DMZ though I'm thinking of changing that to an internal vlan and than nating it out.  Well here's what I have so far:

=================================================================================================

ASA Version 8.3(2)

!

hostname ASA

domain-name a.domain.com

enable password l4Tu/tqHeN0MdD7t encrypted

passwd dL9fmCBkHiwx4Iib encrypted

names

!

interface Management0/0

nameif management

security-level 100

ip address 192.168.1.1 255.255.255.0

management-only

!

interface GigabitEthernet1/0

description outside-interface-connected-to-internet-switch

speed 1000

duplex full

shutdown

nameif outside

security-level 0

ip address 76.77.19.34 255.255.255.240

!

!

interface GigabitEthernet1/1

description inside-int-10.20.145-network

speed 1000

duplex full

shutdown

nameif inside

security-level 100

ip address 10.20.145.3 255.255.255.192

!

interface GigabitEthernet1/2

shutdown

nameif DMZ

security-level 50

ip address 76.77.19.49 255.255.255.240

!

interface GigabitEthernet1/3

shutdown

no nameif

no security-level

no ip address

!

boot system disk0:/asa832-k8.bin

ftp mode passive

clock timezone EST -5

lock summer-time EDT recurring

dns domain-lookup outside

dns server-group DefaultDNS

name-server 76.77.6.11

name-server 66.72.76.84

name-server 4.2.2.1

name-server 8.8.8.8

domain-name a.domain.com

object network Inside_lan

subnet 10.20.145.0 255.255.255.0

object network NET-neighbor

subnet 170.20.0.0 255.255.0.0

description neighbor_LAN 

object network 76.77.19.44_cake

host 76.77.19.44

description cake 

object network 76.77.19.59

host 76.77.19.59

description streaming 

object network 76.77.19.61

host 76.77.19.61

description streaming 

object network cindy

host 50.56.249.224

description cindy 

object-group network internal-LAN

network-object object Inside_lan

object-group service 3306 tcp

description 3306

port-object eq 3306

object-group service 4567 tcp

description 4567

port-object eq 4567

object-group icmp-type ICM

description ICM_basic

icmp-object echo

icmp-object echo-reply

icmp-object time-exceeded

icmp-object traceroute

icmp-object unreachable

object-group service Retriever_SVC tcp

description Retriever

port-object range 8000 8001

object-group service Production tcp

description PM

port-object range www www

object-group service RDP tcp

description RDP

port-object eq 3389

object-group service Streaming tcp

description streaming server

port-object eq 7009

object-group service UDP123 udp

description 123

port-object eq ntp

object-group service affordable tcp

description affordable legacy

port-object eq 85

object-group service market tcp

description ports for market  dmz

port-object eq 2189

port-object eq 2190

port-object eq 2192

port-object eq 2194

object-group service messenger tcp

description air messenger

port-object eq 444

object-group service traffic-701 tcp

description 701

port-object eq 701

object-group service ntp1 udp

description ntp-udp-1

group-object UDP123

object-group service payroll tcp

description payroll port

port-object eq 714

object-group service snmp-udp udp

description snmp udp 1

port-object eq snmp

object-group service vitrol tcp

description vitrol custom

port-object eq 5986

object-group service webconferrence tcp

description webconference legacy port

port-object eq 1417

port-object eq 407

object-group service webmail tcp

description webmail ports

port-object eq 2095

object-group service INLINE_TCP_1 tcp

port-object eq ftp

port-object eq ftp-data

object-group service INLINE_SERVICE_1

service-object tcp

service-object icmp echo-reply

service-object icmp traceroute

service-object icmp unreachable

service-object tcp destination eq ftp

service-object tcp destination eq ftp-data

service-object tcp destination eq www

service-object tcp destination eq https

service-object udp destination eq echo

service-object udp destination eq ntp

service-object udp destination eq radius

service-object udp destination eq radius-acct

service-object udp destination eq syslog

object-group network INLINE_NETWORK_1

network-object host 76.57.19.53

network-object host 255.255.255.255

object-group service INLINE_TCP_2 tcp

group-object Streaming

group-object vitrol

object-group service INLINE_SERVICE_2

service-object ip

service-object tcp

service-object tcp destination eq ftp

service-object tcp destination eq ftp-data

service-object tcp destination eq www

service-object tcp destination eq https

service-object tcp destination eq ssh

access-list internet extended permit ip object Inside_lan interface outside

access-list internet extended permit object-group DM_INLINE_SERVICE_1 object Inside_lan any

access-list syndicaster extended permit tcp object Cindy object Inside_lan object-group INLINE_TCP_1

access-list streaming extended permit tcp interface DMZ any object-group Streaming

access-list streaming59 extended permit tcp object 76.77.19.59 interface outside object-group Streaming

access-list streaming_outside_in extended permit tcp interface outside object-group INLINE_NETWORK_1 object-group DM_INLINE_TCP_2

access-list neighbor extended permit object-group INLINE_SERVICE_2 object NET-neighbor object Inside_lan

pager lines 24

logging enable

logging asdm informational

mtu management 1500

mtu outside 1500

mtu inside 1500

mtu DMZ 1500

no failover

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat (inside,outside) source dynamic any interface

!

object network Inside_lan

nat (any,outside) dynamic interface

access-group neighbor in interface outside

access-group neighbor out interface inside

route outside 0.0.0.0 0.0.0.0 76.77.19.33 1

route inside 10.0.0.0 255.255.255.0 10.20.145.4 1

route inside 10.0.1.0 255.255.255.0 10.20.145.2 1

route inside 10.20.145.0 255.255.255.0 10.20.145.15 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.1.0 255.255.255.0 management

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

telnet 10.20.145.39 255.255.255.255 inside

telnet timeout 5

ssh 10.20.145.39 255.255.255.255 inside

ssh timeout 5

console timeout 0

dhcpd dns 76.77.6.11 64.22.16.84

dhcpd domain a domain

dhcpd option 6 ip 4.2.2.1

!

dhcpd address 192.168.1.2-192.168.1.254 management

dhcpd enable management

!

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

webvpn

username joe password m6OO.pH/13qc7ypS encrypted privilege 15

username bob password N./x1Ut.gM.QGZLa encrypted privilege 15

username bill password uZjIWeHtovCOweHJ encrypted

!

class-map inspection_default

match default-inspection-traffic

!

!

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum client auto

  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 ip-options

  inspect icmp

  inspect icmp error

!

service-policy global_policy global

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:06eb82d8d8a3ae82352512cd707e7f4a

========================================================================================================================================================

access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)

            alert-interval 300

access-list internet; 14 elements; name hash: 0xb30cf7fe

access-list internet line 1 extended permit ip object Inside_lan interface outside 0xe073f975

  access-list internet line 1 extended permit ip 10.20.1450 255.255.255.0 interface outside (hitcnt=0) 0xe073f975

access-list internet line 2 extended permit object-group INLINE_SERVICE_1 object Inside_lan any 0x2e33ca08

  access-list internet line 2 extended permit tcp 10.20.145.0 255.255.255.0 any (hitcnt=0) 0xa576d14f

  access-list internet line 2 extended permit icmp 10.20.145.0 255.255.255.0 any echo-reply (hitcnt=0) 0x15cccd5c

  access-list internet line 2 extended permit icmp 10.20.145.0 255.255.255.0 any traceroute (hitcnt=0) 0x8aab2f53

  access-list internet line 2 extended permit icmp 10.20.145.0 255.255.255.0 any unreachable (hitcnt=0) 0xe02606e1

  access-list internet line 2 extended permit tcp 10.20.145.0 255.255.255.0 any eq ftp (hitcnt=0) 0x6d0043b6

  access-list internet line 2 extended permit tcp 10.20.145.0 255.255.255.0 any eq ftp-data (hitcnt=0) 0xce904411

  access-list internet line 2 extended permit tcp 10.20.145.0 255.255.255.0 any eq www (hitcnt=0) 0x1ddebc69

  access-list internet line 2 extended permit tcp 10.20.145.0 255.255.255.0 any eq https (hitcnt=0) 0x1a3b15bc

  access-list internet line 2 extended permit udp 10.20.145.0 255.255.255.0 any eq echo (hitcnt=0) 0xadc66030

  access-list internet line 2 extended permit udp 10.20.145.0 255.255.255.0 any eq ntp (hitcnt=0) 0xa67a4406

  access-list internet line 2 extended permit udp 10.20.145.0 255.255.255.0 any eq radius (hitcnt=0) 0x230419e6

  access-list internet line 2 extended permit udp 10.20.145.0 255.255.255.0 any eq radius-acct (hitcnt=0) 0xa8ae0824

  access-list internet line 2 extended permit udp 10.20.145.0 255.255.255.0 any eq syslog (hitcnt=0) 0x051c7ef5

access-list cindy; 2 elements; name hash: 0x807c55e5

access-list cindy line 1 extended permit tcp object cindy object Inside_lan object-group DM_INLINE_TCP_1 0xe35e702c

  access-list cindy line 1 extended permit tcp host 50.56.249.224 10.20.145.0 255.255.255.0 eq ftp (hitcnt=0) 0x64b321cc

  access-list cindy line 1 extended permit tcp host 50.56.249.224 10.20.145.0 255.255.255.0 eq ftp-data (hitcnt=0) 0x55109118

access-list streaming; 1 elements; name hash: 0xfd34cf16

access-list streaming line 1 extended permit tcp interface DMZ any object-group Streaming_custom 0x8b2e87d1

access-list streaming line 1 extended permit tcp interface DMZ any eq 7009 (hitcnt=0) 0xb13a2776

access-list streaming59; 1 elements; name hash: 0x959c1f3b

access-list streaming59 line 1 extended permit tcp object 76.77.19.59 interface outside object-group Streaming_custom 0xc173840d

access-list streaming59 line 1 extended permit tcp host 76.77.19.59 interface outside eq 7009 (hitcnt=0) 0x84cd9084

access-list streaming_outside_in; 4 elements; name hash: 0x3f86c9d4

access-list streaming_outside_in line 1 extended permit tcp interface outside object-group INLINE_NETWORK_1 object-group DM_INLINE_TCP_2

  access-list streaming_outside_in line 1 extended permit tcp interface outside host 206.57.19.53 eq 7009 (hitcnt=0) 0x06c04720

  access-list streaming_outside_in line 1 extended permit tcp interface outside host 206.57.19.53 eq 5986 (hitcnt=0) 0x9ae9047e

  access-list streaming_outside_in line 1 extended permit tcp interface outside host 255.255.255.255 eq 7009 (hitcnt=0) 0x5e3553e8

  access-list streaming_outside_in line 1 extended permit tcp interface outside host 255.255.255.255 eq 5986 (hitcnt=0) 0x1f5d8fd9

access-list neighbor; 7 elements; name hash: 0xc99eb2b4

access-list neighbor line 1 extended permit object-group INLINE_SERVICE_2 object NET-neighbor object Inside_lan 0xc9688a21

  access-list neighbor line 1 extended permit ip 170.20.0.0 255.255.0.0 10.20.145.0 255.255.255.0 (hitcnt=0) 0xe1e8b995

  access-list neighbor line 1 extended permit tcp 170.20.0.0 255.255.0.0 10.20.145.0 255.255.255.0 (hitcnt=0) 0x462beedc

  access-list neighbor line 1 extended permit tcp 170.20.0.0 255.255.0.0 10.20.145.0 255.255.255.0 eq ftp (hitcnt=0) 0xf238c75e

  access-list neighbor line 1 extended permit tcp 170.20.0.0 255.255.0.0 10.20.145.0 255.255.255.0 eq ftp-data (hitcnt=0) 0x266e675b

  access-list neighbor line 1 extended permit tcp 170.20.0.0 255.255.0.0 10.20.145.0 255.255.255.0 eq www (hitcnt=0) 0x8627ec0a

  access-list neighbor line 1 extended permit tcp 170.20.0.0 255.255.0.0 10.20.145.0 255.255.255.0 eq https (hitcnt=0) 0x3cae424a

  access-list neighbor line 1 extended permit tcp 170.20.0.0 255.255.0.0 10.20.145.0 255.255.255.0 eq ssh (hitcnt=0) 0xcb6666b3

1 Accepted Solution

Accepted Solutions

Hi,

In the case of the ACL' should I should aim to make one acl with many  ace's that would control traffic from "outside" to "inside" and to  "dmz".  Additionally than, should I create one ACL with many ACE's that  would control traffic from "inside" to "outside" - and the same for the  "DMZ" to outside?  In essence having fewer ACL's with greater amount of  ACEs?

Yes, basically ASA when it comes to controlling traffic from behind each interface, you only use ONE ACL to control that traffic. This ACL will then contain all the needed rules to control traffic entering the ASA. And these ACLs are usually attached to the ASA interface in "inbound" direction.

For example

access-list INSIDE-IN permit ip any any

access-group INSIDE-IN in interface inside

access-list DMZ-IN permit ip any any

access-group DMZ-IN in interface dmz

Naturally the ACLs will look totally different in an actual production environment. The above was just to give an example.

There are some cases where you might want to use also an "outbound" ACL on an interface that already has an "inbound" ACL. The latest example from these forums was a situation where a user wanted to block all traffic destined to some IP on the Internet. Naturally this could be done on the "inbound" ACLs of the local interfaces but naturally the same could be done with a single ACL on the "outside" interface of the ASA.

For example like this

access-list OUTSIDE-OUT remark Block All Traffic to Specific Public IP

access-list OUTSIDE-OUT deny ip any host 1.2.3.4

access-list OUTSIDE-OUT remark Allow All Other Traffic Outbound to Internet

access-list OUTSIDE-OUT permit ip any any

access-group OUTSIDE-OUT out interface outside

With the current device a juniper ssg we're not seeing asymetrical  routing problems, but I'm not sure if the ASA will treat the traffic  differently?

The key thing with ASA is that IF the ASA sees some TCP  connection SYN packet, IT HAS TO SEE the TCP SYN,ACK also. Otherwise you will run into a situation where the last part of the TCP connection negotiation (TCP ACK) is sent to the ASA but the ASA hasnt seen the SYN ACK. Therefore the ASA will simply block the connection from ever forming. (Blocks the TCP ACK)

The workaround for this is to configure TCP State Bypass but naturally this isnt a good choice. I am not 100% sure if this would happen after you migration but I just felt I want to stress this fact so that you dont find yourself in a bad situation when you eventually do the device change

- Jouni

View solution in original post

4 Replies 4

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

For the Default Dynamic PAT rule that you are asking for the single "inside" network I would suggest the following

First remove the current NAT configurations

nat (inside,outside) source dynamic any interface

!

object network Inside_lan

nat (any,outside) dynamic interface

Then reconfigure the NAT in the following way

object-group network DEFAULT-PAT-SOURCE

network-object 10.20.145.0 255.255.255.0

nat (inside,outside) after-auto sourece dynamic DEFAULT-PAT-SOURCE interface

This will create and "object-group" for the networks or hosts that should be PATed to the "outside" interface IP address when accessing the Internet. If you want more internal networks to get PATed the same way, you simply add the network under the "object-group" among the already existing "inside" network.

The "after-auto" parameter also makes sure that this NAT rule doesnt override any other future rules. The parameter in question moves the NAT rule at the bottom of the NAT rules so its one of the last matched agains when traffic arrives on the firewall from behind "inside"

With regards to the neighbor network of 172.20.0.0/16, is this some network that is going to be behind a L2L VPN or is simply almost directly behind the "outside" interface?

In general the NAT format for this kind NAT is

object network NEIGHBOR

subnet 172.20.0.0 255.255.0.0

object-group network NEIGHBOR-SOURCE

network-object 10.20.145.0 255.255.255.0

nat (inside,outside) source static NEIGHBOR-SOURCE NEIGHBOR-SOURCE destination static NEIGHBOR NEIGHBOR

I basically use an "object network" to define the remote network and "object-group network" to define the source network for this NAT. I use "object-group" for the source again because it leaves us room to add more networks under it if needed. Notice that "object network" can only hold one subnet/range/host while "object-group network" can hold pretty much as many as you want.

I think the ACL configurations will have to be looked through also.

Notice that if you want to control traffic from a behind "outside" for example, then you can only use 1 interface bound ACL to control that traffic. So every rule from "outside" to "inside" or to "dmz" has to be in the same ACL. Also this ACL would be attached to the "outside" interface in "in" direction. For example "access-group OUTSIDE-IN in interface outside"

If we are talking about VPN connections configured directly to the ASA there are some other options compared to the above.

But as I said its better that your needs regards the ACL rules are gone through more in depth to really know how we should configure them as I am myself not sure what all the above ACL are supposed to do.

One final question for you. You have this network directly on the "inside" interface 10.20.145.3 255.255.255.192. But you also talk about it with mask /24. Is the ASA "inside" connected to some internal L3 device which hosts rest of the segments of this whole /24 network as currently the "inside" interface holds /26.

Is ANY users/networks behind the ASA "inside" interface using the ASA directly as their gateway? I noticed that you setup would seem to have (as I mentioned in another thread to you) several devices on connected by the same LAN network (Router,VPN,firewall). What I fear will happen is that IF any "inside" users uses the ASA as their gateway and has to be routed back through the ASA "inside" interface to some other gateway that this will result in asymmetric routing and the ASA doesnt really handle that kind of situation that well.

- Jouni

Hi Jouni thanks for your feed back, the NAT rules will surely help me as I have in mind adding another network to the inside interface which will need outside access your solution will help me manage that much easier:

As to your questions:

With regards to the neighbor network of 172.20.0.0/16, is this some  network that is going to be behind a L2L VPN or is simply almost  directly behind the "outside" interface?

Yes this network connects on a L2L currently configured on vpn concentrator that connects to external host.  Currently the networks pass traffic viaa L2L tunnel.  I am trying to make sure that tunnel remains unchanged as I swap out devices.  Basically that 10.20.145.x network can ping across to the 170.20.x.x - but I'm not looking to tackle that part of upgrade just yet as my downtimes are very limited.

In the case of the ACL' should I should aim to make one acl with many ace's that would control traffic from "outside" to "inside" and to "dmz".  Additionally than, should I create one ACL with many ACE's that would control traffic from "inside" to "outside" - and the same for the "DMZ" to outside?  In essence having fewer ACL's with greater amount of ACEs?

One final question for you. You have this network directly on the  "inside" interface 10.20.145.3 255.255.255.192. But you also talk about  it with mask /24. Is the ASA "inside" connected to some internal L3  device which hosts rest of the segments of this whole /24 network as  currently the "inside" interface holds /26.

There is a 3750 switch that has the rest of the segments for 10.20.145.0/24 it connects various vlans that belong to various subnets.  currently 10.20.145.3/192 is configured for the inside interface of the live firewall I thought to use the same one. 

As a side note I would prefer this wasnt the case and that actual separate networks (not subnets) would belong to VLANs, but changing this would mean manual re-ip of about 200 devices (really dhcp range is extremely small rest are all statics). 

Thanks for remembering my last post and the asymetrical routing issue.  I believe have worked out how traffic is currently flowing (this is what is currently happening)

The ASA will not be used as the direct gateway for internal clients (or at least I don't believe so):  All clients have a default gateway of 10.20.145.15 - this is the switchs VLAN IP.  The switch itself has a gateway of 10.20.145.2 - this is an MPLS router that connects solely to a remote site.  Any non mpls traffic is than sent to the firewall.  Any outside traffic should be sent to the outside interface inside traffic for 10.20.145.0/24 from client to client should never reach it as the 3750 should route that to connected networks without forwarding it. 

Since it is the single device doing state inspection of the packet the state of the packet should return to the same firewall - the outside traffic coming should go from the firewall to 10.20.145.15 and than back to the clients on that segment. 

In the case of packets that are not destined for mpls and are destined for 10.0.0.0/24 network the firewall has a direct route configured to send that traffic to 10.20.145.4 (VPN, site-to-site) that packet should than come back to 10.20.145.4 which has default gateway to 10.12.175.15 which has all the hosts connected to it (its actually 2 3750's working as one to clarify).   As I trace route to 10.0.0.1 client traffic goes from

10.20.145.15

10.20.145.2

10.20.145.4

10.0.0.1

With the current device a juniper ssg we're not seeing asymetrical routing problems, but I'm not sure if the ASA will treat the traffic differently?

(there have been some other problems with the device but not this)      

Hi,

In the case of the ACL' should I should aim to make one acl with many  ace's that would control traffic from "outside" to "inside" and to  "dmz".  Additionally than, should I create one ACL with many ACE's that  would control traffic from "inside" to "outside" - and the same for the  "DMZ" to outside?  In essence having fewer ACL's with greater amount of  ACEs?

Yes, basically ASA when it comes to controlling traffic from behind each interface, you only use ONE ACL to control that traffic. This ACL will then contain all the needed rules to control traffic entering the ASA. And these ACLs are usually attached to the ASA interface in "inbound" direction.

For example

access-list INSIDE-IN permit ip any any

access-group INSIDE-IN in interface inside

access-list DMZ-IN permit ip any any

access-group DMZ-IN in interface dmz

Naturally the ACLs will look totally different in an actual production environment. The above was just to give an example.

There are some cases where you might want to use also an "outbound" ACL on an interface that already has an "inbound" ACL. The latest example from these forums was a situation where a user wanted to block all traffic destined to some IP on the Internet. Naturally this could be done on the "inbound" ACLs of the local interfaces but naturally the same could be done with a single ACL on the "outside" interface of the ASA.

For example like this

access-list OUTSIDE-OUT remark Block All Traffic to Specific Public IP

access-list OUTSIDE-OUT deny ip any host 1.2.3.4

access-list OUTSIDE-OUT remark Allow All Other Traffic Outbound to Internet

access-list OUTSIDE-OUT permit ip any any

access-group OUTSIDE-OUT out interface outside

With the current device a juniper ssg we're not seeing asymetrical  routing problems, but I'm not sure if the ASA will treat the traffic  differently?

The key thing with ASA is that IF the ASA sees some TCP  connection SYN packet, IT HAS TO SEE the TCP SYN,ACK also. Otherwise you will run into a situation where the last part of the TCP connection negotiation (TCP ACK) is sent to the ASA but the ASA hasnt seen the SYN ACK. Therefore the ASA will simply block the connection from ever forming. (Blocks the TCP ACK)

The workaround for this is to configure TCP State Bypass but naturally this isnt a good choice. I am not 100% sure if this would happen after you migration but I just felt I want to stress this fact so that you dont find yourself in a bad situation when you eventually do the device change

- Jouni

That makes complete sense for the ACL management.  I was concerned with traffic inside making it out, but since that traffic will be initiated from higher level interface 100 to 0 it should flow easily and making an ACL to allow inside to out does seem silly in hindsight. 

I've read up some more on the Asymetric routing and possible issues, its definately something to take into account and that I'll be looking for in the live environment if I see connection issues, thanks I would not have looked at that as possible culprit on my own. 

This will also help me with plan to run a secondary firewall for redundancy down the line in active/passive mode where asymetric routing appears as a real big issue when configuring the passive device.

Thanks again, the feedback helped me understand configurations beyond the questions asked, and I'll be back when it comes time to configure vpn tunnels.

Review Cisco Networking for a $25 gift card