Tunnel within a Tunnel (Router GRE to a TACLANE VPN )

[csmiler]

We have a Router connected to a TACLANE encryption device (router-to-taclane remote taclane-to-router). The TACLANEs setup VPN tunnels between each end point. Does this meant that using Router GRE tunnels prior to TACLANE VPN not a possible design option?

[Richard Burts]

Cheryl

I do not have experience with TACLANE so there may be something about it that I underestimate. But I do not see why sending traffic TACLANE to TACLANE via VPN tunnel would prevent you from running GRE tunnel from router to router. It seems to me that the TACLANE should accept whatever traffic it gets for the remote destination and encrypt it - why would it care what kind of traffic it was? If there is something that I have missed please help me understand it.

HTH

Rick

[csmiler]

Let me clarify. The TACLANE setup here is point to point and it encrypts. There are limitation within the TACLANE that prevents encryption nesting. Other encryption devices, have problems with multiple nesting of encryption. I guess my question really is pointing to a tech spec that explains how the GRE tunnel is built and what field level information is contained in the header. Or whether anyone else has every used GRE tunnels through DOD encryption devices without problems. Thanks.

[Richard Burts]

Cheryl

Running GRE tunnels through the TACLANE would not be nesting encryption - the GRE tunnel does not encrypt. It only encapsulates one data packet within a new IP header.

If you are interested in a tech spec of GRE then I would suggest that you start with RFC2784.

HTH

Rick

[csmiler]

So I can run the GRE without using encryption (IPSEC). That works for me.

Thanx.

[Richard Burts]

Cheryl

Yes the default in GRE is to not encrypt. GRE by itself is an encapsulating protocol not an encrypting protocol.

HTH

Rick

[rohosford]

I have used the Taclane a lot. The Taclane creates point to point tunnels like a vpn. So you can test your GRE tunnels without a Taclane by using a regular tunnel mode IPSEC tunnel.

The effect is the same on the transit traffic.

Any kind of encapsulating tunnel is going to have issues with fragmentation. This isn't a Taclane problem ,it is an IP header problem and MTU size issue. You have the same problems with nested GRE tunnels.

So back to the Taclane you can nest taclanes, and use gre tunnels on the PT side. If you want to know how to setup GRE tunnels behind the Taclane it is in the Taclane documentation.

Just remember for every gre tunnel interface and taclane you traverse in one direction you have to reduce the mtu size by the size of each new header. If you don't you will have lots of fragments. It is not uncommon to be nested by three taclanes. And then have three gre tunnels. So you will add the six new headers together. This is the amount you subtract from the first sending router. You might have an MTU size of 1280 on the first tunnel interface. It would be best to have the Hosts reduce their MTU size to avoid router fragmenting the packets.

Help desk Contact Information:

* Toll Free: 877-230-0236

* Local: 410-850-4893

* DSN: 644-1139

* E-mail: InfoSecSupport@gdc4s.com

[bbaillie · Accepted solution]

Without getting too detailed here is your conundrum. The issue with the configuration is my assumption you are in a higher than normal security environment, this means the folks doing configuration templates for routers assume everyone wants to DOS them. This means they use "no ip unreachables" on pretty much all interfaces as a "best practice", this creates "blackhole" problems in you network. Here is how it happens, the sending device negotiates MTU with the target device and assumes all is well. When the packet is encrypted or encapsulated (GRE) it becomes bigger than the max MTU of the links inside and outside the encryptor. The hosts may attempt to discover the correct path MTU but neither the inside nor the outside encryptor can send the "ICMP unreachable, packet too big" message when the stations have generated frames with the DF bit set and expect a response. Result they continue to send MAX size packets that after encapuslation are too big and are dropped quietly.

You can address the problem by using the tunnel MTU as the responder, this means adjusting the tunnel MTU accordingly and allowing the tunnel interface the ability to do ICMP packet too big unreacables. You can also reset the DF bit incoming to the tunnel and adjust the tunnel MTU to make it chop packets samll enough to make it all the way though to the far end unimpeeded, not optimal bandwidth useage but its a tradeoff.

Here is a link with some generic info.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

Its not an encryption nesting problem but really an MTU problem causing blackhole routing due to an aggressive security posture.

Cheers,

Brian

[csmiler]

That makes total sense!!! We never had a problem until we tried to double and triple nest the encryption devices in between our routers. Then I thought we better not add one more thing like a router GRE tunnel but I see that is not the limiting factor. I will read more on this and get back with the team.

Thanks a mill!!!

Cheryl