cisco VPN ipsec tunnel virtual interface operation detail question

cisco VPN ipsec tunnel virtual interface operation detail question
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
cisco VPN ipsec tunnel virtual interface operation detail question ricecs 07-28-2006
Posted by on July 28, 2006, 2:57 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Basically I am not clear about the virtual interface and physical
interface interaction in the whole communication process, How TCP/IP
stack, routing process, virtual interface, physical interface, IPSec
fit together in a tunnel all or split-tunnel situation? it would be
greatly appreciated if somebody can shed me some light on this.

VPN server CISCO VPN concentrator 3000,
VPN client CISCO VPN client v4.7 on windows xp.

I noticed that once I establish a tunnel with concentrator, a virtual
interface get activated and routing table get changed.
For example.
my physical interface ip 10.1.1.1 gateway 10.1.1.254
routing table(omit loopback and broadcast/multicast entries):
network 0.0.0.0 mask 0.0.0.0 gateway 10.1.1.1.254 interface
10.1.1.1 metics 1

Once VPN tunnel established(Tunnel All traffics in this case) with VPN
server IP as 192.168.1.254
virtual interface IP 192.168.1.1 gateway 192.168.1.254
routing table(omit loopback and broadcast/multicast entries):
network 0.0.0.0 mask 0.0.0.0 gateway 192.168.1.254 interface
192.168.1.1 metrics 1
network 192.168.1.254 mask 255.255.255.255 gateway 10.1.1.254
interface 10.1.1.1 metrics 1

I understand that all traffic will be routed then to the virtual
interface which tunnels it to vpn server.

My question here is:
What will happen if we manually add a route to the routing table as
following
network 172.16.1.8 mask 255.255.255.255 gateway 10.1.1.254 interface
10.1.1.1 metrics 1

I tried this, the connection will not go, I am wondering where the
traffic gets dropped? Is it in the VPN client computer TCP/IP stack? Or
at the end of the tunnel VPN server dropped the unprotected traffic?
How does the routing process work during the whole process?

Question continued,
Similar scenario.


my physical interface ip 10.1.1.1 gateway 10.1.1.254
routing table(omit loopback and broadcast/multicast entries):
network 0.0.0.0 mask 0.0.0.0 gateway 10.1.1.1.254 interface
10.1.1.1 metics 1

Once VPN tunnel established(split-tunnel in this example, only tunnel
192.168.2.0/24.) with VPN server IP as 192.168.1.254
virtual interface IP 192.168.1.1 gateway 192.168.1.254
routing table(omit loopback and broadcast/multicast entries):
network 0.0.0.0 mask 0.0.0.0 gateway 10.1.1.1.254 interface 10.1.1.1
metics 1
network 192.168.2.0 mask 255.255.255.0 gateway 192.168.1.254 interface
192.168.1.1 metrics 1
network 192.168.1.254 mask 255.255.255.255 gateway 10.1.1.254
interface 10.1.1.1 metrics 1

All traffic destined for 192.168.2.0/24 network is routed to virtual
interface thus tunnelled. All other traffic is routed to physical
interface and unprotected.

My question here is:
What will happen if we manually add two routes to the routing table as
following

which add the following entry to the routing table:
network 172.16.1.8 mask 255.255.255.255 gateway 192.168.1.254 interface
192.168.1.1 metrics 1
network 192.168.2.8 mask 255.255.255.255 gateway 10.1.1.254 interface
10.1.1.1 metric 1

I tried the similar scenario in real split-tunnel VPN connection,
manually redirect the first similar situation(Redirect plain traffic to
the virtual interface) will not go anywhere, is it dropped by virtual
interface or VPN server?
manually redirect the second similar situation(Redirect supposedly
protected traffic to the physical interface) go to the destination
without VPN tunnelling. How that occured? So VPN client does not
mandate the protected traffic to virtual interface?


Posted by Lutz Donnerhacke on July 28, 2006, 4:23 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
* ricecs@gmail.com wrote:
> I tried this, the connection will not go, I am wondering where the
> traffic gets dropped? Is it in the VPN client computer TCP/IP stack? Or
> at the end of the tunnel VPN server dropped the unprotected traffic?

The VPN server will drop protected packetes, which should be unprotected
(from its knowledge) and vice versa. In order to transport packets through a
tunnel, BOTH ends must know, which addresses are involved.

> How does the routing process work during the whole process?

It works as observed.

> I tried the similar scenario in real split-tunnel VPN connection,
> manually redirect the first similar situation(Redirect plain traffic to
> the virtual interface) will not go anywhere, is it dropped by virtual
> interface or VPN server?

VPN server.

> manually redirect the second similar situation(Redirect supposedly
> protected traffic to the physical interface) go to the destination
> without VPN tunnelling. How that occured? So VPN client does not
> mandate the protected traffic to virtual interface?

The VPN client is a device driver which only works with traffic comming
through the virtual interface. If you bypass this by manual configuration,
the VPN clients can't notice it and therefore will not encrypt it.

Usually a VPN client is able to prevent manual routing entries anyway.

Posted by on July 29, 2006, 12:18 am
If you were  Registered and logged in, you could reply and use other advanced thread options

Lutz Donnerhacke wrote:
> * ricecs@gmail.com wrote:
> > I tried this, the connection will not go, I am wondering where the
> > traffic gets dropped? Is it in the VPN client computer TCP/IP stack? Or
> > at the end of the tunnel VPN server dropped the unprotected traffic?
>
> The VPN server will drop protected packetes, which should be unprotected
> (from its knowledge) and vice versa. In order to transport packets through a
> tunnel, BOTH ends must know, which addresses are involved.
Since I redirect the specific traffic to the physical interface
bypassing the virtual interface, is the traffic still sent to VPN
server via the tunnel? If it's the case, how the traffic get the
destination IP address encapsulated in a ip header of VPN server?


>
> > How does the routing process work during the whole process?
>
> It works as observed.
>
> > I tried the similar scenario in real split-tunnel VPN connection,
> > manually redirect the first similar situation(Redirect plain traffic to
> > the virtual interface) will not go anywhere, is it dropped by virtual
> > interface or VPN server?
>
> VPN server.
>
> > manually redirect the second similar situation(Redirect supposedly
> > protected traffic to the physical interface) go to the destination
> > without VPN tunnelling. How that occured? So VPN client does not
> > mandate the protected traffic to virtual interface?
>
> The VPN client is a device driver which only works with traffic comming
> through the virtual interface. If you bypass this by manual configuration,
> the VPN clients can't notice it and therefore will not encrypt it.
>
> Usually a VPN client is able to prevent manual routing entries anyway.


Posted by Lutz Donnerhacke on July 29, 2006, 3:11 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
* ricecs@gmail.com wrote:
> Since I redirect the specific traffic to the physical interface
> bypassing the virtual interface, is the traffic still sent to VPN
> server via the tunnel?

No.

> how the traffic get the destination IP address encapsulated in a ip
> header of VPN server?

ESP encapsulated the whole packet including the IP addresses.


Similar ThreadsPosted
IPsec Virtual Tunnel Interfaces April 10, 2007, 9:43 am
Virtual Tunnel Interface Flapping - Route Redistribution: static->RIP->OSPF July 12, 2007, 2:44 pm
GRE/IPSEC Tunnel and loopback interface April 30, 2007, 7:01 am
Cisco 871 : NAT virtual interface May 16, 2006, 7:57 am
Rather complicated PIX, ipsec, and multiple interface question... July 2, 2005, 8:57 pm
virtual tunnel interfaces / crypto maps June 11, 2008, 12:23 pm
Re: Virtual ethernet interface October 3, 2007, 1:39 pm
MIB to clear virtual-interface via SNMP? February 13, 2005, 6:47 pm
Virtual Interface Sequence Number April 28, 2005, 11:51 pm
site to site IPSEC Tunnel question problem with NAT T November 2, 2006, 3:01 pm

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map