Cisco ASA VPN "Tunnel Mode" / "Transport Mode"

OK, I've never done it with Sonicwall, but I presume they are talking about gre.

On the other hand, there is a document on sonicwall site (FAQ IPSec) that states that SW do not terminate GRE.

So doublecheck GRE option with them

They could also think about pptp but forget that with ASA.

According to cisco:
By default, the ASA uses IPsec tunnel mode—the entire original IP datagram is encrypted, and it becomes the payload in a new IP packet. This mode allows a network device, such as a router, to act as an IPsec proxy. That is, the router performs encryption on behalf of the hosts. The source router encrypts packets and forwards them along the IPsec tunnel. The destination router decrypts the original IP datagram and forwards it on to the destination system. The major advantage of tunnel mode is that the end systems do not need to be modified to receive the benefits of IPsec. Tunnel mode also protects against traffic analysis; with tunnel mode, an attacker can only determine the tunnel endpoints and not the true source and destination of the tunneled packets, even if they are the same as the tunnel endpoints.

When setting up a 'normal' site to site vpn the ASA uses tunnel mode. Configuring the site to site you define on the ASA itself what the intersting traffic is.
So basically you can just set up a normal (ipsec) site to site on the ASA.

Yes, ernieback this is standard terminology and in fact I've never came across any other mode than tunnel. However, if you look closer, "they insist on using what they term to be a "tunnel mode" VPN not a site to site traditional Cisco style VPN " indicates at least to me that some here wants to make some sort of tunnel and then to route the traffic over it like one would do over an point-to-point interface. This can be achieved by gre but the hard things is that SW does not seem to support this.

So after a bit more research - this is what we're looking at

http://www.sonicwall.com/app/projects/file_downloader/document_lib.php?t=PG&id=58

"A dynamic route based VPN" is Sonic Wall's terminology.  They claim to be able to do EIGRP / RIP over the VPN - would they not need to use GRE over IPSEC for this?

DS

Could be. The way I read it is that they are mixing up terminology or have a fuzzy way of explaining.

Transport mode is being used in remote access VPN's, software client to firewalls. My guess would be they try to make the distinction between those types of VPN (remote access vs. site2site).

Crosspost ;)

GRE is a protocol just like ESP (47 and 50). GRE is used with PPtP and ESP is used with IPSec.

That was my initial thought - transport vs tunnel. However the third party is adamant that this can be done with a Cisco ASA. I Think I may follow the GRE/IPSEC config guide and just see what happens - you never know we may end up with a working VPN.

Will report back.

We'll be here :)
Ignore that last post, didn't read your comment correctly :-~

OK, I'm afraid you are out of luck on this. But you can alway try.

Official doc sais:

To use Tunnel Interface, both endpoints must define Tunnel Interface policy. You cannot configure a
Tunnel Interface policy on one endpoint of Tunnel Interface and a Site-to-Site policy on the other
endpoint.

This seems to be SW to SW feature and I have not manage to find any example of doing it with Cisco or with anyone else for that matter.

@shukalo83 (and prodriveit of course :)
Have a look at: http://www.blindhog.net/how-to-configure-a-greipsec-vpn-part-1/
http://www.blindhog.net/how-to-configure-a-greipsec-vpn-part-2/

That seems to be the way to go when you want RIP, EIGRP, etc over a VPN tunnel.

I know routers are used here, it just explains it nicely ;)

Forgot to add this one:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml

Please erniebeek, reed the question carefully,

"association request and this creates a "virtual interface" on their Sonicwall router."

I know that GRE does the job, it's just that SonicWall wan't support it.

Perhaps I'm lost in translation here....
How do you interpret that line?
they don't provide any routing / interesting traffic with the phase 2 association request and this creates a "virtual interface" on their Sonicwall router

:) Yes but that's not GRE, that's the whole point. Sonicwall has the Tunnel interface but no one knows what is it.

Ah, so it wasn't just me :)

But then........

@prodriveit: did they send any other requirements regarding the tunnel setup?

Sorry for delay - only the standard phase 1 / phase 2 info.

When we spoke to them, they initially called it an "unnumbered" VPN. I would have taken that to mean a standard site to site, as in routing terms an unnumbered link is when the medium between two routers is simply point to point and doesn't have an IP range associated with it;routing is achieved using interface commands.

However on speaking to them further they specifically stated that no interesting traffic information / access-lists are presented with the Phase 2 association request. This figures, because the issue we're getting is "no matching phase 2 policy" which could be down to the interesting traffic settings (among other things).

I have to say - I'm beginning to think this can't be done, except for the insistance that it can from the 3rd party - I trust them and I'm inclined to believe them when they say that they've seen it done before.

Ok. If they've seen it done before, then ask them how it was done (so we can learn from that).

Any news on this. I'm still afraid that cisco with sonicwall's tunnel option and you'll have to revert on classic IPSec. I would like to know what will happen so keep us informed.

Solved the problem.