04-19-2013
08:24 PM
- last edited on
03-25-2019
05:50 PM
by
ciscomoderator
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
Solved! Go to Solution.
04-20-2013 10:34 AM
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
04-19-2013 08:59 PM
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
04-19-2013 10:55 PM
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)
04-20-2013 10:34 AM
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
04-20-2013 12:28 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide