[nsp] IPSEC tunnel mode

Victor Sudakov sudakov at sibptus.tomsk.ru
Wed Aug 27 00:20:12 EDT 2003

Joel Snyder wrote:
> >http://noc.tomsk.ru/tmp/router.png
> >I want packets from hosts on Ethernet1 to be securely forwarded to R5
> >and then further to the Internet, without R2, R3 and R4 knowing about
> >the network on Ethernet1.
> >Do I have to build a GRE Tunnel between R1 and R5 to run IPSEC over
> >GRE, or could I just do with IPSEC tunnel mode only?
> "It depends."
> It depends on what you mean by not having "r2, r3, and r4 knowing about 
> the network."  It also depends on what you mean by "packets" and what 
> kind of routing strategy you use.
> IPsec tunnel mode is the simplest answer; you can think of it as a whole 
> different routing engine which somehow magically sends IP unicast 
> packets across from one router to the other and which does not otherwise 
> interfere with or communicate with your other IP routing engine.  Thus, 
> if you have properly filtered out knowledge of R1's ethernet from your 
> routing tables, then R2, R3, R4 won't know diddly about it.
> If when you say "packets" you mean more than IP unicast packets, then 
> you will definitely need something which instantiates an IP interface. 
> By pumping GRE out over IPsec, you can ship any kind of packets you want 
> over the tunnel since IPsec sees it as a GRE tunnel, not as the data in 
> the tunnel.
> GRE is also important if you want the tunnel's existence to be part of 
> your routing infrastructure (again, not sure what you mean by "knowing" 
> about the Ethernet).

I mean that R2, R3, R4 are not under my control. You may think of R5
as a central office and R1 as a remote branch (which in fact they are)
while R2, R3, R4 are the ISP's network. I am sorry I did not make it
clear from the start.

> If I were doing this, my definition of "packets" would be "IP unicast," 

Yes, IP unicast is enough.

> my definition of "knowing" is "can see packets" and thus I would simply 
> do an IPsec tunnel from R1 to R5 and leave it at that.  If you want to 
> stick ACLs on the incoming Internet-pointing interface prohibiting 
> packets from going from R2 directly to R1's Ethernet, that might also be 
>  useful, but perhaps traffic from R2 to R1's Ethernet is not 
> prohibited, even if unencrypted.
> Now, it gets a LOT more complicated if you want R2, R3, and R4 to send 
> their traffic out to R5 for encryption before it can come back to R1. 
> In that case, you'd definitely want to think about using GRE because you 
> will want to make the only route to R1's ethernet via R5, and GRE is one 
> easy way to do that.  You can always static it up, of course.
> I would tend to avoid GRE just because of the additional overhead and 
> complexity.

I would do the same but I am not sure. If I do not do GRE, I will have
to use the word "any" in the crypto acl on R1, which is not recommended.

Victor Sudakov,  VAS4-RIPE, VAS47-RIPN

More information about the cisco-nsp mailing list