Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Cisco ASA 5505 Static Routing and Clients
I have a Cisco ASA 5505 acting as my def. gateway for my network. (192.168.20.1). I have another static route network (192.168.10.0), which is accessible via (192.168.20.80).
The ASA can ping anything in the 192.168.10.0 network just fine, however none of my workstations who use 192.168.20.1 as their def. gateway can ping the 192.168.10.0 network. I'm guessing I'm missing something simple on the ASA.
Ideas? ASA Configuration is below.
The ASA can ping anything in the 192.168.10.0 network just fine, however none of my workstations who use 192.168.20.1 as their def. gateway can ping the 192.168.10.0 network. I'm guessing I'm missing something simple on the ASA.
Ideas? ASA Configuration is below.
: Saved
:
ASA Version 8.2(1)
!
hostname FIREWALL
enable password * encrypted
passwd * encrypted
names
name 192.168.20.20 DC-03
name 192.168.20.46 RADIO
!
interface Vlan1
shutdown
no nameif
no security-level
no ip address
!
interface Vlan2
nameif outside
security-level 0
ip address x.x.x.10 255.255.255.252
!
interface Vlan20
nameif inside
security-level 100
ip address 192.168.20.1 255.255.254.0
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
switchport access vlan 20
!
interface Ethernet0/3
switchport access vlan 20
!
interface Ethernet0/4
switchport access vlan 20
!
interface Ethernet0/5
switchport access vlan 20
!
interface Ethernet0/6
switchport access vlan 20
!
interface Ethernet0/7
switchport access vlan 20
!
ftp mode passive
clock timezone EST -5
clock summer-time EDT recurring
dns domain-lookup outside
dns server-group DefaultDNS
name-server x.x.x.1
name-server x.x.x.2
same-security-traffic permit intra-interface
object-group service VPN
service-object gre
service-object tcp eq pptp
object-group service WEB
service-object tcp eq www
service-object tcp eq https
object-group service RADIO
service-object udp eq 10195
object-group service EMAIL
service-object tcp eq smtp
service-object tcp eq https
object-group service BES
service-object tcp eq 3101
access-list outside_access_in extended permit icmp any any echo-reply
access-list outside_access_in extended permit gre any any
access-list outside_access_in extended permit tcp any any eq pptp
access-list outside_access_in extended permit object-group VPN any host x.x.x.129
access-list outside_access_in extended permit object-group RADIO any host x.x.x.130
pager lines 24
logging enable
logging asdm informational
logging host inside 192.168.10.33
mtu outside 1500
mtu inside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,outside) x.x.x.129 DC-03 netmask 255.255.255.255
static (inside,outside) x.x.x.130 RADIO netmask 255.255.255.255
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 x.x.x.9 1
route inside 192.168.10.0 255.255.254.0 192.168.20.80 1
route inside 192.168.30.0 255.255.255.0 192.168.10.1 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
aaa authentication ssh console LOCAL
http server enable
http 192.168.10.0 255.255.254.0 inside
http 192.168.20.0 255.255.254.0 inside
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 timeout 5
ssh 192.168.20.0 255.255.254.0 inside
ssh 192.168.10.0 255.255.254.0 inside
ssh 192.168.30.0 255.255.255.0 inside
ssh timeout 15
console timeout 0
priority-queue outside
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
username * password * encrypted privilege 15
!
class-map cloass-default
class-map inspection_default
match default-inspection-traffic
!
!
policy-map QOS-TRAFFIC-OUT
class class-default
shape average 20000000
policy-map global_policy
class inspection_default
inspect pptp
!
service-policy global_policy global
service-policy QOS-TRAFFIC-OUT interface outside
prompt hostname context
Cryptochecksum:a0bb4c3e7b41f636d9a0fd7cb2d33259
: end
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Try adding:
static (inside,inside) 192.168.10.0 192.168.10.0 netmask 255.255.255.0
static (inside,inside) 192.168.20.0 192.168.20.0 netmask 255.255.255.0
static (inside,inside) 192.168.10.0 192.168.10.0 netmask 255.255.255.0
static (inside,inside) 192.168.20.0 192.168.20.0 netmask 255.255.255.0
You will also probably need to create a TCP State Bypass policy
access-list tsb extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
access-list tsb extended permit ip 192.168.20.0 255.255.255.0 192.168.10.0 255.255.255.0
class-map stateBypassMap
match access-list tsb
policy-map global_policy
class stateBypassMap
set connection advanced-options tcp-state-bypass
service-policy global_policy global
access-list tsb extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
access-list tsb extended permit ip 192.168.20.0 255.255.255.0 192.168.10.0 255.255.255.0
class-map stateBypassMap
match access-list tsb
policy-map global_policy
class stateBypassMap
set connection advanced-options tcp-state-bypass
service-policy global_policy global
Now that I'm looking at your config more there is alot you need to do to make this work.
your route to the 192.168.30.x network should use the 192.168.20.80 gateway and then on the .80 you should have a route that goes to the 192.168.30.x network.
You also want to set it all not to nat these communications.
Add:
access-list tsb extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
access-list tsb extended permit ip 192.168.20.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list tsb extended permit ip 192.168.30.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list tsb extended permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0
static (inside,inside) 192.168.30.0 192.168.30.0 netmask 255.255.255.0
access-list nonat extended permit ip 192.168.30.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list nonat extended permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0
access-list nonat extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
access-list nonat extended permit ip 192.168.20.0 255.255.255.0 192.168.10.0 255.255.255.0
nat (inside) 0 access-list nonat
class-map stateBypassMap
match access-list tsb
policy-map global_policy
class stateBypassMap
set connection advanced-options tcp-state-bypass
your route to the 192.168.30.x network should use the 192.168.20.80 gateway and then on the .80 you should have a route that goes to the 192.168.30.x network.
You also want to set it all not to nat these communications.
Add:
access-list tsb extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
access-list tsb extended permit ip 192.168.20.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list tsb extended permit ip 192.168.30.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list tsb extended permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0
static (inside,inside) 192.168.30.0 192.168.30.0 netmask 255.255.255.0
access-list nonat extended permit ip 192.168.30.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list nonat extended permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0
access-list nonat extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
access-list nonat extended permit ip 192.168.20.0 255.255.255.0 192.168.10.0 255.255.255.0
nat (inside) 0 access-list nonat
class-map stateBypassMap
match access-list tsb
policy-map global_policy
class stateBypassMap
set connection advanced-options tcp-state-bypass
to confirm, is this the full picture? the asa faces the internet and has 192.168.20.1 on the inside. there is a router 20.80 which is also connected to 192.168.10.0 and there is another router on the 10.0 network which routes to 192.168.30.0? and all the clients in 192.168.20.0 use the asa as their default gateway?
if the above is correct, i have to politely suggest that you ignore all the above responses. forget about nat control, static translations and access lists. the asa will not act as a router - by design. what this means is that if a client on one interface uses the asa as a default gateway and the asa has routes pointing to other networks via routers connected to the same interface, the asa will not route this traffic.
the restriction is that a packet arriving at the asa on any interface will never be forwarded back out that same interface, unless it either arrives via, or leaves via, or both arrives by and leaves by ipsec vpn. this is regardless of the routing config in the asa.
you can make this work however, as long as 192.168.20.80 is not another asa or pix.
1 change the default gateway of the clients on 192.168.20.0 to use 192.168.20.80
2 configure the default route for the 192.168.20.80 router to point to the asa's 192.168.20.1 address.
3 if 192.168.20.80 does not have an interface in 192.168.10.0, then it needs a route for that network
4 192.168.20.80 also needs a route for 192.168.30.0 pointing to 192.168.10.1, if its not there already.
5 the asa route for 192.168.30.0 should point to 192.168.20.80
6 192.168.10.1 needs a route for 192.168.20.0, if its not the same next hop as its default route.
thats all you need for clients in 192.168.20.0 to reach 192.168.10.0 and 192.168.30.0.
if the above is correct, i have to politely suggest that you ignore all the above responses. forget about nat control, static translations and access lists. the asa will not act as a router - by design. what this means is that if a client on one interface uses the asa as a default gateway and the asa has routes pointing to other networks via routers connected to the same interface, the asa will not route this traffic.
the restriction is that a packet arriving at the asa on any interface will never be forwarded back out that same interface, unless it either arrives via, or leaves via, or both arrives by and leaves by ipsec vpn. this is regardless of the routing config in the asa.
you can make this work however, as long as 192.168.20.80 is not another asa or pix.
1 change the default gateway of the clients on 192.168.20.0 to use 192.168.20.80
2 configure the default route for the 192.168.20.80 router to point to the asa's 192.168.20.1 address.
3 if 192.168.20.80 does not have an interface in 192.168.10.0, then it needs a route for that network
4 192.168.20.80 also needs a route for 192.168.30.0 pointing to 192.168.10.1, if its not there already.
5 the asa route for 192.168.30.0 should point to 192.168.20.80
6 192.168.10.1 needs a route for 192.168.20.0, if its not the same next hop as its default route.
thats all you need for clients in 192.168.20.0 to reach 192.168.10.0 and 192.168.30.0.
Hello pgolding00,
It is possible by using command:
same-security-traffic permit intra-interface
"The same-security-traffic intra-interface command lets traffic enter and exit the same interface, which is normally not allowed. This feature might be useful for VPN traffic that enters an interface, but is then routed out the same interface. The VPN traffic might be unencrypted in this case, or it might be reencrypted for another VPN connection. For example, if you have a hub and spoke VPN network, where the adaptive security appliance is the hub, and remote VPN networks are spokes, for one spoke to communicate with another spoke, traffic must go into the adaptive security appliance and then out again to the other spoke. "
More info here:
http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/s1.html#wp1421315
http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080734db7.shtml
And that command exist in posted configuration, so it should work, without any suggestions from above (including mine with no nat-control)
One thing to note:
Note: All traffic allowed by the same-security-traffic intra-interface command is still subject to firewall rules. Be careful not to create an asymmetric routing situation that can cause return traffic not to traverse the adaptive security appliance.
So for the test, try to put ACL on inside which permits all traffic in and out, and try to configure no nat-control, just to be sure NAT is not the issue.
If that works, we can work on increasing security from that point.
Regards!
It is possible by using command:
same-security-traffic permit intra-interface
"The same-security-traffic intra-interface command lets traffic enter and exit the same interface, which is normally not allowed. This feature might be useful for VPN traffic that enters an interface, but is then routed out the same interface. The VPN traffic might be unencrypted in this case, or it might be reencrypted for another VPN connection. For example, if you have a hub and spoke VPN network, where the adaptive security appliance is the hub, and remote VPN networks are spokes, for one spoke to communicate with another spoke, traffic must go into the adaptive security appliance and then out again to the other spoke. "
More info here:
http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/s1.html#wp1421315
http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080734db7.shtml
And that command exist in posted configuration, so it should work, without any suggestions from above (including mine with no nat-control)
One thing to note:
Note: All traffic allowed by the same-security-traffic intra-interface command is still subject to firewall rules. Be careful not to create an asymmetric routing situation that can cause return traffic not to traverse the adaptive security appliance.
So for the test, try to put ACL on inside which permits all traffic in and out, and try to configure no nat-control, just to be sure NAT is not the issue.
If that works, we can work on increasing security from that point.
Regards!
Overview of the connectivity:
Cisco ASA 5505 #1 - (192.168.10.1) - Internet Connected, ISP #1
Cisco ASA 5505 #2 - (192.168.20.1) - Internet Connected, ISP #2
Cisco ASA 5505 #3 - (192.168.30.1) - Internet Connected
Cisco 3560 (192.168.10.80 & 192.168.20.80), VLAN Routing
ASA #1 & #3 are connected via a point to point tunnel
192.168.10 and 192.168.20 networks connect via point to point 20mb fiber, through the 3560.
Hope this helps, I will be playing with configurations later today and tomorrow.
Thanks.
Cisco ASA 5505 #1 - (192.168.10.1) - Internet Connected, ISP #1
Cisco ASA 5505 #2 - (192.168.20.1) - Internet Connected, ISP #2
Cisco ASA 5505 #3 - (192.168.30.1) - Internet Connected
Cisco 3560 (192.168.10.80 & 192.168.20.80), VLAN Routing
ASA #1 & #3 are connected via a point to point tunnel
192.168.10 and 192.168.20 networks connect via point to point 20mb fiber, through the 3560.
Hope this helps, I will be playing with configurations later today and tomorrow.
Thanks.
Fidelius: agree completely that same-security permit intra-interface works as you describe. this feature was added for exactly the reason mentioned in the summary you included - hub and spoke inter-vpn connectivity. and if does have side effects that allow it to be used to achieve traffic flow as you describe.
my point is i think we did not have full understanding of how this network is constructed and that information is likely to make a difference in finding a solution that will work. its better to find a solution that fits with the intended use of the device, especially in light of future support requirements from cisco or others.
Railroad: a simple test - if you add a static route for 192.168.10.0 pointing to 192.168.20.80 onto one of the 20.x clients that cant ping to 10.x, does the ping then work from the client? this should go via the 3560. so the question becomes how do you want this to work?
it sounds like you have 3 sites, each has internet service and asa. site 1 and 2 have fibre link interconnect, site 3 is only connected via vpn thru internet?
do you want traffic from 20.x to go via internet or via 3560 and fibre link?
do you want traffic from 30.x to go via 10.x site or via 20.x site and fibre link?
do you have any problems with traffic from 30.x site?
do you have full vpn tunnel mesh between the 3 sites (i.e. vpn between sites 1-2, 2-3, 1-3)?
do you just have vpn between 1-3, 2-3 because 1-2 havs direct fibre link?
if you want traffic from site 2 to go via fibre to site 1, there are two options. either what i described above, or what Fidelius has mentioned - same-interface permit intra-interface plus enough routing (static or otherwise) to make the site 2 asa aware of the available path(s), via the fibre link.
regards, pg
my point is i think we did not have full understanding of how this network is constructed and that information is likely to make a difference in finding a solution that will work. its better to find a solution that fits with the intended use of the device, especially in light of future support requirements from cisco or others.
Railroad: a simple test - if you add a static route for 192.168.10.0 pointing to 192.168.20.80 onto one of the 20.x clients that cant ping to 10.x, does the ping then work from the client? this should go via the 3560. so the question becomes how do you want this to work?
it sounds like you have 3 sites, each has internet service and asa. site 1 and 2 have fibre link interconnect, site 3 is only connected via vpn thru internet?
do you want traffic from 20.x to go via internet or via 3560 and fibre link?
do you want traffic from 30.x to go via 10.x site or via 20.x site and fibre link?
do you have any problems with traffic from 30.x site?
do you have full vpn tunnel mesh between the 3 sites (i.e. vpn between sites 1-2, 2-3, 1-3)?
do you just have vpn between 1-3, 2-3 because 1-2 havs direct fibre link?
if you want traffic from site 2 to go via fibre to site 1, there are two options. either what i described above, or what Fidelius has mentioned - same-interface permit intra-interface plus enough routing (static or otherwise) to make the site 2 asa aware of the available path(s), via the fibre link.
regards, pg
Sorry, been swamped at work the past few days. Read through your comments this morning.
@pgolding00: Yes adding a static route for 10.0, pointing at 20.80 would allow the client to ping devices in the 10.0 network. Yes you are correct on you description of our network layout.
Some clarification, until a week ago ASA #2 at site 2 didn't exist. Clients at site 2 have used 20.80 as their def. gateway up until now.
I'd like to see each site using their "local" ISP for Internet access and have the ability to get to devices at the other sites. My thought was to possibly also have the ability to change a command on the ASA and have all the clients from that site be forced to use the other sites Internet connection.
The only VPN I have is between site 1 (10.0) and site 3 (30.0), everything else has been done via vlan routing.
@pgolding00: Yes adding a static route for 10.0, pointing at 20.80 would allow the client to ping devices in the 10.0 network. Yes you are correct on you description of our network layout.
Some clarification, until a week ago ASA #2 at site 2 didn't exist. Clients at site 2 have used 20.80 as their def. gateway up until now.
I'd like to see each site using their "local" ISP for Internet access and have the ability to get to devices at the other sites. My thought was to possibly also have the ability to change a command on the ASA and have all the clients from that site be forced to use the other sites Internet connection.
The only VPN I have is between site 1 (10.0) and site 3 (30.0), everything else has been done via vlan routing.
Sounds like I'm asking the ASA's to do something they were not intended for. So how should have I have this all setup? Do I need to add a router on the 20.0 network and use it as the def. gateway? If so what hardware would be recommended.
So adding the commands:
static (inside,inside) 192.168.10.0 192.168.10.0 netmask 255.255.254.0
static (inside,inside) 192.168.20.0 192.168.20.0 netmask 255.255.254.0
static (inside,inside) 192.168.30.0 192.168.30.0 netmask 255.255.255.0
Corrected the issue, however are there any security risks to doing it this way?
Thanks in advance
static (inside,inside) 192.168.10.0 192.168.10.0 netmask 255.255.254.0
static (inside,inside) 192.168.20.0 192.168.20.0 netmask 255.255.254.0
static (inside,inside) 192.168.30.0 192.168.30.0 netmask 255.255.255.0
Corrected the issue, however are there any security risks to doing it this way?
Thanks in advance
Nope, everything stays at the inside. It's just that the ASA needs to do 'nat', even if it's to the same address (simply pu).
Well I've done some more playing... My accepted solution didn't actually correct the situation. Not sure why I didn't catch it before.
I have this same setup and it took a TAC call to get it resolved and my input above plus the statics you have entered was what it took to make it work.
To make it clear: you can now ping between the networks?
If so, it could be an access list somewhere.......
If so, it could be an access list somewhere.......
Ok to Clarify a little more... Add the commands:
static (inside,inside) 192.168.10.0 192.168.10.0 netmask 255.255.254.0
static (inside,inside) 192.168.20.0 192.168.20.0 netmask 255.255.254.0
static (inside,inside) 192.168.30.0 192.168.30.0 netmask 255.255.255.0
20.0 devices can ping the 10.0 network. However 10.0 devices can not ping 20.0 devices using 20.1 as their gateway.
static (inside,inside) 192.168.10.0 192.168.10.0 netmask 255.255.254.0
static (inside,inside) 192.168.20.0 192.168.20.0 netmask 255.255.254.0
static (inside,inside) 192.168.30.0 192.168.30.0 netmask 255.255.255.0
20.0 devices can ping the 10.0 network. However 10.0 devices can not ping 20.0 devices using 20.1 as their gateway.
Ehr, do you mean the 10.0 devices are using 20.1 as their gateway?
Just making sure we understand each other.
If that's not the case check the routes on the 10.1
Just making sure we understand each other.
If that's not the case check the routes on the 10.1
No... 10.0 devices using 10.80 as the gateway can not ping devices on the 20.0 network which are using 20.1 as their def. gateway. if they are using 20.80 as the def. gateway they are ping able.
20.0 devices using 20.1 as their def. gateway can ping 10.0 devices.
20.0 devices using 20.1 as their def. gateway can ping 10.0 devices.
Sorry been swamped at work... in the command:
access-list tsb extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
What is tsb?
access-list tsb extended permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
What is tsb?
I did just like you are doing, spun my wheels for days and then I called cisco and 2 hours later they set it up and BAM! It worked ;)
Sorry but I'm on my phone and in a meeting otherwise I would try to give you a more descriptive explanation.
tsb... can be any word... I was asking what is stood for... I'm guessing "TCP Stateful bypass"
Ok so entering the commands below did the trick. When I use 10.80 has the def. gateway. I'll have to play with the 10.1 ASA and add similar command to make it all work when using 10.1 has the def. gateway.
Thank you for you help, sorry I can't move points around at this point :(
static (inside,inside) 192.168.10.0 192.168.10.0 netmask 255.255.254.0
static (inside,inside) 192.168.20.0 192.168.20.0 netmask 255.255.254.0
static (inside,inside) 192.168.30.0 192.168.30.0 netmask 255.255.255.0
access-list tsb extended permit ip 192.168.10.0 255.255.254.0 192.168.20.0 255.255.254.0
access-list tsb extended permit ip 192.168.20.0 255.255.254.0 192.168.10.0 255.255.254.0
access-list tsb extended permit ip 192.168.30.0 255.255.255.0 192.168.10.0 255.255.254.0
access-list tsb extended permit ip 192.168.10.0 255.255.254.0 192.168.30.0 255.255.255.0
access-list nonat extended permit ip 192.168.30.0 255.255.255.0 192.168.10.0 255.255.254.0
access-list nonat extended permit ip 192.168.10.0 255.255.254.0 192.168.30.0 255.255.255.0
access-list nonat extended permit ip 192.168.10.0 255.255.254.0 192.168.20.0 255.255.254.0
access-list nonat extended permit ip 192.168.20.0 255.255.254.0 192.168.10.0 255.255.254.0
nat (inside) 0 access-list nonat
class-map stateBypassMap
match access-list tsb
policy-map global_policy
class stateBypassMap
set connection advanced-options tcp-state-bypass
Ok so entering the commands below did the trick. When I use 10.80 has the def. gateway. I'll have to play with the 10.1 ASA and add similar command to make it all work when using 10.1 has the def. gateway.
Thank you for you help, sorry I can't move points around at this point :(
static (inside,inside) 192.168.10.0 192.168.10.0 netmask 255.255.254.0
static (inside,inside) 192.168.20.0 192.168.20.0 netmask 255.255.254.0
static (inside,inside) 192.168.30.0 192.168.30.0 netmask 255.255.255.0
access-list tsb extended permit ip 192.168.10.0 255.255.254.0 192.168.20.0 255.255.254.0
access-list tsb extended permit ip 192.168.20.0 255.255.254.0 192.168.10.0 255.255.254.0
access-list tsb extended permit ip 192.168.30.0 255.255.255.0 192.168.10.0 255.255.254.0
access-list tsb extended permit ip 192.168.10.0 255.255.254.0 192.168.30.0 255.255.255.0
access-list nonat extended permit ip 192.168.30.0 255.255.255.0 192.168.10.0 255.255.254.0
access-list nonat extended permit ip 192.168.10.0 255.255.254.0 192.168.30.0 255.255.255.0
access-list nonat extended permit ip 192.168.10.0 255.255.254.0 192.168.20.0 255.255.254.0
access-list nonat extended permit ip 192.168.20.0 255.255.254.0 192.168.10.0 255.255.254.0
nat (inside) 0 access-list nonat
class-map stateBypassMap
match access-list tsb
policy-map global_policy
class stateBypassMap
set connection advanced-options tcp-state-bypass
Premium Content
You need an Expert Office subscription to comment.Start Free Trial