Understanding VPN on a general level for a beginner.

[SJ K]

Hi all,

This question isn't really particularly tied to any Cisco VPN / firewall product.
But I would really hope to seek clarifications with regards to the general workings of a VPN tunnel from gurus here..

So here we go...

I understand that  (encryption aside), VPN tunnels embeds the actual source and destination (e.g. internal network) of a network packet with the public internet address between the VPN client and the VPN server.

For example, on site A, i would have a 192.168.10.0/24 private network and i would like VPN clients connections to site A to be part of this 192.168.10.0/24 network. The gateway for this network is a L3 coreswitch - 192.168.10.254 which will then routes to other internal network/resources.

As shown in my illustration below,  i have an internet router that does not support VPN, hence i have to setup another VPN behind it with a public IP

My question is ->

 if there is a route install in my VPN client with

192.168.4.0  255.255.255.0  192.168.10.254

Does that means my "internet" packet will still be send to the VPN server, but the VPN server will then "unwrap" it and "forward" it to the L3 coreswitch gateway IP - 192.168.10.254 ?

e.g. embedded packet A from VPN client machine

[src] [dest] [payload]

[192.168.10.50] [192.168.4.3][icmp]

final packet

[public src][public dest][embbeded packet A]

[63.216.23.24][202.202.202.10] [192.168.10.50][192.168.4.3][ICMP]

q1) What i meant is, the final packet is send through the internet to the VPN server (202.202.202.10), how does the VPN server then carry on to forward the packet to the L3 gateway then ? surely it need some sort of forwarding/routing capability right ?

In general how does, the embedded packet A get forwarded to the VPN server, then to the L3 core switch -> to the intended destination 192.168.4.3 ?

-- or is it that i must setup/allocate an entire separate VPN subnet for the VPN client and VPN server; and the gateway for the VPN client to all the other internal networks will be to the VPN server (and not the L3 coreswitch), with the VPN server having the routes to another internal network through to the L3 coreswitch instead ?

Regards,
Noob

[SJ K]

Anyone ? :(

[David_Che]

In general, one default route like ' ip route 0.0.0.0 0.0.0.0 tunnel1 (ipsec tunnel) ' will be installed on remote ipsec client.  The mentioned route '192.168.4.0  255.255.255.0  192.168.10.254' will be recursive lookup until it hit the default route. So the tunneled packet will be sent over the IPsec tunnel. when the packet arrived at IPsec gateway, the outer IP header will be removed and IP route lookup will serve only for the inner IP packet. it is reasonable that ASA know how to reach 192.168.4.0 by its IGP routing.

For site to site IPsec deployment, after ipsec tunnel (not using crypto-map, using tunnel protection mode) was setup, then setup IGP neighbor between IPsec peer, advertise site specific route to each other, the ipsec tunnel can be seen as logical link, packet forwarding was no difference with other physical link.

[Marvin Rhoads]

The routes installed on your host when connected to the remote access VPN are determined by the VPN Server configuration. It may be certain subnets or hosts (this setup is called "split tunnel" as the traffic is split between that which is tunneled and everything else) or it may be all routes (no split tunnel)

For the remote addresses that need to use VPN, it will install routes saying to use the public IP of the "VPN Server". It will encrypt / encapsulate the traffic in SSL or IPsec (two most common methods) and send it on to the VPN server which knows to unencrypt / decapsulate it.

The gateway(s) the VPN server uses on the remote network are not apparent to your client PC. The VPN server has its own routes which may be defined statically or it may participate in an Interior Gateway Protocol (IGP) like EIGRP or OSPF.

You don't need a dedicated subnet for your VPN client addresses, just unique addresses that the remote systems know how to reach (e.g. via the VPN server).

[SJ K]

Hi Marvin,

So sorry for the late reply and a million appreciation and thanks for the straight to the point explanation.  I hope you are still around...

Would you mind to clarify abit further on the below

For the remote addresses that need to use VPN, it will install routes saying to use the public IP of the "VPN Server"

q1) to use the public IP of  "VPN Server" as the ? ( is the answer "gateway")  ?

q2) i would believe routes that need to be encrypted/routed, will use the tunnel interface (on the vpn client/host) as the exit interface, and that tunnel interface will encapsulate and send traffic to the VPN server)  -- right ?

q3) However, the point of confusion is that when traffic reach the VPN server which decapsulate the packet and realize that the packet wasn't meant for itself, surely it would need some sort of routing / forwarding capability right ?  -- thus can i say VPN server ( must somehow do "routing"  as well ) ?

q4) and here come the last bit,  from what i know,  traffic to different destination network from source are routed. is it possible for the scenario below

vpn client (host)'s vpn/tunnel interface ip   -> 192.168.0.10

vpn client public ip -> 202.202.202.3

vpn server internal ip -> 192.168.0.11

vpn server public ip -> 63.63.63.4

vpn server side 's gateway -> 192.168.0.254  (a l3 switch to reach other network)

and the vpn client has a route to

192.168.40.0/24 network via the VPN server and send a ping to 192.168.40.1

Since the VPN client (192.168.0.10) is in the same subnet as the remote gateway (192.168.0.254) - Is traffic still send to the VPN server (192.168.0.11) ?

If yes, does that means the VPN server upon receiving and decapsulate the packet, realize that the destination is meant for a .40/24 network , will then route the packet to the gateway in the same subnet (192.168.0.254) ?

q5) if the answer to the above is a yes, does that means the VPN server is still consider as a hop, even though the vpn client, vpn server, l3 gateway are all in the same subnet  (is it possible for the vpn client , vpn server and the actual gateway behind the vpn server to be all in the same subnet) ?

and in the vpn client (host side)'s tunnel interface, there will not be a gateway entry for 192.168.0.254 ?

Regards,
Noob

[Marvin Rhoads]

Yes when VPN is established a tunnel interface becomes activated. All remote networks defined by VPN server configuration which are configured on client upon connection use that tunnel interface.

When the VPN server receives and decapsulate the packets, it routes them to the destination based on its internal routing logic, as defined in either static or dynamic routes.

The VPN server does not appear as a "hop" as the traffic was enacapsulated in the SSL or IPsec wrapper from the client to VPN server. The decapsulated packet appears to come from the client address in the VPN address pool. The remote VPN client does not ever know about the VPN server's  routing logic to remote internal networks. That is one of the functions of the VPN server.

[SJ K]

Hi Marvin,

Thanks for the marvellous reply and a Happy mayday to you.

q1) on the host/vpn client side, there is a tunnel interface whom ip address is allocated via/from the VPN address pool - am i right ?

is/will there be a similar tunnel interface created on the VPN server side ?

q2) can the allocated ip on the vpn client, and the vpn server, and the remote gateway (l3 switch) be in the same subnet ?

The intention that i want was to give my vpn client the same subnet range as all my other workstations in the office user network. (192.168.0.0/24) - and the VPN server is also inside this subnet.

i am wondering if the above is workable/true; when i use my vpn client to ping to another actual workstation in the office network (which is in the same 192.168.0.0/24) subnet; 

does it means that the packet will stlil go the VPN server to be decapsulated -> but what will happen when the VPN server realize that the packet is destined to a workstation in the same subnet as VPN server itself ?  will it still be able to forward/send out via its connected interface to the 192.168.0.0/24 subnet to the actual destined workstation ?

Regards,
Noob

[Marvin Rhoads]

Answer to q1: That's correct on the client side. On the VPN server side, not exactly. The hosts it assigns from the VPN pool appear to be on the VPN server. It will respond to any internal hosts wanting to send traffic to the VPN client addresses.

Answer to q2: Yes they can all be on the same subnet although that may be a bit confusing to anyone who doesn't know the setup since it won't be apparent that a given client isn't actually local.

The VPN server will know to decapsulate since the traffic is part of a security association whose rules are checked for this reason (among others).

[SJ K]

Hi Marvin,

Thanks and greatly appreciate your reply.

On answer1) Do you mean there will be something like a session table.. any traffic/packets to those client's IPs allocated via the VPN pool will be encapsulated and resend out to the VPN client.. - right ?

On answer 2) On having the client (ip from vpn pool), vpn server and the remote L3 gateway on the same subnet -> does that means that

If there is a workstation (192.168.0.20) on the actual site connected to the same switch/same subnet as the VPN server (192.168.0.0/24) network

Dong a ping from a VPN client (tunnel interface 192.168.0.10) - will result in the following path ->

vpn client -> vpn server -> workstation

The vpn client will send to the vpn server, the vpn server will decapsulate the packet; and see that it is destined to its connected network (192.168.0.0/24), and still forward the packet out to the workstation (192.168.0.20) - right ?

Regards,
Noob

[SJ K]

Hi Marvin,

Still there ? :)

Regards,

Noob

[Marvin Rhoads · Accepted solution]

Yes.Participation in this forum is a volunteer activity and often the day job will preempt quick replies.

There is "something like " a session table. Actually a set of IPsec security Associations (SAs) that the VPN appliance uses to keep track of the connected remote clients.

It represents to the local network(s) that those clients are on the appliance itself (even though they are actually remote) so the traffic to/from VPN clients and the local subnet(s) will never see the VPN appliance itself as being in the path (e.g., via traceroute output)

[SJ K]

Hi Marvin,

So sorry if i seems to be rushing you for a reply.

Greatly appreciate you taking time to reply my questions and a millions thanks.

Last , sorry to iterate , but i just want to confirm the idea that

when the vpn client (tunnel ip), vpn server and destination workstation are all in the same internal subnet, the vpn upon decapsulating the network packet - will still send the packet out of its connected interface to that subnet and to the workstation - right ?

Regards,
Noob

[Marvin Rhoads · Accepted solution]

Yes, that's correct.

[SJ K]

thank you marvin