6

I've (finally) got a VPN tunnel to an AWS VPC up and running. I'm not a network engineer.

It works fine from the office to the VPC, but remote users cannot access anything through this site-to-site tunnel. Just to eliminate anything on the AWS side I've set a #1 ACL rule to allow all traffic and I have a test VM with a security group that allows all traffic.

All we really care about is office and remote (10.0.0.0/8) to VPC (172.17.0.0/16) traffic.

I'll try to post relevant config info, but let me know if you need more which I will gladly share. The only things I've redacted are the AWS tunnel IPs and our office's outside IP address:

access lists

ciscoasa(config)# show run access-list
access-list inside_nat0_outbound extended permit ip any 10.0.0.0 255.255.255.192 
access-list Split_Tunnel_List standard permit 10.0.0.0 255.255.255.0 
access-list Split_Tunnel_List standard permit 172.17.0.0 255.255.0.0 
access-list acl-amzn extended permit ip any 172.17.0.0 255.255.0.0 
access-list amzn-filter extended permit ip 172.17.0.0 255.255.0.0 10.0.0.0 255.0.0.0 
access-list amzn-filter extended deny ip any any 
access-list outside_access_in extended permit ip host AWS_TUNNEL_IP_1 host OFFICE_OUTSIDE_IP
access-list outside_access_in extended permit ip host AWS_TUNNEL_IP_2 host OFFICE_OUTSIDE_IP
ciscoasa(config)# 

group-policy

ciscoasa(config)# show run group-policy
group-policy RA_GROUP internal
group-policy RA_GROUP attributes
 dns-server value 8.8.8.8 8.8.4.4
 vpn-tunnel-protocol IPSec 
 split-tunnel-network-list value Split_Tunnel_List
group-policy filter internal
group-policy filter attributes
 vpn-filter value amzn-filter
ciscoasa(config)# 

crypto map

ciscoasa(config)# show run crypto map
crypto map outside_map 1 match address acl-amzn
crypto map outside_map 1 set pfs 
crypto map outside_map 1 set peer AWS_TUNNEL_IP_1 AWS_TUNNEL_IP_2 
crypto map outside_map 1 set transform-set transform-amzn
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
ciscoasa(config)# show run nat
nat (inside) 0 access-list acl-amzn
nat (inside) 1 0.0.0.0 0.0.0.0
nat (outside) 1 10.0.0.0 255.255.255.0
ciscoasa(config)#

same-security-traffic

ciscoasa(config)# show run same-security-traffic 
same-security-traffic permit intra-interface
ciscoasa(config)# 

ping from 10.0.0.15 to VPC works

ciscoasa(config)# packet-tracer input inside icmp 10.0.0.15 0 8 172.17.44.71      

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: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 3
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: NAT-EXEMPT
Subtype: 
Result: ALLOW
Config:
  match ip inside any outside 172.17.0.0 255.255.0.0
    NAT exempt
    translate_hits = 258, untranslate_hits = 104
Additional Information:

Phase: 5
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
  match ip inside any outside any
    dynamic translation to pool 1 (OFFICE_OUTSIDE_IP [Interface PAT])
    translate_hits = 9425616, untranslate_hits = 1313465
Additional Information:

Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
  match ip inside any inside any
    dynamic translation to pool 1 (No matching global)
    translate_hits = 0, untranslate_hits = 0
Additional Information:

Phase: 7
Type: HOST-LIMIT
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: ACCESS-LIST
Subtype: vpn-user
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 10392911, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

ciscoasa(config)# 

ping from office outside IP fails

ciscoasa(config)# packet-tracer input inside icmp OFFICE_OUTSIDE_IP 0 8 172.17.44.71 detailed 

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: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc959e0e0, priority=0, domain=inspect-ip-options, deny=true
    hits=9738259, user_data=0x0, cs_id=0x0, reverse, 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

Phase: 3
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc959dd58, priority=66, domain=inspect-icmp-error, deny=false
    hits=305383, user_data=0xc959dc40, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
    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

Phase: 4
Type: NAT-EXEMPT
Subtype: 
Result: ALLOW
Config:
  match ip inside any outside 172.17.0.0 255.255.0.0
    NAT exempt
    translate_hits = 259, untranslate_hits = 107
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc9603e48, priority=6, domain=nat-exempt, deny=false
    hits=271, user_data=0xca1792f8, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
    src ip=0.0.0.0, mask=0.0.0.0, port=0
    dst ip=172.17.0.0, mask=255.255.0.0, port=0, dscp=0x0

Phase: 5
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
  match ip inside any outside any
    dynamic translation to pool 1 (OFFICE_OUTSIDE_IP[Interface PAT])
    translate_hits = 9431076, untranslate_hits = 1314029
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc9620cf8, priority=1, domain=nat, deny=false
    hits=10741033, user_data=0xc9620c38, 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

Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
  match ip inside any inside any
    dynamic translation to pool 1 (No matching global)
    translate_hits = 0, untranslate_hits = 0
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc96208b8, priority=1, domain=host, deny=false
    hits=10681997, user_data=0xc9620538, cs_id=0x0, reverse, 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

Phase: 7
Type: HOST-LIMIT
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc95a1058, priority=0, domain=host-limit, deny=false
    hits=3610687, user_data=0x0, 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

Phase: 8
Type: ACCESS-LIST
Subtype: vpn-user
Result: DROP
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xca201808, priority=12, domain=vpn-user, deny=true
    hits=17, user_data=0xc793c300, filter_id=0x4(amzn-filter), 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

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

ciscoasa(config)# 

sysopt

ciscoasa(config)# show run all sysopt
no sysopt connection timewait
sysopt connection tcpmss 1387
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 inside
no sysopt noproxyarp outside
ciscoasa(config)# 

Turning on debug icmp trace and pinging from a remote connection yields nothing when I try to ping something through the site-to-site tunnel. When I try to ping something in the office LAN I get:

ICMP echo request from outside:10.0.0.19 to outside:10.0.1.34 ID=12 seq=0 len=8
ICMP echo request translating outside:10.0.0.19/12 to outside:OFFICE_OUTSIDE_IP/47077

10.0.0.19 is the remote connection's IP address.

From the office LAN I can successfully ping AWS VMs through the site-to-site tunnel but the pings fail if done directly from the ASA 5505.

I don't know if this is normal behavior but to my untrained eyes it looks like the remote connection is being treated as an outside connection. I would have assumed if you're connected via the VPN you'd be considered inside.

Here's the route table when connected remotely minus the IPv6 section(produced by netstat -nr on a macbook):

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            link#12            UCS            16        0   utun1
default            10.128.128.128     UGScI          16        0     en0
8.8.8.8            link#12            UHWIi           6       41   utun1
10                 link#4             UCS             1        0     en0
10.0.0.19          10.0.0.19          UH              0       11   utun1
10.128.128.128/32  link#4             UCS             1        0     en0
10.128.128.128     0:18:a:34:c7:94    UHLWIir        19       89     en0   1198
10.243.58.109/32   link#4             UCS             0        0     en0
10.255.255.255     ff:ff:ff:ff:ff:ff  UHLWbI          0        3     en0
17.146.233.11      link#12            UHW3I           0        5   utun1     10
17.158.28.36       link#12            UHWIi           2       10   utun1
17.171.4.15        link#12            UHWIi           1        1   utun1
17.172.224.14      link#12            UHWIi           1        3   utun1
17.172.232.134     link#12            UHWIi           1       23   utun1
17.173.254.222     link#12            UHW3I           0        9   utun1      9
17.173.254.223     link#12            UHW3I           0        4   utun1      9
23.211.232.189     link#12            UHW3I           0       17   utun1      7
23.212.21.149      link#12            UHWIi           1        4   utun1
74.125.25.188      link#12            UHWIi           1       14   utun1
74.125.28.125      link#12            UHWIi           1       71   utun1
74.125.239.17      link#12            UHWIi           1       18   utun1
74.125.239.181     link#12            UHWIi           1       19   utun1
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              1    39007     lo0
169.254            link#4             UCS             0        0     en0
OFFICE_OUTSIDE_IP  10.128.128.128     UGHS            3        1     en0
OFFICE_OUTSIDE_IP  link#12            UHW3I           0        3   utun1      6
224.0.0.251        link#12            UHmW3I          0        0   utun1     10

A cleaner route table from my home linux box connected to the VPN:

$ route -n
Kernel IP routing table
Destination       Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0           0.0.0.0         0.0.0.0         U     0      0        0 tun0
10.0.0.0          0.0.0.0         255.255.255.0   U     0      0        0 tun0
OFFICE_OUTSIDE_IP 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
192.168.1.0       0.0.0.0         255.255.255.0   U     1      0        0 eth0

As an experiment (AKA grasping at straws) I added the OFFICE_OUTSIDE_IP to the amazon-filter access list:

access-list amzn-filter extended permit ip 172.17.0.0 255.255.0.0 10.0.0.0 255.0.0.0 
access-list amzn-filter extended permit ip 172.17.0.0 255.255.0.0 host OFFICE_OUTSIDE_IP 
access-list amzn-filter extended deny ip any any 

With that in place, and debug icmp trace I can see ping attempts from remote connections, but the pings still fail:

ICMP echo request from outside:10.0.0.19 to outside:172.17.44.71 ID=22350 seq=2 len=56
ICMP echo request translating outside:10.0.0.19/22350 to outside:OFFICE_OUTSIDE_IP/8998

The current running config is here. Anything that I edited in the configuration should be pretty obvious. The address spaces are messy due to what I inherited. I do hope to clean that up in the future.

4

Got a response on the cisco forums that solved my problem.

you are missing NAT exempt from the IP local pool to the destination of the site to site:

access-list NAT_EXEMPT permit ip 10.0.0.0 255.255.255.0 172.17.0.0 255.255.0.0

NAT (outside) 0 access-list NAT_EXEMPT
1

I think your vpn-filter is causing an issue and isn't necessary. Try removing it by doing clear config group-policy filter.

Check that you have this setting turned on: sysopt connection permit-vpn by doing show run all sysopt. When that is on, all of the VPN traffic will bypass the interface ACL and you won't have a need for the VPN-Filter.

  • Removed the group-policy filter, but the results are exactly the same. The permit-vpn setting is on. I'll add the output of show run all sysopt to the original post. – pmac72 Oct 20 '14 at 13:53
1
access-list amzn-filter extended permit ip 172.17.0.0 255.255.0.0 10.0.0.0 255.0.0.0 
access-list amzn-filter extended deny ip any any 

Unless your "remote" users are contained in the 10.0.0.0/8 network, your filter is missing their IP range. From what I gather of your output, there is AWS (172.17.0.0/16), your Office (10.0.0.0/8), and the "Remote" network. You never provided the IP Range, so I can't know for sure.

Regarding your second packet-tracer output. It seems you are trying to ping from your Inside interface using the source address of your Outside interface. I'm pretty sure that will always fail, as your Outside interface IP is (more than likely) not in the range of IPs you are allowing in your Encryption Domain.

  • The remote users get a 10.0.0.0/8 address and they appear to the world as if they are inside the office, which is why I had the 2nd packet trace like that. So should I add the OFFICE_OUTSIDE_IP to the amzn-filter access-list? – pmac72 Oct 20 '14 at 17:01
  • Turn on warning level debugging, and send some pings from the Remote VPN. See what log messages you receive, they might provide a clue for why the Firewall is dropping the packets (or even IF the firewall is receiving the traffic). Turn on debug icmp trace while doing this, so you can determine for sure whether the Firewall is receiving the packet, and/or whether the Firewall is sending the packet elsewhere. – Eddie Oct 20 '14 at 20:13
  • Thank you for your response. I've added the results to the original post for better formatting. – pmac72 Oct 21 '14 at 15:23
  • It seems that tells you where the problem is. Remote VPN users aren't sending the traffic to your firewall when they attempt to ping the AWS ip addresses. You would have seen their packet in the debug icmp trace if they were. Make sure your clients are getting the route for 172.17.0.0\16 when they connect to the VPN. – Eddie Oct 21 '14 at 18:34
  • I appreciate your help. As an ASA neophyte, how would I configure this? My googling let me to route inside 0 0 "internet firewall IP address" tunneled. Does this seem reasonable? I can't test it until after hours. – pmac72 Oct 21 '14 at 20:24
1

Assuming you have something to the likes of:

[ 10.0.0.0/8 nets ] --- [ router ] --- [ asa ] ---> [ internet ]

You can try something like the below. Note the config isn't complete, meaning it doesn't allow Internet access for example. If you post your full config, we could provide a little more help. Just redact anything sensitive like you've been doing (passwords, PSK's, outside IP's, etc. etc.)

!
!
!
interface Ethernet0/0
 description to internet
 nameif outside
 security-level 0
 ip address 1.1.1.2 255.255.255.252
!
interface Ethernet0/1
 description to router
 nameif inside
 security-level 100
 ip address 10.10.10.252 255.255.255.252
!
!
!
object-group protocol PROTOCOLS_ALL
 protocol-object ip
 protocol-object icmp
!
object-group network GRP_AWS_NET
 network-object 172.17.0.0 255.225.0.0
!
object-group network GRP_LOCAL_NETS
 network-object 10.0.0.0 255.0.0.0
!
!
!
access-list acl-amzn extended permit ip object-group GRP_LOCAL_NETS object-group GRP_AWS_NET
access-list inside_access_in extended permit object-group PROTOCOLS_ALL object-group GRP_LOCAL_NETS object-group GRP_AWS_NET
access-list inside_access_in extended permit object-group PROTOCOLS_ALL object-group GRP_AWS_NET any
!
!
!
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
!
!
!
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
route inside 10.0.0.0 255.0.0.0 10.10.10.251
!
!
!
global (outside) 1 interface
nat (inside) 0 access-list acl-amzn
nat (inside) 1 10.0.0.0 255.0.0.0
!
!
!
crypto map outside_map 1 match address acl-amzn
crypto map outside_map 1 set pfs
crypto map outside_map 1 set connection-type originate-only
crypto map outside_map 1 set peer <YOUR_AMZN_IP_1> <YOUR_AMZN_IP_2>
crypto map outside_map 1 set transform-set transform-amzn
crypto map outside_map 1 set nat-t-disable ! <--- this may help you. give it a try.
crypto map outside_map interface outside
!
!
!
tunnel-group <YOUR_AMZN_IP_1> type ipsec-l2l
tunnel-group <YOUR_AMZN_IP_1> ipsec-attributes
 pre-shared-key  SOME_PRESHARED_KEY
!
tunnel-group <YOUR_AMZN_IP_2> type ipsec-l2l
tunnel-group <YOUR_AMZN_IP_2> ipsec-attributes
 pre-shared-key  SOME_PRESHARED_KEY
!
!
!
  • Thanks. This is a working set up, so I can't be too experimental during business hours. I did try the crypto map outside_map 1 set nat-t-disable with no observable difference. I've not posted the full config because I'm such a cisco novice I'm not even 100% sure what is and is not sensitive information. I'll take a crack at it and post it later today. – pmac72 Oct 23 '14 at 16:07
  • OK here's the current running config. – pmac72 Oct 23 '14 at 16:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.