cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2774
Views
20
Helpful
8
Replies

site-to-site VPN with nat static on ASA 5515X Version 8.6(1)2

Hi,

We would like to configure site-to-site VPN between 2 sites.

the IP address used in the 2 sites are the same, so we need to nat our internal IP address when it communicates to the peer.

we use ASA 5515X, with IOS version 8.6(1)2

we tried the following configuration but it does not work.

object-group network Obj_LAN

network-object IP_LAN

object network Obj_LAN_Peer

subnet IP_LAN_Peer

object-group network Obj_LAN_NAT

network-object IP_LAN_NAT

nat (inside,outside) source static Obj_LAN Obj_LAN_NAT destination static Obj_LAN_Peer Obj_LAN_Peer

access-list VPN_ACL extended permit ip object-group Obj_LAN_NAT object-group Obj_LAN_Peer.

Could anyone please help?

8 Replies 8

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

The information provided is not enough. We can see the actual L2L VPN networks and the NAT configurations also dont show us the actual networks used.

Provide us with the full output of a "packet-tracer" command that uses your side real source address and the IP address of the remote site that they use for their NAT (since both sites do NAT?)

packet-tracer input inside tcp 12345 80

Change the destination port if needed. Insert the actual real source IP address and the destination IP address of the host on the remote site.

This should tell us what NAT configuration is matched and if there is problem with other ASA configurations.

The general format of the NAT0 is the following

object network LAN

subnet

object network REMOTE-LAN

subnet

nat (inside,outside) source static LAN LAN destination static REMOTE-LAN REMOTE-LAN

Hope this helps

- Jouni

Hi Jouni,

Thanks for your help and reply.

I would like to send you the complete configuration of the ASA and the output of packet-tracer, i cannot find how to attach the file (could you tell how to attach a file or could you give me an email address where i can send it).

Actually, we do not know the architecture of the peer site, but they asked us to translate our LAN.

Please, let us know in case more information is needed.

please find below the output of packet tracer

packet-tracer input inside-1 tcp 10.6.1.131 12345 10.60.80.5 80

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside-1_access_in in interface inside-1

access-list inside-1_access_in extended permit object-group DM_INLINE_PROTOCOL_3 object Client1 object-group WEB_DEST

object-group protocol DM_INLINE_PROTOCOL_3

protocol-object ip

protocol-object icmp

object-group network WEB_DEST

group-object Conf_web_group

network-object object 172.24.0.191

network-object object 172.24.0.192

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside-1,outside) source static 10.6.1.0 NAT-WEB destination static Conf_web_group Conf_web_group

Additional Information:

Static translate 10.6.1.131/12345 to 172.24.2.2/12345

Phase: 8

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Result:

input-interface: inside-1

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Best Regards

Hi,

The "packet-tracer" shows the traffic matching this NAT rule

nat (inside-1,outside) source static 10.6.1.0 NAT-WEB destination static Conf_web_group Conf_web_group

Is that the correct NAT rule?

Atleast it next matches some VPN configuration but results in DROP.

Can you issue the same "packet-tracer" command twice and copy/paste the second output. The reason for this is that if the L2L VPN was down it would take the first "packet-tracer" command to get the negotiation going and the second "packet-tracer" command would go through normally IF the L2L VPN is configured correctly.

- Jouni

Hi Jouni,

Yes, that is the correct NAT rule.

Please, find below the second output of packet-tracer

packet-tracer input inside-1 tcp 10.6.1.131 12345 10.60.80.5 80

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside-1_access_in in interface inside-1

access-list inside-1_access_in extended permit object-group DM_INLINE_PROTOCOL_3 object Client1 object-group WEB_DEST

object-group protocol DM_INLINE_PROTOCOL_3

protocol-object ip

protocol-object icmp

object-group network WEB_DEST

group-object Conf_web_group

network-object object 172.24.0.191

network-object object 172.24.0.192

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside-1,outside) source static 10.6.1.0 NAT-WEB destination static Conf_web_group Conf_web_group

Additional Information:

Static translate 10.6.1.131/12345 to 172.24.2.2/12345

Phase: 7

Type: VPN

Subtype: encrypt

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 10

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 11

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 12

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 38084994, packet dispatched to next module

Result:

input-interface: inside-1

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

We also run the commande show crypto ipsec sa and this is the output.

sh cryp ips sa | beg 10.60.80

      access-list outside_cryptomap extended permit ip host 172.24.2.2 host 10.60.80.5

      local ident (addr/mask/prot/port): (172.24.2.2/255.255.255.255/0/0)

      remote ident (addr/mask/prot/port): (10.60.80.5/255.255.255.255/0/0)

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

      #pkts compressed: 0, #pkts decompressed: 0

      #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0

      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

      #send errors: 0, #recv errors: 0

Please, let us know the next step.

Best regards

Hi,

The "packet-tracer" test goes through and also some traffic seems to have been generated to the tunnel (perhaps ICMP?) but it doesnt seem to go through. The L2L VPN connection itself is fine since its up.

Test the actual connections through the L2L VPN. If you see the encaps/encrypt counter above increase then contact the remote site and ask them to confirm their firewall rules since they dont seem to be sending any traffic back. Its likely that your connections either arent allowed or the actual servers arent replying to the connection attempt. There is ofcourse always possible that there is some routing problem on the remote site so that the return traffic doesnt find its way back to the VPN device at the remote site.

- Jouni

Hi Jouni,

Thanks for your reply.

yes, we did the test with ICMP .

So, does it mean that in our side, there is no wrong configuration?

should we see output for 172.24.2.2 when we launch "sh xl"? we couldn't see eny ouptut for this IP.

okay, we will also ask the remote site and let you know.

Best Regards

Hi,

Since we see the output of "show crypto ipsec sa" that means the L2L VPN is up.

We see that we have sent traffic to the connection as we see encrypt/encaps statistics. Also as we see from the SA the local source is 172.24.2.2 which means the packets have gone with that IP address to the tunnel

You should probably see some translation for that though

You could try with the local IP address with the command

show xlate local

I would say there is some problems at the remote site as the L2L VPN is up but there is no return traffic for your connection. As you probably use this connection for something else than ICMP I would suggest testing with the actual services that you are going to use through the L2L VPN. For example in our cases we rarely allow ICMP traffic though every 3rd party seems to insist on using the ICMP/Traceroute as their means to test the connection.

- Jouni

Ok Jouni, thanks for this clear reply and the command .

we will ask the remote site and let you know.

best regards

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: