IPSec in transport mode question

[mikeleecha]

Hello. I was wondering if anyone has any experience with setting up an IPSec connection in transport mode?

I have a situation where I need the original source and destination address to be preserved. I would be running this IPSec connection within a WAN of mine so I don't need to tunnel this connection. Keeping the original source ip is vital since I've setup different metrics in my OSPF process for this subnet. Thanks

[Richard Burts]

Mike

I have set up IPSec using transport mode. You are correct that the big difference between transport mode and tunnel mode is that tunnel mode creates a new additional header for the packet and transport mode does not. To the extent that the additional header of tunnel mode hides the identity of the end stations that are communicating it removes one piece of information that an attacker might be interested in. But it sounds like that is not a concern for your situation.

I configured the IPSec, specified transport mode, and it works well. Do you have a specific question about transport mode.

HTH

Rick

[mikeleecha]

Rick

That's correct, hiding the identity of the end stations is not needed in this case. I'm running the IPSec connection through a telco provided MPLS network.

The network as it sits now looks like the following:

Router A has g0/0 with IP 10.254.120.10/24 - this interface goes to the Site A LAN. g0/1 hooks up to the telco router. The interface has an IP of 192.168.52.2/28. The telco router has an IP of 192.168.52.8/28.

Router B has g0/0 with IP of 172.16.1.1/16 - this plugs into Site B's LAN. g0/1 plugs into the telco router. The g0/1 interface has an IP of 192.168.52.36/29. The telco router at this site has an IP of 192.168.52.38/29.

I exchange routes with my telco using OSPF and in turn those routes are redistributed through my Telco's cloud as BGP routes. When the routes emerge at the other end my telco redistributes them back to OSPF External Type 1's.

I perform PAT on both Router A and Router B so that source traffic from each LAN is changed.

For Router A - when users go from the LAN to the telco router their IP is PAT'd to the address 207.148.190.5.

On Router B - when users go from the LAN to the telco router their IP is PAT'd to the address 206.75.237.5.

I do a ip route 207.148.190.0 255.255.255.0 null0 and redistribute static on Router A so my telco router recieves this route.

Likewise, on Router B I do a ip route 206.75.237.0 255.255.255.0 null0 and redistribute static on Router B so my telco router recieves this route.

In the near future I will be deploying two routers in each site for redundancy purposes. As such I will influence the OSPF metrics so one router advertises routes with a preferred metric as the other.

For example, at Site A I could have routers F and G. F could send the route with 207.148.190.0/24 with a metric of 10 while router G could send that same route with a metric of 20.

I've mocked up a lab network with each site having two routers with and telco router in the middle. Everything works as expected. However, my dept has mandated that all traffic between the two sites be encrypted.

The problem I have is that when I use IPSec in tunnel mode the source and dest IP of the packet is of the IPSec peers. Without IPSec running the packet that the telco would receive could have a source ip of 206.75.237.10 for example and a dest ip of 207.148.190.5. Because I influence the OSPF metrics I can also influence which router my telco uses to forward traffic.

However, with IPSec running in tunnel mode the source and dest ip would be 192.168.52.2 and 192.168.52.36 for example. Because the telco see's these as locally attached networks it will simply arp for the peer address. It won't perform any sort of route lookup.

Not sure if I made myself clear or not here. I guess the gist of it is this - can I keep my packets with the original ip header but just have the payload encrypted?

Any help would be greatly appreciated.

Mike

[Richard Burts]

Mike

This is a very interesting situation with lots to think about and to figure out. I certainly can not address all of it in a single response, but here are some thoughts to start. I suspect that there will be some more.

It seems to me that with a single router at each site it does not matter much whether you do IPSec in tunnel mode or in transport mode. They both should work and should deliver traffic correctly to the remote router. It gets more tricky when you introduce a backup router at each site and need to control which router receives the packets. Is this a correct understanding?

When you install the second routers at each site, will the new router be doing PAT into the same existing address or will they translate into a different address? It seems to me that a different address might solve your problem of which router to receive the packets without complicating the routing protocol.

Another potential solution occurs to me which might be that the routers at each site will probably be configuring IPSec peer relationship with both routers at the other site. Is that correct? If this is so, could you not have each router treat one peer as preferred and solve your problem that way?

HTH

Rick

[mikeleecha]

Rick

Yes, the second router will be doing PAT to the same address as well. The two routers are running HSRP on the LAN interfaces. Since the primary router will be doing PAT I need the return traffic to go back to the same router.

Without IPSec running I let OSPF dictate the choice of which router the telco should forward traffic to. If an interface goes down on the primary router I can tell the router to stop advertising the route to the telco (I use a tracking object for the static route). HSRP will then failover to the second router and since it's the only router telling the telco about the subnet it the telco will forward traffic to it.

Yes, the two routers at Site A would have a peer relationship with the two routers at Site B. If I do make a peer as preferred do you know how I could send traffic to the second router in case of HSRP failover?

With IPSec running the destination IP will be the peer address of my router at the other site. Since this IP is locally connected (from the telco's point of view) they will always advertise the locally connected subnet between their router and mine and this subnet will always be in the routing table.

Let's say I had a failure on my primary router's LAN interfaces on Site A but the WAN interfaces were up and running. This would cause HSRP to failover to the 2nd router at Site A. Is there a way I could tell my routers at Site B to no longer use the IPSec peer of router A and to use Router B instead?

In your opinion is it possible to run IPSec in transport mode for this situation?

Thanks,

Mike

[Richard Burts]

Mike

I think that it is feasible to run IPSec in transport mode in your situation.

HTH

Rick

[mikeleecha]

Rick

I took your advice and tried running in transport mode.

I adjusted my crypto transform set on my routers to look like this

crypto ipsec transform-set ipsec_transform esp-aes 256

mode transport require

However, I get the following error when I do a deb crypto ipsec

*Dec 10 18:49:29.498: IPSEC(key_engine): got a queue event with 1 kei messages

*Dec 10 18:49:29.506: IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) INBOUND local= 192.168.52.2, remote= 192.168.52.18,

local_proxy= 207.148.190.0/255.255.255.0/0/0 (type=4),

remote_proxy= 206.75.237.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-aes 256 (Tunnel),

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x2

*Dec 10 18:49:29.506: Crypto mapdb : proxy_match

src addr : 207.148.190.0

dst addr : 206.75.237.0

protocol : 0

src port : 0

dst port : 0

*Dec 10 18:49:29.506: IPSEC(validate_transform_proposal): invalid transform proposal flags -- 0x2

*Dec 10 18:49:29.506: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 192.168.52.18

Do you know if there's more I need to do to enable transport mode other than just specifying it in your transform set?

If I remove the line that says mode transport require I the IPSec connection comes up just fine...albeit in Tunnel mode.

Thanks

Mike

[mikeleecha]

Rick

One thought I had - currently I'm relying on my telco to provide me with routing updates. If I do run IPSec to all peers could I run a routing protcol within a GRE tunnel so that I could then know which peer to send traffic to based on a routing update?

As it sits now without IPSec running the telco is telling me about 207.148.190.0/24 for example. But let's say I run IPSec with GRE between the two routers at Site A with the two routers at Site B. Then instead I could send routing updates between the Site A and Site B routers with GRE.

Normally Site A Router A would send to Site B router A for subnet 206.75.237.0/24. That's because Site B router would send this subnet with a higher metric than Site B router A. But if Site B router A had some sort of failure it would stop sending routes for 206.75.237.0/24 (either by tracking an object or because it went offline) and the only remaining route to 206.75.237.0/24 would be through Site B router B. I haven't worked much with IPSec w/GRE but I would imagine I could have routes coming from tunnel 1 and tunnel 2 and route to those tunnels based on the routing table.

Do yiu think this is possible or am I out to lunch? :-)

Thanks,

Mike

[Richard Burts · Accepted solution]

Mike

I think that this is very possible. Most of the IPSec VPNs that I have done have been IPSec with GRE. One of the advantages of GRE with IPSec is that the GRE can carry routing protocols so that the peer routers can share routing information with each other.

While it is common practice to use loopback addresses as source and destination for GRE tunnels, in many of my implementations I use the outside physical interface. That way if the link to the provider goes down the tunnel will stop and it facilitates quick failover to the other router.

HTH

Rick

[mikeleecha]

Rick

Glad to hear this is a feasabile option. I'll do some research and figure out how to best implement this solution in my network.

Thanks for all the great advice! It's much appreciated.

Mike