IPSEC - Cisco - crypto map which interface?

Hello Experts!
    I have to set up an IPSEC tunnel with a 1841 router. (The other party is also a Cisco, but I don't administer it). However, following the tutorials, I cannot bring up the tunnel. The other site is configured perfectly, as it was demonstrated apparently.

    The only unusual thing with my network (I suppose) is that on the ISP side we don't use a public IP subnet, instead, we use a 192.168.x.x/30 local subnet. The IPSEC  tutorials suggest to apply the
"crypto map"
 to the outer interface (Fa0/1), but that interface has no public address to bring up the tunnel.

|-------| remote                                                                                                                    a.b.c.109
|         | IPSEC peer  ------ INTERNET...                                                   |----------------------|
|-------| (public IP)                             ISP ------------------------------------ |      1841              |
                                                         192.168.x.1               192.168.x.2|                            |-------
                                                                                                           Fa0/1                     Fa0/0

                                                                                                                                   ... Company...

Our company public address range is the  --- a.b.c.96/27
a.b.c.126 is the company default gateway address (1841), and
a.b.c.109 is also an address of the 1841 which I want to use as the IPSEC peer address.

Is it possible to setup the IPSEC tunnel? I would appreciate any help.
Who is Participating?
using crypto map mymap local-address l0 (or whatever loopback interface you choose) should work as kelle stated, however this is going to require you to subnet your/27 public ip space and make a potential mess of your publically assigned address space.

Rather than a single /27 on the inside interface, you would have to break it down into a /28, a /29, and /30 and waste some IP addresses in the process as you would need to break off a /30 for use on the loopback interface.

I still strongly believe that the best solution is to get your ISP to renumber your "uplink" interface with a publically routable /30 subnet.
There is a small chance you may be able to terminate the tunnel on the inside interface of your 1841 router, but I highly doubt it.

You are most likely going to need to request that your ISP assign you a publically routable /30 IP subnet to use between their edge router and yours.  You should probably consider doing this anyway.
exxqltAuthor Commented:
What about the fairly complex
- reverse-route ...
- reverse-route remote-peer ...
keywords in the crypto map? Wouldn't it help?

Or what about to assign my public IPSEC peer address (a.b.c.109) to the outer interface (as a primary or secondary)?

Anyway... If I made the changes with the ISP and we would use a publicly routable /30 subnet between us...
Should I have to propagate that address as my IPSEC peer, or could I use my
a.b.c.109 on the outer interface (as a primary or secondary again)?
On-Demand: Securing Your Wi-Fi for Summer Travel

Traveling this summer?Check out our on-demand webinar to learn about the importance of Wi-Fi security and 3 easy measures you can start taking immediately to protect your private data while using public Wi-Fi. Follow us today to learn more!

The quick-fix is to implement EzVPN, but this requires a configuration-change on the remote end. With EzVPN you router will act as a software vpn client, and doesn't need a public IP as long as UDP ports 500 and 4500 (default) towards the internet.
Here is a link which describes how to configure it.


If the remote end is is a ASA firewall instead of a router, the configuration is similar:


I'm a bit unsure what you mean about assigning your public IPSEC peer address to the outside interface.  If you a.b.c.109 on the outside interface, you would be unable to use the IPs from the same subnet on the inside interface. Plus if you are going to move a public subnet to the outside interface, you may as well assign a /30 and use it to connect to your ISPs network.

reverse-route etc will not work because the peer address on the remote router will still be RFC1918 space.  Because of this there would be no route to get the traffic delivered to you to terminate the VPN.

As Kelle pointed out, if you do not want to change to /30 public subnet for connecting to your ISP, you can attempt to use ezVPN if the other party is willing to update their configuration.  However, I am actually unsure if this will even work.  while ezVPN does function as a VPN client, it is still going to be sending the 192.168.x.x as the originating IP which still may prevent the remote router from being able to communicate back to your router.  Normally when a VPN client is connecting from private IP space is it NAT'd somewhere and the remote router sees the public IP used for the NAT translation to direct return traffic for the VPN tunnel to.  In your situation, I'm still unsure how the return traffic would reach you, although, I admittedly do not use ezVPN too often and am probably not as familiar with its capabilities as much as Kelle who appears to have used it previously.
I assume that you actually have internet access through your provider, and therefore NAT does take places somewhere in their network. EzVPN has no problem with NAT'tet traffic. The only prereq is that ISAKMP NAT-traversal is enabled on the remote end. It is enabled by default except on old 7.x ASA firmware.
Hi Kelle,

That is what I do not believe in the case based on what the way he documented the network.  My assumption was that the ISP was/is using the RFC1918 /30 to statically route Exx's public IP address to him.  I do not see how that interface traffic could be NAT'd given that Exx uses his public IP space on his internal interface.

Using a private /30 to route the public ip space is not a very good design which is why I suggested changing to the /30 public subnet even if other options worked.  However, if you are not looking to terminate any traffic on the outside interface (such as a VPN for example), then using the private /30 works fine as far as pure routing is concerned with traffic reaching its destination.

This why I do not really see any alternative to changing to a public /30, even if he wanted to use ezVPN.
Sorry, missed the part about the public IP's behind the private net. I agree that is a strange approach on the ISP's behalf.
Another possible solution is to add a public IP to a loopback interface on the router.
You still put the crypto map on the outside interface, but also issue the "crypto map mymap local-address" and use the loopback interface as source IP.
I've never tried this, but in theory it should work.
exxqltAuthor Commented:
Guys, thank you for your efforts in finding the solution to my problem. I will return today still to this topic. Which I can say at the moment is that we can't change the technology, so I'm afraid ezVPN is not an alternative for me.
Secondly: our a.b.c.96/27 is an ordinary public-access subnet, no NATting anywhere, even not at the ISP, despite of the 192.168.x.3/30 connection.

Regards Exxqlt
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
I've requested that this question be deleted for the following reason:

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
exxqltAuthor Commented:
I had some difficulties with the credit card payment.
However it has been passed, my account is valid again.
exxqltAuthor Commented:
I think the 192.168.x.x uplink is an elegant method. But it seems me that  the IPSEC logic forces me to change. So Ihave started the changing process. Thank you for your help.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.