IPSEC Issue

[Mikey John]

Hi,

I am trying to setup an IPSEC tunnel between a Cisco ISR4431 router and a checkpoint firewall. I ran into multiple issues, and needed help to validate the configs and logs on the cisco router. Attached is the router config for your reference.

Source - 192.168.1.0/24
Destination - 10.10.10.1/32

Tunnel Source is Router LAN interface (2.2.2.3).

Traffic path
============

Host machine (192.168.1.x) --> Switch (192.168.1.x/24) --> FW Inside (192.168.1.10) --> FW outside (2.2.2.2) --> Router (LAN Interface 2.2.2.3) --> Router WAN Interface--> Towards Internet

Problem 1
=========

When I initiate traffic (continuos pings) from source 192.168.1.23/24, it does not seem to hit the crypto ACL. I could not see any hits getting incremented. But, when I added permit any any on the ACL, it started getting hits.

ip access-list extended vpn-ABC
permit ip 192.168.1.0 0.0.0.255 host 10.10.10.1 log --> No hits seen for this line

permit any any ---> added later

1) What seems to be wrong with the original ACL?

Problem 2
=========

When I added "permit any any" on the crypto ACL, the ACL was getting hits, and I could see Tunnel Phase 1 and Phase 2 Up. But, there was no Web traffic passing through. I was getting the following errors.

*Jan 23 16:03:55 GMT: %IOSXE-3-PLATFORM:cpp_cp: QFP:0.0 Thread:001 TS:00002146448051374595 %IPSEC-3-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet, dest_addr= 10.10.10.1, src_addr= 192.168.1.23, prot= 1
*Jan 23 16:04:55 GMT: %IOSXE-3-PLATFORM:cpp_cp: QFP:0.0 Thread:001 TS:00002146509123448118 %IPSEC-3-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet, dest_addr= 10.10.10.1, src_addr= 192.168.1.23, prot= 1

Is it because of a routing issue? I did not have enough time to troubleshoot, but I figured later that there was no return route from router back into 192.168.1.0 LAN segment.

ip route 192.168.1.0 255.255.255.0 2.2.2.2 --> This was missing

Am I right in my assumption?

Appreciate your feedback.

Cheers
Mikey

[Sergey Lisitsin]

Mikey John,

Remove the log keyword from the end of your crypto ACL, it is not supported. That's why you didn't get hits. And when you added permit any any at the end, you started getting hits, but that broke your encryption domain symmetry and caused other issues. Just re-write your crypto ACL without the log and that should sort it.

[Mikey John]

Thanks Sergey. I'll try without the log keyword and see the outcome.

Also, is there any issue if my tunnel source IP is on the LAN interface instead of the WAN interface (as commonly configured). I saw the tunnel come up, so Iam guessing it shouldn;t be. But wanted to confirm.

Cheers

Mikey

[Richard Burts]

Mikey

As long as there is successful IP connectivity between the tunnel destination address (on the remote peer) and the tunnel source address (on the local peer) it should not matter whether those addresses are on the outward facing (WAN) interfaces, inward facing (LAN) interfaces, or loopback interfaces. It is sometimes easier to satisfy this requirement if the addresses are on outward facing interfaces, but as long as the connectivity requirement is satisfied then it should not be a problem.

HTH

Rick

[Mikey John]

Hi Rich / Sergey,

 I tried settting up the Tunnel with only the specific ACL (removing the any statements). Traffic was not even hitting my local router as I could not see any hits on the ACL. The FW was passing the traffic towards my router though. 

What could be the issue?

Thanks

Mikey

[Richard Burts]

Mikey

I am not sure what has changed since you posted the router config. Perhaps you could post the current config?

I see that the traffic from the LAN passes through a firewall before it gets to your router. Is there any possibility that the firewall is doing some address translation and by the time the packet gets to your router that the source address is not what you are expecting?

HTH

Rick

[Mikey John]

Hi Rick,

 Nothing has changed in the Router config. I have attached the configuration again for your reference.

I checked with the Firewall team, and they said they could see the traffic from Inside to outside on the Palo Alto FWs, and as per them the next logical hop should have been the router.  As per them, no NAT should happen in the firewall interface. But, I can confirm on this only in the next change window.

In the meanwhile, I wanted to be sure nothing is wrong on my router end.

Cheers

Mikey

[Richard Burts]

Mikey

Thank you for a fresh copy of the config. There are several issues to be addressed.

1) As Sergy mentioned your acl for crypto includes the log parameter. I agree with him that you need to remove the log parameter. And I certainly agree that the acl for crypto should not contain "any".

2) The config has a crypto map. But I do not see that crypto map configured on any interface. It is hard to know if it is really not in the config or is one of the things that you did not include (like interface G0/0/1 is not included). 

3) You had asked about whether it mattered whether the tunnel source was the outside interface or perhaps an inside interface. In thinking about tunnels and source addresses I was thinking more in terms of a GRE tunnel. And my answer was appropriate for a GRE tunnel that the source address could be either inside or outside. But having looked more closely at the config I realize that this is not a GRE tunnel but is an ipsec tunnel (which uses a crypto map). And for a crypto map the placement of the map is more critical. The crypto map needs to be configured on the interface which the router will use to forward the packet toward its destination. So in your case it is important that the crypto map be configured on the outside interface. 

4) Routing information. The config shows that you are running BGP (apparently with your ISP). But there are no other routing statements or any dynamic routing protocol. The config shows that traffic for the vpn will come from 192.168.1.0. But your router has no way to know where that network is. Your original post asks if there should be a route statement for that network. Yes indeed there should be.

HTH

Rick

[Mikey John]

Hi Rick,

Thanks for your reply. My answers are inline below to each of the points.

1) The "log: keyword was removed during my last change while testing. It is not there anymore.

2) Yes, the crypto map was applied on the Gig0/0/2 interface when we were trying to move the tunnel to this router. Since the change did not work, we moved it back to the SonicWall FW, and the crypto map statement was removed from the Gig0/0/2 interface. 

3) Thanks for the explanation. So, even if there is routing towards Internet through BGP, I cannot have Crypto map configured on the Inside interface? We are forced to use the same public IP (in our LAN segment) for IPSEC termination since customer does not want to change IP on their end. 

4) There is a static route added for traffic going back towards the LAN segment. I removed it when we had to revert the change.

ip route 192.168.1.0 255.255.255.0 2.2.2.2 (FW IP)

Now, coming back to my original query, why is the traffic not hitting my router's LAN interface? Can it be due to some hidden NAT on the FW?

Cheers

Mikey

[Richard Burts]

Mikey

Thanks for the clarifications. Here are my responses:

1) it is good to know that the log parameter has been removed. I believe that will be significant.

2) it is good to know that the crypto map was applied during testing and removed when the test was not successful. The crypto map needs to be on the outside interface.

3) the crypto map does need to be on the outside interface. I created some confusion when I made a response that the tunnel source could be on an inside interface and I am sorry for the confusion. My response was based on a misunderstanding of your question. I interpreted your question to be about configuring tunnel source (as in some type of GRE tunnel). After looking into the config I realized that you are really asking about where to place the crypto map. Since the way it works is that IOS looks at traffic going out the interface where the crypto map is assigned and if traffic matches the acl then the traffic is encrypted. If you assign the crypto map on the inside interface then the traffic going out that interface will not match the acl. I believe that is why you are not seeing hits on the acl. (and I believe that the log parameter may also have been a factor for that)

I am not clear what you are telling us in this statement

We are forced to use the same public IP (in our LAN segment) for IPSEC termination since customer does not want to change IP on their end. 

4) it is good to know that there was a static route and that it was removed when the vpn did not work.

How do you know whether the traffic is hitting your interface? If the fact that there is no hit count in your crypto acl is the basis of this concern there is an explanation for that. (especially the crypto map not on the appropriate interface, and perhaps the log parameter) Is there some other reason to believe that the traffic is not hitting your interface?

I believe that if the log parameter has been removed from the acl, if the static route is configured again, and if the crypto map is assigned to the outside interface that your next test should work.

HTH

Rick

[Mikey John]

Thanks Rick for the detailed explanation.

You are right, my sole reason in believing the traffic is not hitting the Router's LAN interface is because I was not getting any hits on the ACL. 

In the current setup, the public IP used for the IPSEC termination is configured on the SonicWall FW. While planning to migrate the IPSEC tunnel from SonicWall FW to Router, we were planning to use the same public IP (and decommission the FW) so that we don;t have to ask the customer to change the IP on their end. 

Now, that you have confirmed that crypto map would not work on the inside interface, I would have to apply it on the Gig0/0/0 interface (outside), and hence ask the customer to change the public IP on their end (as my outside interface has a different public IP (/30) towards the ISP)

Thanks

Mikey

[Richard Burts]

Mikey

Thank you for the explanation. As I understand your situation as you move the vpn from Sonicwall to ASA the outside interface/public IP will change. And that will require the customer to make changes in their configuration.

HTH

Rick

[Mikey John]

Thanks Rick. One last thing I wanted to run by you.

Can I set up two subinterfaces on the router towards LAN (Gig0/0/2.10 and gig 0/0/2.20). That ways I will have one sub-interface on the 192.168.1.x segment, and the other one on 2.2.2.x segment. And make the uplink from switch towards router a trunk port. I believe this would be better?

Thanks

Mikey

[Richard Burts]

Mikey

I am not sure that I understand your question correctly. Certainly the router supports configuring a physical interface with sub interfaces, associating a vlan with the sub interface, and connecting to a switch trunk port. So in a technical sense yes you can do this. But I do not understand why you would want to do this. In the original post you described the topology as 192.168.1 was for users and connected to FW. And 2.2.2 connected FW to your router. If you configure sub interfaces and the router has a sub interface in 192.168.1 and a sub interface in 2.2.2 does that mean that user traffic in 192.168.1 can go directly to your router and bypass the FW?

HTH

Rick

[Mikey John]

You are right. That would essentially mean I am bypassing the FW, and I wouldn;t want to do that.

Thanks

Mikey