cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1720
Views
0
Helpful
6
Replies

IPSec Transport Mode Question

support
Level 1
Level 1

Hello,

We currently have a site-to-site VPN in tunnel mode running between our corporate network and our DR site to provide secure replication to our DR site. I am making some firewall changes this weekend that will place a IOS Zone-Based FW between the 2 sites (To provide 2 firewalls for the corporate site - creating a DMZ in the middle).

The Corporate site and the DR site are all within our Autonomous System, so there is no NAT invovled, as all the routes are private. I have a VPN to provide extra protection at each site, because they are both accessible via the Internet (I wanted to keep the ACL small on each ASA's outside interface) Anyway, to my question.

I am implementing a zone-based firewall on the edge router to provide additional protection. On the ACL for the zone-pair between my corporate and DR site, if I switch the VPN to transport mode, should these ACE's work?

Corporate ASA = 1.1.1.1

Corporate Net = 10.10.10.0/24

DR ASA = 2.2.2.2

DR Net = 20.20.20.0/24

permit esp 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255

permit udp host 1.1.1.1 host 2.2.2.2 eq isakmp

permit esp 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255

permit udp host 2.2.2.2 host 1.1.1.1 eq isakmp

I'm pretty sure this is correct; however, I wanted a little re-assurance before I made these changes Saturday.

1 Accepted Solution

Accepted Solutions

This link describes IPSec features as a protocol, transport and tunnel mode being of those features, what I mean is that the ASA as a Cisco solution does not support Transport mode for Lan to Lan tunnels.

Now sinc eyou made me hesitate on my answer, I did a quick test connecting 2 ASA's back to back and setting a lan to lan tunnel using transport mode, the tunnel came up fine yet traffic did not go through, reason? the ASA was dropping it due to the fact that the SA and classification of the secure traffic should be from peer to peer (as normal tunnel mode works) in our case the ASA received an ESP packet from the internal network of the remote ASA which does not match the classification therefore it is being dropped.

ESP request discarded from 11.1.1.2 to outside:10.1.1.2

Deny inbound protocol 50 src outside:11.1.1.2 dst identity:10.1.1.2

This message shows after configuring some nat and acl rules to see if it accepts traffic:

IPSEC: Received a non-IPSec packet (protocol= ESP) from 11.1.1.2 to 10.1.1.2.

So as you can see it is more like a limitation of the platform or something.

Now the question I have for you why the need of transport mode?

View solution in original post

6 Replies 6

Ivan Martinon
Level 7
Level 7

First of, if I am not wrong Transport mode is only supported for Remote Access Type VPN on the ASA not for lan to lan, yes it does give less overhead but I am not sure this will work.

Thanks for your responce. Hopefully I'm not thinking too outside the box here.

What is your intruptation on this statement from the IPSec Guide of Cisco's web site? (http://www.cisco.com/en/US/docs/net_mgmt/vpn_solutions_center/2.0/ip_security/provisioning/guide/IPsecPG1.html#wp1031028) Maybe I'm looking for something that isn't there, but this statement leads me to believe it is possible. What do you think?

"Transport mode is applicable to either gateway or host implementations, and provides protection for upper layer protocols as well as selected IP header fields."

This link describes IPSec features as a protocol, transport and tunnel mode being of those features, what I mean is that the ASA as a Cisco solution does not support Transport mode for Lan to Lan tunnels.

Now sinc eyou made me hesitate on my answer, I did a quick test connecting 2 ASA's back to back and setting a lan to lan tunnel using transport mode, the tunnel came up fine yet traffic did not go through, reason? the ASA was dropping it due to the fact that the SA and classification of the secure traffic should be from peer to peer (as normal tunnel mode works) in our case the ASA received an ESP packet from the internal network of the remote ASA which does not match the classification therefore it is being dropped.

ESP request discarded from 11.1.1.2 to outside:10.1.1.2

Deny inbound protocol 50 src outside:11.1.1.2 dst identity:10.1.1.2

This message shows after configuring some nat and acl rules to see if it accepts traffic:

IPSEC: Received a non-IPSec packet (protocol= ESP) from 11.1.1.2 to 10.1.1.2.

So as you can see it is more like a limitation of the platform or something.

Now the question I have for you why the need of transport mode?

Wow! Thank you doing all of that! Sorry to make you hesitate on your answer!  I was not considering the ASA's limitations. My assumption was Cisco would have designed the devices to following the RFC for IPSec, whether it was RA VPN or S2S…. I don't like assumptions, so that is part of the reason why I posted this question. I have a ton of things to do this Saturday, and the time I would have spent troubleshooting why transport mode was not working, would have wasted a lot of valuable time. Thanks again for helping me out!

I have collocation network in a nearby city, where we keep DR equipment. I've got a T1 from my corporate HQ to this colo network to provide Internet access to our office. I have the T1 going there because we are charged for Internet access at that collocation depending on what our bandwidth usage is ($375 per month per 1MB based off our 95th percentile usage). We have replication configured between our corporate office to the DR equipment. All of our replication traffic would have cost extra $$$ if we had a T1 connected to an ISP. We save about $750/month by doing it this way. Since the T1 remains in a private network, replication can occur at no extra cost. I also can control QoS on both sides of the T1, and we are moving to a VoIP phone system this year as well as add another T1. This will allow more replication bandwidth without incurring more per MB bandwidth charges.

Now the reason I have a VPN. I wanted to avoid the “Swiss cheese” effect on the firewall on both ASAs. This also protects both internal networks from an IP spoof attack, even though is unlikely, I thought was to be better safe than sorry. In theory, transport mode would be the best, since all of the IP addresses are private, and transport mode would cut out 20bytes of overhead per packet.

Oh well I guess I'll stick with Tunnel mode! Thanks again for your help!!!

No Worries, it is always good to reinforce knowledge, I actually understand your point however there are alternatives as to how to treat packet size, allowing fragmentation is one and other is to force the MSS (maximum segement size) to be less than the standard 1460 (recommended 1300) to avoid adding or making the packet to be greater than 1500 bytes.

I was thinking more along the line that tunnel mode adds a new IP header to every packet, which I really don't need, so I was trying to elimiate that all together.

Oh well! Thanks again for your help. You saved me a ton of time!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: