asa l2l vpn issues

[Random44F]

Hi all,

I have two firewalls which I am trying to set up l2l vpn between them. once of them is an old sonic wall and the other 5505.

I have set it all up and phase 1/2 completes and the tunnel comes up however no traffic passes through it

here is my setup,

asa (outside , 192.168.30.1) asa internal 192.168.10.0/25

sonicwall(outside , 192.168.30.2) sonicwall 192.168.20.0/24

i have an accesslist which is setup on the asa and applied to cypto map using crypto map XXXX 1 ,atch address YYY

however when I look at the ebugging information on the console it says, "failed to locate egress interface for UDP from XXXX :192.168.10.10/1 to 192.178.20.1/0

any ideas why this is ?

I don't need to have a static route to say any traffic on asa with source of 192...10.0 should go through 192.168.30.2?

I suppose this is the job of crypto map

am i correct ?

[Jouni Forss]

Hi,

Have you typoed some IP address in configurations since the below says 192.178.20.1

"failed to locate egress interface for UDP from XXXX :192.168.10.10/1 to 192.178.20.1/0"

- Jouni

[Jouni Forss]

I think most of the time your default route will handle that the ASA  chooses the correct destination/egress interface for the traffic. You  can also configure the "crypto map" statement of this connection with "set reverse-route" which should automatically install a route for the destination network in your ASAs routing table.

I am not sure why an external interface with a default  route would still result in the ASA not finding the egress interface  for the traffic.

- Jouni

[Random44F]

thanks for the prompt reply.

yes it was a typo, it should be 192.168.20.1 . I have a default route of

route outside_2 0.0.0.0 0.0.0.0 192.168.40.1  1

this is different from the interface used to establish the vpn.

i have no routes for the 192.168.20.1 network and if I do put one in, it does work however I guess that is a direct routing and not VPN as the VPN counters do not increase

[Jouni Forss]

Hi,

So the VPN is done on an interface which is not the inteface that holds the default route.

I think you might need the "crypto map set reverse-route" command in the L2L VPN configurations or alternatively have a static route configured for the remote network through the VPN interface.

Can you provide some "packet-tracer" command output that matches the VPN configurations

- Jouni

[Random44F]

thanks for the reply.

I did packet tracer and realised the access list was causing the issue. I have an access list in place which was used by crypto as follow

access-list AAA extended permit ip 192.168.10.0 255.255.255.192 192.168.20.0 255.255.255.0

the packet tracer should it as it was going through all stages including encrypt but then dropped at user-vpn stage . after further digging I realised If i put the reverse of above command ( from 20.0 to 10.0) in the same access-list then all works

so here are two questions.

why doesn't asa automatically define the route and needs a static route

2. does asa not keep trak of traffic ? if so why did it deny the traffic when I had a one way acl in . Maybe it is because ICMP is stateless and it was not keeping a track of the return packets ( echo reply)

[Jouni Forss · Accepted solution]

Hi,

Starting to seem to me that you might have a VPN Filter ACL configured for your L2L VPN and also that the VPN Filter ACL and the Crypto ACL are the same things meaning you are using a single ACL for both purposes.

Why I think its like this is the fact that you say that your L2L VPN negotiation goes through in the "packet-tracer" VPN Phase means the L2L VPN Crypto ACL was correct. But at the same time you say the connection was stopped at USER-VPN Phase. This points to a VPN Filter ACL being configured.

Considering all the above I also know that L2L VPN Filter ACLs behave with different logic than typical interface ACL. In L2L VPN the Filter ACL mentions the Remote Network as source ALWAYS and your Local Network as the destination ALWAYS.

So you adding a ACL rule with switched order of the networks would seem that this corrected the VPN Filter ACL problems and finally allowed the traffic. Naturally I can only guess as I have not seen any actual configurations at this point (which usually together with "packet-tracer" output help solve a problems faster than guessing )

If you do indeed have VPN Filter you might be able to track it down with the following commands

show run tunnel-group

Check if any "group-policy" is set then issue the command

show run group-policy

This output should list the name of the VPN Filter ACL if its set

With regards to the automatic route installantion. The default setting for ASA is that it will NOT create any static routes automatically according to the VPN configurations. This has to be manually enabled in the "crypto map" configurations or you can configure the static routes yourself manually.

ASA keeps track of the UDP and TCP connections by default. ICMP is only inspected if its enabled. By default it is NOT inspected.

Hope this helps

Please do remember to mark a reply as the correct answer if it answered your question.

Feel free to ask more if needed.

- Jouni

[Random44F]

You were 100% right. I did have vpn filter configured. I didn’t know the ACL in vpn filter is other way around.

Regarding the route, I am slightly confused and also disappointed. My sonicwall did not need to configure static route etc but this asa does . The sonicwall creates a tunnel and then dynamically add the route.

Does the router not have any mechanism to say once the tunnel is up, all traffic to the remote network ( for instance 10.0.0.0) should go through 1.1.1.1 ? do you have to add a static route for all vpns ?

if you have a default gwateway of 1.1.1.1 for all traffic, when the vpn traffic needs to cross to the other end(assuming tunnel is established) , would that be encrypted and passed to 1.1.1.1 ( encrypted using crypto map acl?)

if so I believe this means crypto acl always have to apply to the outside interface .

In my case I had a default gateway but the outside or the vpn interface was on a different interface . Thus I guess no traffic was passed between as my asa tried to send it to default gateway which had no clue what it is as also no crypto was applied to the outside interface for the internet. Just to clarify, I had two outside network , one for the internet and all traffic going through it and one for vpn only which had no route setup.

But again as I said, I was thinking the asa will setup the route after bringing the tunnel up.

[Jouni Forss · Accepted solution]

Hi,

Since you are essentially using 2 WAN interface of which one holds the default route for Internet traffic and the other one is meant for this L2L VPN you will have to do the following

Add the static route for the remote VPN gateway through the VPN interface.

Make sure you have the "set reverse-route" in the "crypto map" configuration for the L2L VPN configuration.

Lets look the situation from my own home ASA5505. The situation is not ideal as I have to use my WLAN interface to simulate the interface you have purely for VPN

Essentially the basic partial configuration is this

route WAN 0.0.0.0 0.0.0.0 x.x.x.x

object network LOCAL

subnet 10.0.0.0 255.255.255.0

object network REMOTE

subnet 10.0.100.0 255.255.255.0

nat (LAN,any) source static LOCAL LOCAL destination static REMOTE REMOTE

access-list L2LVPN extended permit ip 10.0.0.0 255.255.255.0 10.0.100.0 255.255.255.0

crypto map CRYPTOMAP 1 match address L2LVPN

crypto map CRYPTOMAP 1 set peer 1.1.1.1

crypto map CRYPTOMAP 1 set ikev1 transform-set AES-256

crypto map CRYPTOMAP interface WLAN

Essentially from the above configuration we can tell that the VPN Peer and the remote network would follow the default route configured out of WAN interface.

When we check the routing table we can't see any mention of the remote network 10.0.100.0/24

C    10.0.10.0 255.255.254.0 is directly connected, LAN

S    10.0.0.0 255.255.255.0 [1/0] via 10.0.10.1, LAN

C    10.0.255.0 255.255.255.0 is directly connected, WLAN

C    x.x.x.x 255.255.255.248 is directly connected, WAN

S*   0.0.0.0 0.0.0.0 [1/0] via x.x.x.x, WAN

Since we already have the CRYPTOMAP attached to WLAN interface too we now add a Static Route for the VPN Peer

route WLAN 1.1.1.1 255.255.255.255 10.0.255.100

C    10.0.10.0 255.255.254.0 is directly connected, LAN

S    10.0.0.0 255.255.255.0 [1/0] via 10.0.10.1, LAN

C    10.0.255.0 255.255.255.0 is directly connected, WLAN

C    x.x.x.x 255.255.255.248 is directly connected, WAN

S    1.1.1.1 255.255.255.255 [1/0] via 10.0.255.100, WLAN

S*   0.0.0.0 0.0.0.0 [1/0] via x.x.x.x, WAN

Now for the last part we add the "crypto map CRYPTOMAP 1 set reverse-route" and check the routing table again

C    10.0.10.0 255.255.254.0 is directly connected, LAN

S    10.0.0.0 255.255.255.0 [1/0] via 10.0.10.1, LAN

S    10.0.100.0 255.255.255.0 [1/0] via 10.0.255.100, WLAN

C    10.0.255.0 255.255.255.0 is directly connected, WLAN

C    x.x.x.x 255.255.255.248 is directly connected, WAN

S    1.1.1.1 255.255.255.255 [1/0] via 10.0.255.100, WLAN

S*   0.0.0.0 0.0.0.0 [1/0] via x.x.x.x, WAN

So as you can see the ASA automatically adds a Static Route for the remote network and uses the gateway IP address that we had in the Static Route for the VPN peer IP.

Notice also the L2L VPN is not up. The VPN peer IP is made up and no traffic for the VPN has been generated so the route is created automatically on the basis of the Crypto ACL.

Hope this helps

- Jouni

[Random44F]

thank you very much

very good and detailed explanation.

so the set reverse route command is used to dynamically add the route back to remote as I understand ? I am also going to try it now

Again thanks for helping on this and taking time to run a test environment etc

[Jouni Forss]

Hi,

Glad to help

Yes the "set reverse-route" is used to add the route based on the L2L VPN configurations

Let us know if the above works for you and mark the reply as a correct answer if it answered your question.

Feel free to ask more though.

- Jouni

[Random44F]

sorry for asking many questions but I did remove the filter and tried again which meant I do not need the 2 entries in the ACL.

One question I have is , for testing perposes, I did use a crypto map with acl like this

access-list text extended permit ip 192.168.10.0 255.255.255.0 any

this worked but soon after it would tear the connection down and up again and was not stable . After debugging it had an rror saying duplicate entry already in tunnel manager

Any ways after changing this from any to 192.168.20.0 255.255.255.0 it does work fine, would that any cause any issues?

is it not simply that the router will encrypt everything from 192.168.20.0 and if it doesn't have a route to it just drop it ?

I know this is not ideal but just curious

thanks