«

Hi guys,

I'm setting up our PIX 525 (running 6.3(3)) to allow remote pcs with cisco
vpn client 4.04 to connect to it and access our internal network. Our
clients are mostly XP boxes. The clients have successfully connected to the
internal network via the PIX using IPSEC tunnelling, however when they are
assigned an ip address by the PIX, they end up with the incorrect subnet
mask. Our address pool is 172.16.6.16- 172.16.6.254, and an address from
this pool is assigned to the remote client when it connects, however the
subnet mask defaults to 255.255.0.0, which is incorrect (we are using a mask
of 255.255.255.0). My question is therefore, how to change the PIX
configuration so that it assigns the correct subnet mask of 255.255.255.0 to
the client, and not 255.255.0.0? Is it possible to change it? If not, what's
the workaround for this problem?

thanks,
woon

Given that the pool of addresses is from your "inside" address range, then I
would guess it uses the same netmask as you defined in the "ip address"
command that sets the network / netmask on your inside interface.

I can't see any mention anywhere else on setting the netmask.

paul




"Woon" <> wrote in message
news:...
> Hi guys,
>
> I'm setting up our PIX 525 (running 6.3(3)) to allow remote pcs with cisco
> vpn client 4.04 to connect to it and access our internal network. Our
> clients are mostly XP boxes. The clients have successfully connected to
the
> internal network via the PIX using IPSEC tunnelling, however when they are
> assigned an ip address by the PIX, they end up with the incorrect subnet
> mask. Our address pool is 172.16.6.16- 172.16.6.254, and an address from
> this pool is assigned to the remote client when it connects, however the
> subnet mask defaults to 255.255.0.0, which is incorrect (we are using a
mask
> of 255.255.255.0). My question is therefore, how to change the PIX
> configuration so that it assigns the correct subnet mask of 255.255.255.0
to
> the client, and not 255.255.0.0? Is it possible to change it? If not,
what's
> the workaround for this problem?
>
> thanks,
> woon
>
>

On Tue, 18 May 2004 05:07:35 -0500, Woon wrote:

> Hi guys,
>
> I'm setting up our PIX 525 (running 6.3(3)) to allow remote pcs with
> cisco vpn client 4.04 to connect to it and access our internal network.
> Our clients are mostly XP boxes. The clients have successfully connected
> to the internal network via the PIX using IPSEC tunnelling, however when
> they are assigned an ip address by the PIX, they end up with the
> incorrect subnet mask. Our address pool is 172.16.6.16- 172.16.6.254,
> and an address from this pool is assigned to the remote client when it
> connects, however the subnet mask defaults to 255.255.0.0, which is
> incorrect (we are using a mask of 255.255.255.0). My question is
> therefore, how to change the PIX configuration so that it assigns the
> correct subnet mask of 255.255.255.0 to the client, and not 255.255.0.0?
> Is it possible to change it? If not, what's the workaround for this
> problem?
>
> thanks,
> woon

AFAIK, you cannot.

Is this causing a problem?

"Woon" <> wrote in message
news:...
> Hi guys,
>
> I'm setting up our PIX 525 (running 6.3(3)) to allow remote pcs with cisco
> vpn client 4.04 to connect to it and access our internal network. Our
> clients are mostly XP boxes. The clients have successfully connected to
the
> internal network via the PIX using IPSEC tunnelling, however when they are
> assigned an ip address by the PIX, they end up with the incorrect subnet
> mask. Our address pool is 172.16.6.16- 172.16.6.254, and an address from
> this pool is assigned to the remote client when it connects, however the
> subnet mask defaults to 255.255.0.0, which is incorrect (we are using a
mask
> of 255.255.255.0). My question is therefore, how to change the PIX
> configuration so that it assigns the correct subnet mask of 255.255.255.0
to
> the client, and not 255.255.0.0? Is it possible to change it? If not,
what's
> the workaround for this problem?
>
> thanks,
> woon
>
>


Your VPN address pool does not need to be in the same network as your
internal IP range so it really shouldn't matter what the mask is.

Chris.

Hi, let me give more details on the problem:

Topology:

Outside (internet) ---------------- PIX
525 --------------------- inside (172.16.1.x/24) -------------------
Internal RSM (with 172.16.6.0/24 and 172.16.1.0/24)

I'm trying to get the pix to assign a ip address from the 172.16.6.0/24
pool, range 172.16.6.16 to 172.16.6.250 say, with subnet mask /24. Here's
the relevant config for the PIX. Where am i going wrong? The pix assigns say
ip 172.16.6.16 to the vpn client, gateway 172.16.6.16, but subnet mask /16.
Our network is all subnet 24 vlans.

tq

-- snip--
ip local pool VPNPOOL 172.16.6.16-172.16.6.254
nat (inside) 0 access-list NO_NAT
route inside 172.16.0.0 255.240.0.0 172.16.1.1 1 //where 172.16.1.1 is the
pix inside interface ip
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ (inside) host xxyx password timeout 10
sysopt connection permit-ipsec
sysopt noproxyarp inside
auth-prompt prompt show flashfs
auth-prompt accept OK, You've been accepted.
crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec transform-set AAAAES ah-md5-hmac esp-aes-256 esp-md5-hmac
crypto dynamic-map DYNAMAP 10 set transform-set AAAAES
crypto dynamic-map outside_dyn_map 20 match address outside_cryptomap_dyn_20
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-AES-256-MD5
crypto dynamic-map outside_dyn_map 40 match address outside_cryptomap_dyn_40
crypto dynamic-map outside_dyn_map 40 set transform-set ESP-AES-256-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map client authentication TACACS+
crypto map outside_map interface outside
isakmp enable outside
isakmp identity address
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes-256
isakmp policy 20 hash md5
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
vpngroup Woontest address-pool VPNPOOL
vpngroup Woontest dns-server <ip1> <ip2>
vpngroup Woontest wins-server <ip1> <ip2>
vpngroup Woontest default-domain staff
vpngroup Woontest idle-time 1800
vpngroup Woontest password ********
-- snip--

On Tue, 18 May 2004 05:07:35 -0500, Woon wrote:

> Hi guys,
>
> I'm setting up our PIX 525 (running 6.3(3)) to allow remote pcs with
> cisco vpn client 4.04 to connect to it and access our internal network.
> Our clients are mostly XP boxes. The clients have successfully connected
> to the internal network via the PIX using IPSEC tunnelling, however when
> they are assigned an ip address by the PIX, they end up with the
> incorrect subnet mask. Our address pool is 172.16.6.16- 172.16.6.254,
> and an address from this pool is assigned to the remote client when it
> connects, however the subnet mask defaults to 255.255.0.0, which is
> incorrect (we are using a mask of 255.255.255.0). My question is
> therefore, how to change the PIX configuration so that it assigns the
> correct subnet mask of 255.255.255.0 to the client, and not 255.255.0.0?
> Is it possible to change it? If not, what's the workaround for this
> problem?
>
> thanks,
> woon

I looked into this some more and it appears to a problem with the 4.x
client (which uses virtual adapter). The client does have the ability to
request a mask, but the pix has no method of assigning it. The VPN3000
should have this ability (but it appears broken due to CSCeb83746).

In any event, it looks like you will have to go to a pool that does not
overlap your internal destinations.

HTH,

Rik Bain

Does that mean we are unable to assign a 172.16.x.x/24 ip address to a vpn
client?? Our internal network uses 172.16.x.x/24 addresses, it'd be kinda
strange to introduce a /16 ip or a smaller subnet e.g. 192.168.1.0/24.
Anyone has a workaround for this?


"Rik Bain" <> wrote in message
news:40ab6ff7$0$1768$ om...
> On Tue, 18 May 2004 05:07:35 -0500, Woon wrote:
>
> > Hi guys,
> >
> > I'm setting up our PIX 525 (running 6.3(3)) to allow remote pcs with
> > cisco vpn client 4.04 to connect to it and access our internal network.
> > Our clients are mostly XP boxes. The clients have successfully connected
> > to the internal network via the PIX using IPSEC tunnelling, however when
> > they are assigned an ip address by the PIX, they end up with the
> > incorrect subnet mask. Our address pool is 172.16.6.16- 172.16.6.254,
> > and an address from this pool is assigned to the remote client when it
> > connects, however the subnet mask defaults to 255.255.0.0, which is
> > incorrect (we are using a mask of 255.255.255.0). My question is
> > therefore, how to change the PIX configuration so that it assigns the
> > correct subnet mask of 255.255.255.0 to the client, and not 255.255.0.0?
> > Is it possible to change it? If not, what's the workaround for this
> > problem?
> >
> > thanks,
> > woon
>
> I looked into this some more and it appears to a problem with the 4.x
> client (which uses virtual adapter). The client does have the ability to
> request a mask, but the pix has no method of assigning it. The VPN3000
> should have this ability (but it appears broken due to CSCeb83746).
>
> In any event, it looks like you will have to go to a pool that does not
> overlap your internal destinations.
>
> HTH,
>
> Rik Bain

Hi ng,

> Does that mean we are unable to assign a 172.16.x.x/24 ip address to a vpn
> client?? Our internal network uses 172.16.x.x/24 addresses, it'd be kinda
> strange to introduce a /16 ip or a smaller subnet e.g. 192.168.1.0/24.

it seems so. Today I run into the same problem (same pix, same OS)
Is there a workaround outthere?

In my case there is public address space available - formaly class B
(e.g. 141.141.0.0/16) - now subneted - lets say an university address
space. Every IP device has its own public ip address. If I use a small
subnet for the vpn thing, all vpn clients will get a class b mask -
not that funny. A testconfig with private address space works very
well - for sure - no overlaps.

Now I have to explain why they have to change their public address
routing policy (routed to null), just because the pix can not provide
a subnet mask to the client.

Does anybody know a reason, why the pix should or should not provide a
subnet mask to the vpn client? Or is ist just a missing feature?

Cheers
Hendrik Danz

[NeverOutofTune]

You can add a mask in v6.3 code

> ip local pool VPNPOOL 172.16.6.16-172.16.6.254

change to:

ip local pool VPNPOOL 172.16.6.16-172.16.6.254 mask 255.255.255.0