|
Home > Archive > VPN > November 2005 > VPN - Same IP's
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| jslarose@cheerful.com 2005-11-17, 5:53 pm |
| Hi,
Have a stupid question ...
We have a vpn at work using a cisco Pix and the network has an ip range
of 192.168.1.1, etc ... I have several users who are logging into the
vpn from home computers. Some of these computers I have had to change
the ip address range to be different then the work network range to
avoid conflict ... I would use 192.168.0.1 range
This seems to work ok so far ... have a question on the effects of
several home users logging in with the same ip address though. What
happens when several home users that have been assigned 192.168.0.1 by
their home routers all log into the vpn at the same time? Does this
create any conflicts or is this not even a factor when using vpn?
thanks,
JL
| |
| Stephen J. Bevan 2005-11-18, 2:46 am |
| jslarose@cheerful.com writes:
> This seems to work ok so far ... have a question on the effects of
> several home users logging in with the same ip address though. What
> happens when several home users that have been assigned 192.168.0.1 by
> their home routers all log into the vpn at the same time? Does this
> create any conflicts or is this not even a factor when using vpn?
I don't know about a PIX specifically but the following are
possibilities :-
a) the PIX would reject the connection of the *second* user using
192.168.0.1 to avoid the possibility of a routing conflict.
b) the PIX will allow multiple users to connect with 192.168.0.1 but
this will result in a routing conflict so either all traffic to
192.168.0.1 will go to one of the users or it will flap back and
forth causing TCP connections to fail and traffic to be lost.
c) the PIX has been configured to dynamically NAT all remote subnets
to another IP range to ensure that everyone appears to have a
unique subnet and so avoid a routing conflict.
| |
|
| jslarose@cheerful.com wrote:
> Hi,
>
> Have a stupid question ...
>
> We have a vpn at work using a cisco Pix and the network has an ip range
> of 192.168.1.1, etc ... I have several users who are logging into the
> vpn from home computers. Some of these computers I have had to change
> the ip address range to be different then the work network range to
> avoid conflict ... I would use 192.168.0.1 range
>
> This seems to work ok so far ... have a question on the effects of
> several home users logging in with the same ip address though. What
> happens when several home users that have been assigned 192.168.0.1 by
> their home routers all log into the vpn at the same time? Does this
> create any conflicts or is this not even a factor when using vpn?
>
> thanks,
>
> JL
>
I can't see a problem as each of the home users will have had their 192
local addresses natted to the wan address of their router, it's this
address the pix will see the tunnel request coming from, not the 192 one.
Simon
| |
| jslarose@cheerful.com 2005-11-18, 5:47 pm |
| Wasn't quite sure what it would do. What I did find out was that the
home users could not use the 192.168.1.x range ... it would allow the
vpn to connect but no traffic would actually pass. The problem was
fixed once I moved the home users onto the 192.168.0.x range. Just
wanted to make sure that if they happened to all have the same address
on their home machine that it wouldn't create an issue ... I guess it
wouldn't if it got natted to the wan of the router
thanks for the replies .. I appreciate it ...
| |
| Draschl Clemens 2005-11-24, 2:46 am |
| Simon wrote:
> I can't see a problem as each of the home users will have had their 192
> local addresses natted to the wan address of their router, it's this
> address the pix will see the tunnel request coming from, not the 192 one.
> Simon
in esp-tunnel mode (which you'll be using) the initiator proxy is a 192,
which the pix will see. esp takes the whole ip-packet, encrypts it and
adds a new header, which is modified by the pix's nat-mechanism.
why this _could_ work:
* host-routes are higher-weighted than network-routes
* inbound-nat on ipsec-packets
* nat-traversal
the solution to bypass this problem is to use ike-config. the pix gives
a dhcp-address to the ipsec-client, and _only_ to the ipsec-client.
doesn't provide dhcp to normal lan users. you have to modify the
access-lists to pass the virtual ip's. and the client has to be
configured to obtain a virtual ip-address.
\cd
|
|
|
|
|