HP3000-L Archives

April 2011, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Thu, 21 Apr 2011 12:39:19 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
On 4/21/2011 12:32 PM, Tom Hula wrote:
> Thank you. I will research how VPN works on those Secure Computing Snap Gear routers
> and see if there is an issue there. I know that the IP addresses that are assigned to
> the VPN access are 192.168.100.x addresses and that is the same as what is being used
> internally. Still, there is a firewall on that router as well and maybe that is the
> root of the problem.

Check on how your VPNs are advertising routes back to the clients, especially if you are
doing split-tunnel VPNs, and particularly if you are spanning two VPN hops (which it
sounded like if I followed your explanation correctly).

Full VPN works by sending *all* traffic through the tunnel, so there are no routing
anomalies.

Split-tunnel VPN works by the VPN server sending back routes to the connecting client
specifying which subnets are to be passed over the tunnel.

If the second hop is split, it may not have routes to the far end (destination) subnets
in a split-tunnel situation.

Also, some of these sound rather site-to-site; over a given point-to-point link you can
only have one VPN session active at a time (full IPsec VPN with traditional ISAKMP on
UDP/500 only maps to one host at a time).

Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2