[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