cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1611
Views
0
Helpful
12
Replies

Can't pass traffic from VPN client to remote site-to-site VPN

Erik Jacobsen
Level 1
Level 1

Hi,

I can not get the traffic to flow between my VPN clients and one of my remote site-to-site vpns, I have done step by step in this link:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008046f307.shtml

my firewall is saying the packet is dropped by statefull inspection.

But that should be "same-security-traffic......" command there should fix this

%ASA-6-302020: Built inbound ICMP connection for faddr 10.45.231.163/1 gaddr 10.48.100.2/0 laddr 10.48.100.2/0 (nworks)


%ASA-6-302020: Built outbound ICMP connection for faddr 10.48.100.2/0 gaddr 10.45.231.163/1 laddr 10.45.231.163/1

%ASA-6-302021: Teardown ICMP connection for faddr 10.45.231.163/1 gaddr 10.48.100.2/0 laddr 10.48.100.2/0 (nworks)


%ASA-6-302021: Teardown ICMP connection for faddr 10.48.100.2/0 gaddr 10.45.231.163/1 laddr 10.45.231.163/1

Is there anything you could think of that I'm missing?

Best regards,

Erik

1 Accepted Solution

Accepted Solutions

Erik,

Please check it out because no decaps means the ASA is not receiving anything back from the other side through the tunnel.

If you send traffic and you see the encrypts increment... but nothing back... 99% sure the problem is on the other end.

Federico.

View solution in original post

12 Replies 12

Hi,

You want to send the traffic from a VPN client through the site-to-site correct?

The same-security-traffic.. should take care of the u-turn...

You also need to check that NAT (or no-NAT) is configured correctly.

Which OS version is the ASA running?

Are you positive that the Site-to-Site LAN is included in the split-tunneling for the VPN clients and that the VPN range is include in the Site-to-Site interesting traffic?

Federico.

Here is everything I have configured, so fare for this.

The Client vpn tunnel is working fine to the internal network

The site-to-site is working fine to all internal networks on 10.45.0.0 /16

It is only 10.45.231.0/24 there is not working.

crypto tunnel to site-to-site tunnel

access-list outside_2_cryptomap extended permit ip 10.45.0.0 255.255.0.0 10.48.100.0 255.255.252.0

No nat

nat (inside) 0 access-list inside_nat0_outbound
access-list inside_nat0_outbound extended permit ip 10.45.0.0 255.255.0.0 10.48.100.0 255.255.252.0

access-list inside_nat0_outbound extended permit ip any 10.45.231.0 255.255.255.0

VPN poop for VPN clients:

ip local pool VPN 10.45.231.1-10.45.231.128 mask 255.255.255.0

group-policy home internal
group-policy home attributes
wins-server value 10.45.254.4 10.45.254.71
dns-server value 10.45.254.4 10.45.254.71
dhcp-network-scope 10.45.231.0
vpn-tunnel-protocol IPSec svc
split-tunnel-policy tunnelspecified
split-tunnel-network-list value clients-polen

split-tunneling:

access-list clients-polen standard permit10.45.0.0 255.255.0.0
access-list clients-polen standard permit 10.48.100.0 255.255.252.0

Best regards,

Erik Jacobsen

Erik Jacobsen
Level 1
Level 1

Sorry forgot to add this to the tred.

This is also configured.

same-security-traffic permit intra-interface

Erik

Can you include:

sh run nat

To make sure there's no NAT being done on the outside interface.

Also, please check the ''sh asp drop'' when trying to access the 10.48.100.x from the VPN clients to see if the ASA reports any encryption problems.

What should happen is the following:

The VPN clients (10.45.231.0/25) traffic should be received by the ASA and redirected back-out the same interface via the Site-to-Site.

The configuration seems fine.

Check the following and also do this:

packet-tracer input outside icmp 8 0 10.45.231.1 10.48.100.1 det

This will let the ASA report if any process is conflicting with this connection.

Federico.

ASAfirewall# sh run nat

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 10.45.0.0 255.255.0.0

ASAfirewall# sh asp drop

Frame drop:
  Flow is denied by configured rule (acl-drop)                                63
  NAT-T keepalive message (natt-keepalive)                                    12
  TCP RST/FIN out of order (tcp-rstfin-ooo)                                    3
  FP L2 rule drop (l2_acl)                                                     1

Last clearing: 15:50:17 GMT+1 Nov 11 2010 by enable_15

Flow drop:
  NAT failed (nat-failed)                                                     34

Last clearing: 15:50:17 GMT+1 Nov 11 2010 by enable_15
ASAfirewall#

ASAfirewall# packet-tracer input outside icmp 10.45.231.160 8 0 10.48.100.2 det

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in  id=0xd7b88b58, priority=1, domain=permit, deny=false
        hits=155445, user_data=0x0, cs_id=0x0, l3_type=0x8
        src mac=0000.0000.0000, mask=0000.0000.0000
        dst mac=0000.0000.0000, mask=0100.0000.0000

Phase: 2
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in  id=0xd7de0560, priority=11, domain=permit, deny=true
        hits=7, user_data=0x5, cs_id=0x0, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Result:
input-interface: outside
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

ASAfirewall#

Here is the version:  System image file is "disk0:/asa822-k8.bin"

Erik

It seems the flow is being denied by the ACL.

Please post:

sh run access-group

This means there must be an ACL applied to the outside interface that is denying the traffic.

Do this also:

sh run all sysopt

Check that:

sysopt connection permit-ipsec or sysopt connection permit-vpn

is showing in the configuration.

Federico.

ASAfirewall# sh run all sysopt
no sysopt connection timewait
sysopt connection tcpmss 1380
sysopt connection tcpmss minimum 0
sysopt connection permit-vpn
sysopt connection reclassify-vpn
no sysopt connection preserve-vpn-flows
no sysopt nodnsalias inbound
no sysopt nodnsalias outbound
no sysopt radius ignore-secret
no sysopt noproxyarp outside
no sysopt noproxyarp inside
no sysopt noproxyarp Guest-lan
no sysopt noproxyarp WEB-dmz
no sysopt noproxyarp Radiator
no sysopt noproxyarp management

And yes there is a access-list on the outside, but I can not see what that have to do with anything, since VPN tunnels bypass the interface access-lists

ASAfirewall# sh run access-group
access-group ipsec in interface outside

There is a few static nat to internal servers, there have to be open for from the outside.

Erik

Perhaps the packet-tracer result is not accurate because the ASA sees this traffic coming from the outside and it thinks it will be denied by the ACL (when truly is coming via an IPsec tunnel).

Anyway...

Can you check if there's an IPsec SA being built for traffic between the VPN client and the remote Site-to-Site LAN?

When you connect the VPN client and try to access the remote LAN, check the ''sh cry ips sa'' and check if for the VPN tunnel there's an IPsec SA for getting to the remote site.

This will show us if the ASA is encrypting this traffic.

Federico.

now there is not that many on, the it actually look like there is a problem at the remote site-to-site

Because when I look at second there is opening the connection to the remote site-to-site, there is no decaps packet.

My ip address is "10.45.231.162" vpn client

Remote site-to-site is 10.48.100.2

  Crypto map tag: SYSTEM_DEFAULT_CRYPTO_MAP, seq num: 65535, local addr: 80.167.237.203

      local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (10.45.231.162/255.255.255.255/0/0)
      current_peer: 87.59.133.103, username: nworks
      dynamic allocated peer ip: 10.45.231.162

      #pkts encaps: 363, #pkts encrypt: 377, #pkts digest: 377
      #pkts decaps: 381, #pkts decrypt: 381, #pkts verify: 381
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 377, #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

      local crypto endpt.: 80.167.237.203/4500, remote crypto endpt.: 87.59.133.103/59789
      path mtu 1500, ipsec overhead 82, media mtu 1500
      current outbound spi: 48D63AF3
      current inbound spi : 7B41C78A

    inbound esp sas:
      spi: 0x7B41C78A (2067908490)
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={RA, Tunnel,  NAT-T-Encaps, }
         slot: 0, conn_id: 102400, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP
         sa timing: remaining key lifetime (sec): 28735
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0x48D63AF3 (1221999347)
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={RA, Tunnel,  NAT-T-Encaps, }
         slot: 0, conn_id: 102400, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP
         sa timing: remaining key lifetime (sec): 28699
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

    Crypto map tag: outside_map, seq num: 2, local addr: 80.167.237.203

      access-list outside_2_cryptomap extended permit ip 10.45.0.0 255.255.0.0 10.48.100.0 255.255.252.0
      local ident (addr/mask/prot/port): (Ista-net/255.255.0.0/0/0)
      remote ident (addr/mask/prot/port): (10.48.100.0/255.255.252.0/0/0)
      current_peer: 91.213.156.24

      #pkts encaps: 6, #pkts encrypt: 6, #pkts digest: 6
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 6, #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

      local crypto endpt.: 80.167.237.203, remote crypto endpt.: 91.213.156.24

      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: 49839E35
      current inbound spi : 28373C87

    inbound esp sas:
      spi: 0x28373C87 (674708615)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 5, }
         slot: 0, conn_id: 8192, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3915000/28408)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0x49839E35 (1233362485)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 5, }
         slot: 0, conn_id: 8192, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3914999/28408)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

there is only one problem, I don't control the other end of the site-to-site VPN tunnel, so I have just written to them and get them to confirm that the tunnel is setup correctly.

I'm just pretty sure that we already have tested some other nets on 10.45.x.x.

But just to be sure. Because it does not really make sense.

Erik

Erik,

Please check it out because no decaps means the ASA is not receiving anything back from the other side through the tunnel.

If you send traffic and you see the encrypts increment... but nothing back... 99% sure the problem is on the other end.

Federico.