cisco VPN ipsec tunnel virtual interface operation detail question

Discussion in 'Cisco' started by ricecs@gmail.com, Jul 28, 2006.

  1. Guest

    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?
     
    , Jul 28, 2006
    #1
    1. Advertising

  2. * 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.
     
    Lutz Donnerhacke, Jul 28, 2006
    #2
    1. Advertising

  3. Guest

    Lutz Donnerhacke wrote:
    > * 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.
     
    , Jul 29, 2006
    #3
  4. * 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.
     
    Lutz Donnerhacke, Jul 29, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Ireland
    Replies:
    1
    Views:
    1,091
    Claude LeFort
    Nov 11, 2003
  2. a.nonny mouse
    Replies:
    2
    Views:
    1,126
  3. AM
    Replies:
    7
    Views:
    4,457
    kh_alex81
    Jul 19, 2007
  4. Trouble
    Replies:
    0
    Views:
    658
    Trouble
    Aug 4, 2006
  5. Trouble
    Replies:
    1
    Views:
    559
Loading...

Share This Page