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.
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
pgolding00
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.
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.
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
Railroad
ASKER
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.
Railroad
ASKER
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.
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.
Railroad
ASKER
TAC? Ok I'll play again.
Ernie Beek
To make it clear: you can now ping between the networks?
If so, it could be an access list somewhere.......
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
Railroad
ASKER
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.
ShareefHuddle
So did you add the statebypass lines and the nonat acl's?
Sorry but I'm on my phone and in a meeting otherwise I would try to give you a more descriptive explanation.
Railroad
ASKER
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
Oh, yeah that's what the tsb stood for. Glad to hear it worked. If you can move the points around that would be great but if not no biggie. I'm just glad to not only help but to see I'm not the only one that has ran into the issue. Have a good one!
Shareef
Ernie Beek
Well seeing that I only have given a part of the solution, I'm not the type to hold on to his points. Try pressing the button 'request attention' and explain to a moderator you would like to redistribute the points. I will do the same stating I only find that a fair solution.
no nat-control
Regards!