11-12-2013 10:38 PM - edited 03-11-2019 08:04 PM
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?
11-13-2013 02:02 AM
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
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
11-13-2013 05:14 AM
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
11-13-2013 06:42 AM
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
11-14-2013 12:28 AM
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
11-14-2013 01:39 AM
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
11-14-2013 05:32 AM
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
11-14-2013 05:57 AM
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
11-14-2013 06:25 AM
Ok Jouni, thanks for this clear reply and the command .
we will ask the remote site and let you know.
best regards
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: