05-09-2013 10:18 PM
Hi Guys,
Might sound like a basic question.
Some points:
1. We have setup a site to site VPN tunnel between our ASA (Monash) and the external site (BMC).
2. The inside interface is 130.194.9.209/28 (VLAN303)
3. The outside interface is 130.194.9.193/28 (VLAN302)
4 Our ASA is configured in routed mode
2. The servers within our network that need to use this tunnel sit one router hop away from the ASA, i.e. the servers are not on a directly attached subnet to the ASA.
3. Due to 2 above, I would need to setup some host routes on the downstream router (which is one from the ASA), to presumably point to the inside interface of our ASA (i.e. 130.194.9.209)?
4. The other question is whether I require to configure any static routes on the ASA itself, and if so what would it look like? Essentially I need the traffic to traverse the site to site tunnel...
Hope this makes sense.
Any help would be appreciated,.
thanks
Sheldon
05-09-2013 10:27 PM
Hi,
So you have a Router behind the ASA on the LAN network and the servers sit on LAN connected to that Router? Then I would assume that the Router already has a default route pointing towards the LAN interface of the ASA? This should alteast be the basic setup provided that there is no other form of Internet connection connected to the Router behind the ASA?
When the traffic for the remote site network reaches the ASA then usually routing wise the ASAs default route is enough to handle the fact that the ASA chooses the correct interface which to use to forward the traffic out of. Usually the more important parameters related to the L2L VPN operation are the actual VPN parameters and if you have the proper NAT configurations so that the traffic from the server source addresses match the configured VPN settings.
Naturally the easiest way to look through this would be seeing the configurations.
Also the ASA has a CLI command called "packet-tracer" which would tells us what rules/configurations a certain packet would hit on the ASA and this could actually be used to confirm if the ASA would forward the packet to the L2L VPN connection.
CLI command format is
packet-tracer input inside tcp
(Provided that your LAN interface on the ASA is called "inside")
The same Packet Tracer test can be done through ASDM also. (From the top menus)
- Jouni
05-09-2013 11:01 PM
Hi Jouni,
Thanks for the info.
>> So you have a Router behind the ASA on the LAN network and the servers sit on LAN connected to that Router?
Correct
>> Then I would assume that the Router already has a default route pointing towards the LAN interface of the ASA?
I will be configuring a static route on this router behind the ASA to point to the lan interface on the ASA rather than a static route, becuase this router has a separate path to the internet. One question here, I imagine that the static route should be pointing to the inside interface on the ASA right?
Thanks for pointing out the packet-tracer tool which has been quite useful to see what the ASA actually does. I can see the following as per the attached pic. Note, that the packet is "dropped". Wondering if I need to update the firewall rules on the ASA to permit the specific traffic (i.e. between hosts on our network and the hosts on the external network)?
thanks
Sheldon
05-09-2013 11:07 PM
Ok,
So the router has another path that it should take towards the Internet. In other words the default route is pointing to somewhere else on the router than the ASA. This is naturally ok for this setup.
You should then configure a static route or several static routes on the Router that point towards the "inside" IP address of the ASA. The routers should be for those networks that are to be found behind the L2L VPN connection.
Just to make sure, can you run the packet-tracer twice and see if the VPN Phase changes.
In general the first packet-tracer with regards to VPN connections always fails as the first try initiates the VPN negotiation and after that the next time goes through as then the VPN has been negotiated up. If the packet-tracer fails on the second try too then there might be some problem with regards to the configurations.
Btw, check the box for TCP when you are testing.
- Jouni
05-09-2013 11:17 PM
So the router has another path that it should take towards the Internet. In other words the default route is pointing to somewhere else on the router than the ASA. This is naturally ok for this setup.
You should then configure a static route or several static routes on the Router that point towards the "inside" IP address of the ASA. The routers should be for those networks that are to be found behind the L2L VPN connection.
>> Sure sounds good
Just to make sure, can you run the packet-tracer twice and see if the VPN Phase changes.
In general the first packet-tracer with regards to VPN connections always fails as the first try initiates the VPN negotiation and after that the next time goes through as then the VPN has been negotiated up. If the packet-tracer fails on the second try too then there might be some problem with regards to the configurations.
>> We've run it a few times and on all of them the packet is dropped at the "outside" interface, hence why i'm wondering if we need to update the firewall? What are your thoughts here. I should add that the site to site tunnel was setup fine without any issues.
thanks
Sheldon
05-09-2013 11:48 PM
Hi.
From the CLI config we have the following access-lists:
access-list outside_1_cryptomap extended permit ip object-group Monash-remedy-DEV-QAT object-group Remedy-DEV-QAT
access-list outside_2_cryptomap extended permit ip object-group Monash-Remedy-Prod object-group BMC-Remedy-Prod
object network 10-170-138-171
host 10.170.138.171
description 10-170-138-171
object network 10-170-144-129
host 10.170.144.129
description 10-170-144-129
object network 10-170-145-186
host 10.170.145.186
description 10-170-145-186
object network 10-170-5-144
host 10.170.5.144
description 10-170-5-144
object network 130-194-10-226
host 130.194.10.226
description 130-194-10-226
object network 130-194-10-41
host 130.194.10.41
description 130-194-10-41
object network 130-194-11-114
host 130.194.11.114
description 130-194-11-114
object network 130-194-11-146
host 130.194.11.146
description 130-194-11-146
object network 130-194-24-139
host 130.194.24.139
description 130-194-24-139
object network 130-194-24-140
host 130.194.24.140
description 130-194-24-140
object network 130-194-24-235
host 130.194.24.235
description 130-194-24-235
object network 130-194-24-236
host 130.194.24.236
description 130-194-24-236
The above is a snipit to show that the traffic between the devices i'm testing with via the packet tracer tool is allowed....so the "dropping" is odd?!
thanks
Sheldon
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: