cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
453
Views
5
Helpful
7
Replies

Tunnelled clients can't see internet via ASA hub

Group IT
Level 1
Level 1

Greetings all,

Please may I share an issue with you regarding IPsec tunnel between an 1841 router (spoke) and an ASA5505 (hub)? This is our first venture with secure tunnels so we've gotten into a complete mess trying to follow all the different (most out-dated) guides out there.

  • ASA (Hub):
    Static pubic IP: 81.136.123.123
    Inside IP: 192.168.0.250
    Clients: 192.168.0.0/24
    ASA Version v9.2(4)
    There is a test DC/DNS/DHCP Windows server at 192.168.0.11

  • 1841 (Spoke):
    Dynamic public IP
    Inside IP: 192.168.99.254
    Clients: 192.168.99.0/24


We have successfully got clients on the spoke network (192.168.99.0/24) to be able to RDP/ping to clients on the hub network. So we're for most the part there.

We have two big issues though.

  1. The speed/latency between clients over the tunnel is almost unworkable.
  2. Clients on the spoke network are unable to access the internet (served via the ASA).

I would like to focus on the second issue for now. We are trying to achieve a full tunnel, where all WWW traffic goes down the pipe to the ASA from spoke clients.

As it stands, if I try to ping 8.8.8.8 or browse the web from a 192.168.99.0/24 client the request just times out.

The spoke clients have the spoke router (192.168.99.254) as their gateway. The spoke router has the outside interface as the "ip route 0.0.0.0 0.0.0.0" destination.
From what I can understand the ASA accepts all traffic from the tunnelled IP's. But what to do from here?

I am attaching the configs of our ASA and router in the hope that someone has time to look over them and perhaps point out the error of our ways!

Thank you very much for your time.

Regards,

Elliot

1 Accepted Solution

Accepted Solutions

I would start by pointing out a weakness in your router config which is your static default route

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

It is not good to have a static route point just to the outbound interface when that interface is Ethernet. I do not think this causes your issue but I believe that it is something that you should address.

When I read the original post and saw that the problem was hosts at the remote site not able to access Internet when going through a site to site VPN my first thought was that it might be an issue with same security level intra interface. But I am glad to see that you do have this in your config. So that is not the issue (I comment on it because it is so common an issue).

I believe that your issue is that when hosts from the remote site attempt to access the Internet that there is no address translation for this traffic. Fix that and let us know if it starts to work.

HTH

Rick

HTH

Rick

View solution in original post

7 Replies 7

Group IT
Level 1
Level 1

Oh, also, since this gets asked frequently on queries of this nature, here some "show" output which may be useful:

rtr-h000355#sh cry session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 81.136.123.123 port 4500
IKE SA: local 82.42.123.123/4500 remote 81.136.123.123/4500 Active
IPSEC FLOW: permit ip 192.168.99.0/255.255.255.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

Interface: FastEthernet0/0
Session status: DOWN
Peer: 81.136.123.123 port 500
IPSEC FLOW: permit 1 192.168.99.0/255.255.255.0 0.0.0.0/0.0.0.0
Active SAs: 0, origin: crypto map

rtr-h000355#sh cry isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
1 82.42.123.123 81.136.123.123 ACTIVE aes sha psk 2 23:02:13 N
Connection-id:Engine-id = 1:2(hardware)

I would start by pointing out a weakness in your router config which is your static default route

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

It is not good to have a static route point just to the outbound interface when that interface is Ethernet. I do not think this causes your issue but I believe that it is something that you should address.

When I read the original post and saw that the problem was hosts at the remote site not able to access Internet when going through a site to site VPN my first thought was that it might be an issue with same security level intra interface. But I am glad to see that you do have this in your config. So that is not the issue (I comment on it because it is so common an issue).

I believe that your issue is that when hosts from the remote site attempt to access the Internet that there is no address translation for this traffic. Fix that and let us know if it starts to work.

HTH

Rick

HTH

Rick

Hi Richard,

Thank you very much for your reply.

First things first. The "ip route 0.0.0.0" I have was based on another guide for configuring Cisco routers with dynamic outside IPs. Can you recommend how I should change this route if the next hop is dynamic?

As per your suggestion that my overall problem it's likely a NAT issue, I will have a look now but I tend to get in a mess with NAT rules, so any pointers would be great! :)

Thank you very much for your time and advice.

Best Regards,

Elliot

Hi Richard,

I managed to get a NAT rule working:

nat (BTInfinity,BTInfinity) source dynamic HomeNetwork-EJ interface

I can ping 8.8.8.8 and browse the web from the client devices, so looking good!

Please let me know if the rule looks okay to you :)

Best Regards,

Elliot

Elliot

I am glad that you got the NAT rule worked out. The rule looks fine to me.

As far as the static default route is concerned I would be vaguely interested in knowing which one is was (and possibly how old it is). But ultimately it does not matter where the suggestion came from and does matter that you understand the issue. So let me explain a few things.

- it is not always a bad choice to configure a static route that points only to the outbound interface. If the outbound interface is a true point to point (perhaps HDLC, or PPP, or Frame Relay point to point) then it would be fine to configure

ip route 0.0.0.0 0.0.0.0 serial 0

- but when the outbound interface is Ethernet then there are multiple issues with it

-- it requires the router to arp for every destination address that it forwards

-- it only works if the next hop router enables proxy arp. Increasingly many ISP and many organizations see proxy arp as a security issue and do not enable it.

-- this arp activity increases traffic on the network, increases cpu utilization of the router.

-- this arp activity results in a larger arp table which consumes memory

-- every entry in the arp table must be refreshed every 4 hours (by default) which results in more traffic on the network and more cpu utilization.

Normally the suggestion is to configure the static route and specify the next hop address. But in your situation you may not know the next hop address since it is using DHCP. So my suggestion would be to use this

ip route 0.0.0.0 0.0.0.0 dhcp

HTH

Rick

HTH

Rick

Hi Rick,

Yes, you are correct, my situation is indeed that I do not know what my next hop is going to be as the setup I am experimenting with at the moment is on a domestic dynamic public IP.

The original IP route command I was using is from an online guide (or forum post) I followed when I was originally trying to setup a Cisco ADSL router to replace a domestic ISP-supplied piece of junk :) So I assumed it was correct... until now :D It's going back a number of years though, so I'm afraid I have no reference for it now.

I tried swapping out my ip route statement with your suggestion, and it all seems fine, so thank you once again for your advice!

Best Regards,

Elliot

Elliot

Thanks for the additional information. If the suggested static route came from a discussion focused on ADSL then the chances are good that it was being applied on some type of point to point connection, and that would not have the same issues as doing it on an Ethernet interface. And like I said it matters less where the example came from and matters more that you understand the potential impact in your current config. I am glad that you swapped the ip route statements and that the results are working fine.

HTH

Rick

HTH

Rick
Review Cisco Networking products for a $25 gift card