cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
385
Views
0
Helpful
5
Replies

ASA5580 / SDM6.3(2) - Question about ensuring that inside hosts one hop away forwards traffic via a site to site vpn tunnel

sgonsalv
Level 1
Level 1

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

5 Replies 5

Jouni Forss
VIP Alumni
VIP Alumni

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

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

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

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

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

Getting Started

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: