Re: Issue of IPsec VPN network over transport mode

JManalo20 · ‎10-28-2012

Hi Guys

I'm now trying to implement a IPsec VPN network over transport mode in my simple network environment.

I got two Cisco 2811 routers connected each other and each router hosts a client PC running Windows7.

I have finished the configuration on both routers and make them running over transport mode.

However, as what it should be, transport mode indicates the communication between two end stations (two PCs)

So I am wondering that do I need to do anything else on the client PC (install or configure something) to make the network fully works?

Thanks for any suggestions and comments.

Cheers.

olpeleri · ‎10-29-2012

Jerson,

With transport mode, the traffic that need to be encapsulated need to be generated by the router itself.

In other words, if the client PC need to reach something between the router, it will work ONLY with tunnel mode.

Cheers,

Marcofbbr · ‎04-07-2013

Hello olpeleri,

I am studing IPsec and I came across this interesting thread.

Could you please clarify or confirm that what I am writing below is correct ?

PC1-----R1-----(ipsec)-------R2------PC2

==CASE 1 : IPSEC is set to transport mode, gre is not configured.

1)PC1 creates a packet destined to PC2 and send it to R1.

Headers are "| IP | TCP | payload|"

2)R1 receives the packet, perform a RIB lookup and forward it to R2. Packet get encrypted before it leaves the outbound interface.

Headers are: "| IP | ESP | TCP | payload |". The destination IP is still PC2 address?

3)R2 receives the ecrypted packet that get decrypted. I suppose R3 is unable to forward the packet here, because it does not have the IP information after the ESP header. Isn't it?

==CASE 2 : GRE over IPsec is configured between R1 and R3, using VTI (no crypto map applied, and option "tunnel mode ipsec ipv4" used on tunnel)

1)PC1 creates a packet destined to PC2 and send it to R1.

Headers are "| IP | TCP | payload|"

2) R1 receives the packet, perform a RIB lookup and forward it to R2. Packet get encrypted before it leaves the outbound interface.

Headers are: "| IP | ESP | IP | TCP | payload |"

3) R2 receives the packet and should be able to forward it to PC2 because R2 can see the original packet information . If this is true it means that when using VTI, the tunnel mode configured for IPsec is not a reason of concern. This should solve the issue described in the first message.

Andrew Phirsov · ‎04-07-2013

I'll comment on how i see this:

==CASE 1 : IPSEC is set to transport mode, gre is not configured.
1)PC1 creates a packet destined to PC2 and send it to R1. 
Headers are  "| IP | TCP | payload|"

2)R1  receives the packet, perform a RIB lookup and forward it to R2. Packet  get encrypted before it leaves the outbound interface.
Headers are: "| IP | ESP | TCP | payload |". The destination IP is still  PC2 address?

I'm not sure that R1 will encrypt the packet (never tried it, but should try))), cause source address is not IP of R1s interface, but, just suppose it does. Then, yes, destination IP will not be changed, and it remains PC2 IP address.

3)R2 receives the ecrypted packet that get decrypted. I suppose R3 is unable to forward the packet here, because it does not have the IP information after the ESP header. Isn't it?

When R2 receives this encrypted traffic, it's not gonna decrypt it, cause the packet is not destined to R2, it's destination is PC2 IP, so R1 will just route it towards PC2.

Now, PC2 receives IPSec packet, and just drops it, cause it doesn't know what to do with it.

==CASE  2 : GRE over IPsec is configured between R1 and R3, using VTI (no  crypto map applied, and option "tunnel mode ipsec ipv4" used on tunnel)
1)PC1 creates a packet destined to PC2 and send it to R1. 
Headers are  "| IP | TCP | payload|"


2)  R1 receives the packet, perform a RIB lookup and forward it to R2.  Packet get encrypted before it leaves the outbound interface.
Headers are: "| IP | ESP | IP | TCP | payload |"

Packet are routed towards the tunnel interface and get encrypted as you said, and, what really matters here, it's got new IP header with source and destination being IPSec endpoinds IP-addresses.

3) R2 receives the packet and should be able to forward it to PC2 because R2 can see the original packet information . If this is true it means that when using VTI, the tunnel mode configured for IPsec is not a reason of concern. This should solve the issue described in the first message.

What solves that command, it adds new IP header, so when R2 receives encrypted packet, IP of the outer header is the IP of R2s outside interface. So, when R2 receives it, R2 knows that it should look inside, decrypt packet, and send it to the PC2.

All said above just outlines general concept, that transport mode should and may only be used to protect traffic between IPSec endpoints (gateways) themselves, as said olperely in the previos post.

Hope i was clear)))

olpeleri · ‎04-15-2013

Hello,

Your analysis of point 1 seems right. That's why the RFC2401 does not allow that scenario:

RFC2401 mandate the use of transport mode as

"A transport mode SA is a security association between two hosts".

A bit later in the rfc, we clarify the scenario

"If it supports transport mode, that should be used only when the security gateway is acting as a host"

Cheers,

Olivier