IPSec VPN with Public IP on end and other side Private WAN Address

[ittechk4u1]

Hello Experts,

I am trying to establish a Site-to-Site IPSec VPN between Plant A and Plant B.

Plant A: is feting private IP(192.168.1.2) from LTE/Vodafone router

Plant B: is directly connected to ISU and getting a public IP (88.xxx.21.xxx)

Is there any method to make this setup working ? Please provide me the sample config .

Thanks in advance.

[Giuseppe Larosa]

Hello,

the provided output shows that traffic is going over the LAN to LAN IPsec tunnel in both directions from the point of view of the Spoke router.

Be aware that using a VRF on the HUB is supported only if also internal interfaces will be in a VRF otherwise it will not be possible.

Remember the limitation about FVRF and IVRF some posts ago.

on the HUB you need to find the public IP address used by the Spoke if you have it you should be able to use

show crypto ipsec sa <Spoke-Public-address>

Note: You can use show crypto isakmp sa to find out the public address used by the Spoke

2) the ACL hits can increment or not depending on the platform you need to verify the counters on show crypto ipsec sa

However, if on Spoke router both rx and tx counters are incrementing you know that the LAN to LAN IPSec VPN is working.

Are the test pings with correct source IP address working now ?

Hope to help

Giuseppe

[ittechk4u1]

No ping is not working.

Spoke#ping 10.18.2.4 so loop0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.18.2.4, timeout is 2 seconds:
Packet sent with a source address of 10.99.0.1
.....
Success rate is 0 percent (0/5)

!

Spoke#ping 10.18.2.4 so gig0/0/2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.18.2.4, timeout is 2 seconds:
Packet sent with a source address of 192.168.178.99
.....
Success rate is 0 percent (0/5)

Thanks

[Richard Burts]

Of the ping output posted only 1 could possibly succeed. For this ping

Spoke#ping 10.18.2.4 so gig0/0/2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.18.2.4, timeout is 2 seconds:
Packet sent with a source address of 192.168.178.99
.....
Success rate is 0 percent (0/5)

The source address does not match the acl used to select traffic for the vpn and therefore could not work.

This ping could have worked since the source address and destination address do match the crypto acl.

Spoke#ping 10.18.2.4 so loop0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.18.2.4, timeout is 2 seconds:
Packet sent with a source address of 10.99.0.1
.....
Success rate is 0 percent (0/5)

I suspect that the reason it did not work has to do with the use of vrf.

It might be helpful if we could see the output of show crypto ipsec sa from the hub for the spoke peer. It would also be helpful if we had some clarification of how vrf is used on hub.

Also note that since the spoke has a dynamic address with the hub using dynamic crypto map that the vpn must be initiated from the spoke. The hub can respond but the hub can not initiate the vpn.

HTH

Rick

[ittechk4u1]

Rick ,

It is working now. It was issue with NAT on LTE router.

But now new issue came...

i can ping to all IP on spoke but cant do SSH.

Thanks

[Richard Burts]

I am glad that we are making progress and that the vpn is now working ok. 

We do not have enough information yet to understand the issue about doing SSH to the spoke. As a first step would you post the output of show ip ssh this will confirm whether SSH is correctly enabled.

Also could you tell us what happens when you attempt SSH to the spoke? Do you get any prompt? Or does the SSH request just hang? Or do you get an error response that the request is denied? Or something else?

What address on the spoke are you attempting to SSH to? Have you attempted to SSH to more than one address on the spoke?

We will probably need to see more of the config of the spoke. I might ask that you post the entire config of the spoke. But if you do not want to post all of the config then let us start by posting everything that has to do with aaa. Also post the config beginning at line con 0 and through the end of the config.

HTH

Rick

[Giuseppe Larosa]

Hello,

this is good news

How do you make your SSH attempt ?

try to SSH to Spoke loop address 10.99.0.1 using a source that is in the 10.18.0.0/16 address block.

Verify as suggested by Rick that SSH server function is enabled on the Spoke routers and also as he noted we should see the following:

show run | inc aaa

show run | begin line con 0

You may have an access-list applied on vty lines using an access-class in that case you need to modify it to accept incoming sessions with source IP address in 10.18.0.0/16.

Hope to help

Giuseppe

[ittechk4u1]

Giuseppe,

Thanks for your help.

I used route-map to access the spoke route from HUB. (But i cant use these as permanent solution because LTE solution will be used as 3rd number:, first traffic will flow via GRE tunnels and if these tunnels are down then over LTE.)

Check my cofnig attached:

Now if i use route-map on HUB router 

ip access-list extended TEST
permit ip 10.18.0.0 0.0.255.255 10.99.0.0 0.0.255.255
!
route-map GM_SAP permit 7
match ip address TEST
set vrf ISP3
!
int gig0/1
ip policy route-map GM_SAP

Then i can ping from 10.18.0.0/16 to 10.99.0.0/16 but cant ssh. I suspect its a issue with routing.

[Giuseppe Larosa]

Hello ititech4u1,

you have provided us a creative way to use PBR to put traffic over the IPSec LAN to LAN VRF.

However, yo still have the internal networks in global routing table and you use vrf ISP3 that is

unsupported according to the limitations on VRF aware IPSec I had reported previously.

Second, we have asked you some simple show commands to verify why your SSH attempts are failing and you are not providing them.

Again can you post

show run | inc aaa

show run | begin line con 0

You say the issue is with routing but if it was the ping should fail too. Because routing is not able to discriminate above Layer3.

Networking uses the Layers approach for this reason.

So your issue is likely not with routing. But we cannot say more without more info.

About how to make the new design for a long term solution:

If you have GRE Tunnels protected by IPSec as primary and secondary path, you should think of using a p2p GRE tunnel protected by IPSec also for your tertiary path.

You can even run a routing protocol over the 3 p2p GRE Tunnels and you can easily make a hierarchy in paths by manipulating metrics used by the chosen IGP (for example changing delay on tunnel interfaces if using EIGRP, that you are already using inside each site),

This should allow you to avoid to use vrfs or at least to have the tunnel interface as an additional tool to work with.

Hope to help

Giuseppe

[ittechk4u1]

Sorry for not giving you the output of these commands.

About how to make the new design for a long term solution:

If you have GRE Tunnels protected by IPSec as primary and secondary path, you should think of using a p2p GRE tunnel protected by IPSec also for your tertiary path.--> Good Idea, Let me try to do it. I will update you.

Thanks for valuable information.

[ittechk4u1]

Thanks guys,

Now its working. I created a DMVPN tunnel .

Issue was with NAT-T. I configured NAT on LTE router and it started working.

Thanks