Forcing remote internet traffic through its IPSec VPN to HQ

[MichelleS]

We have a Cisco 881 at a remote site with an IPSEC VPN successfully routing traffic between this site and our HQ networks but as soon as we attempt to access internet from the remote site it fails. We'd like to route all traffic from this remote subnet through HQ to the internet. I've tried adding "permit ip <remote_subnet> 0.0.0.255 any" to the access list which is linked to the crypto map profile for the VPN but after clear crypto ikev2 command our HQ end keeps attempting to negotiate and fails with an error about proxy ID. cannot find matching phase-2 tunnel for received proxy ID. received local id: 0.0.0.0/0 type IPv4_subnet protocol 0 port 0, received remote id: <remote_subnet>/24 type IPv4_subnet protocol 0 port 0.' 

Can anyone tell me what's up with the config please? 

[balaji.bandi]

If you like to send all the Traffic to HQ for Internet you need fllow below stes - high level.

You need to have basic IPSEC tunnel running - for your Local network to send to HQ - you need to add local IP address towards tunnel interface as example

ip route x.x.x.x  255.255.255.0 Tunnel0 ( exmaple change tunnel interface name)

On the HQ, you need to have NAT / ACL for this to go to internet

Other Options - you can have split-tunnel for Internet Local breakout only send traffic to HQ related stuff

[Richard Burts]

The original post contains a partial config for one device with several aspects that make it difficult to understand what is going on:

- first and most important, all IP addresses are blanked out, including several that logically would be private addresses. I can understand wanting to obscure public IP addresses. But blanking out every address prevents us from understanding the relationships.

- the static default route shown in the config does not indicate a next hop but only has the indication "Internet". What does this mean?

- there are 2 crypto map entries shown (TS 10 and TM 10). And they both reference the same crypto access list. How are we to understand this? Which one is the one being used for the HQ? I really have doubts that this would work successfully.

- (while I do not believe it is related to the issue about vpn I find this  needs to be identified) the access list applied on the outside interface contains a statement to permit icmp any any followed by a statement to deny icmp any any. Since the deny icmp any any is the only deny in the acl, and since it will not work because icmp any any is already permitted, then this whole access list is meaningless and might as well be removed.

The other point I would make is that we have seen only one side of the vpn. For the change at the remote side to be effective to send all of its traffic over the vpn there must be a similar change to the HQ side to accept all traffic from this peer (not just the lan traffic from this peer). We have not been provided any information about the HQ side and I wonder if that is where the issue is.

[MichelleS]

Oh man, I had an entire response addressing each of your findings Rick but it failed to submit and I lost it so here it goes again. I really appreciate your attention to detail here. So just want to say thank you for starters!

Private IP related config:

interface Vlan1
description LAN network
ip address 10.10.20.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip tcp adjust-mss 1360

ip access-list extended VPN-ACL
permit ip 10.10.20.0 0.0.0.255 10.10.0.0 0.0.0.255

(*this is where I added an entry which caused proxy ID errors)

TS 10 used:

crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac
mode tunnel

Static route - "Internet" would've been better ID'd as FastEth4 next hop in hindsight 

I realize the STOP PING is void atm but it is only this way so it won't get in the way while testing. It stands out out like a sore thumb so I won't forget to change it back. 

The HQ side is a Palo firewall so if I can get internet traffic tunneling over the VPN I had hoped to see that traffic in the logs and deal with it then. I am much more familiar with the Palo than Cisco. 

[MichelleS · Accepted solution]

Managed to work this out. Added an extra line to the ACL to permit remote client subnet to any. This caused the HQ end to report an issue with the proxy ID. On HQ end I configured an additional proxy ID within the tunnel config and the VPN was then able to reconnect and commence tunneling internet traffic through HQ.  

[Richard Burts]

Thanks for the update. Glad to hear that you got it worked out. Congratulations on finding your own solution.