Incorrect Default Gateway for Clients using a Concentrator

[andrewburridge]

Hey all,

Hopfully an easy one - I'm trying to configure a VPN Concentrator for use with the old VPN Client for an IPSec CVPN.

The clients connect fine, but they are getting the incorrect default gateway during the address assignment.

My address pool is 192.168.0.128/25.  The client correctly picks up the first address in the range, 192.168.0.129, but the default gateway for the VPN adapter is assigned as the next address in the range, 192.168.0.130.

I need the gateway address to be 192.168.0.254 (the SVI of the L3 switch connected to the Concentrator), but I can't for the life of me fine a configuration option anywhere in the pool assignment.  I've set the tunnel default gateway to this 192.168.0.254, but this makes no difference.

Any ideas where I can find this config option?

Thanks!

[Herbert Baerten]

Andrew,

the default gateway on the client's tunnel interface is just a dummy address - it is not actually used since the client will encrypt the traffic and send it to the concentrator's public ip address.

So if this was just a concern, you can just ignore it.

If you were looking at this because of a problem, we'll need to look in a different direction. If so, please post more details.

hth

Herbert

[andrewburridge]

Hi Herbet,

Thanks for your reply.  I guess my question could be condensed down to:

'how do I specify a default gateway address for my connecting vpn clients'.

I can't seem to find the configuration option to specify this anywhere.

Thanks,

Andy

[Richard Burts]

Andy

There is not an option on the concentrator to configure the gateway for clients (and Herbert gives a good explanation for why it is not needed).

Can you tell us why you are concerned about the gateway address?

HTH

Rick

[andrewburridge]

Hey Rick,

Thanks for your reply.  Perhaps I'm thinking about this the wrong way, please let me know if so.

Essentially, I have a concentrator with a public IP and a LAN ip, 192.168.0.254.  The concentrator has the default route set to the public interface, and a route to 192.168.0.0/25 via the layer 3 switch that it is connected to, 192.168.0.254.

When a client connects, they get assigned an address from the pool as follows:

IP: 192.168.0.129

SM: 255.255.255.128

DG: 192.168.0.130 (I haven't set this anywhere)

Now the client can ping the interfaces on its local LAN (concentrator interface 192.168.0.253, and the L3 switch, 192.168.0.253), but it cannot reach the rest of our internal LAN behind the layer 3 switch.

Now I'm presuming that this is because of the default gateway setting that the client is picking up, and I wanted to resolve this by giving it the default gateway as the IP of the layer 3 switch.  If there is another way of accomplishing what I require (full connectivity to the LAN) then please let me know.

Hope this makes sense.

Andrew Burridge

[Richard Burts]

Andrew

I do believe that there is a flaw in the way that you are looking at the problem. It is intuitive to believe that the client default gateway is faulty and is the cause of the connectivity problems. But I believe that this is not the case. As

Herbert explained, the client does not really use the gateway address but just encrypts and sends all data over the tunnel. In this sense it is really acting more like a point to point connection (which a tunnel is) and does is not concerned with the address at the end of the tunnel and just sends its data through the tunnel.

I believe that the problem is more likely on the concentrator. You mention that you have a default route configured on the concentrator. Do you also have a default route (or any other route) configured using the "tunneled" parameter? the "tunneled" routes are how the concentrator routes traffic from clients and my guess is that you do not have a tunneled route for the traffic from theclient to these destinations.

HTH

Rick

[Herbert Baerten]

Thanks for jumping in Rick
I agree that this is most likely a routing issue and so indeed first thing to check is if the concentrator has a route to

192.168.0.0/25 pointing to the L3 switch (or a "tunneled" default route as Rick mentions).

I just wanted to add that the problem could also be with the return traffic; so I wanted to ask if the L3 switch has a route back to the client pool, when I realized the pool is actually overlapping the network used between the concentrator and the L3 switch and so the switch will see this as directly connected and will arp for the pool addresses. That means the concentrator would have to do proxy arp for these pool addresses and off the top of my head I'm not sure if it does that (are we talking about a VPN3000 concentrator by the way?).

Could you try changing the pool to something else, and make sure that the L3 switch has a route towards this new pool, with the concentrator as next hop?

hth

Herbert

[andrewburridge]

Hi Guys,

Thanks for your continued support on this.  Sorry Herbert, but I made a little mistake in explaining the routing to you.  Hopefully this diagram will help:

I'm fairly confident that routing between the concentrator and the internal network is fine, as I can contact the web server on the private interface and manage the concentrator from my internal network. 

My routing table looks as follows:

Rick, thanks for your explanation - that does make sense.  I guess the only thing is that I haven't explicitly configured a route using the tunnelled parameter.  I'm not quite sure what you mean by this, and I can't see an option for it.  The only option I can see that is similar is the tunnel default gateway which is set to 192.168.0.254 (as we have already discussed).

This is a 3015 model incidentally.

Thanks.

[Herbert Baerten]

Well my previous suggestion still stands - since the client pool is overlapping with your private interface's lan (they both use 192.168.0.128/25), I would suggest giving it a try with a different pool - and make sure that the L3 switch has a route to this new pool (using 192.168.0.253 as next hop).

(BTW your diagram shows 255.255.255.0 as the client mask, which should be 255.255.255.128 I believe, I don't expect this to matter though).

On another note - if your internal LAN is really 192.168.0.0/16 then the private interface of the vpn3k would be in there so I don't see how you could possibly reach the web interface - so I assume it's not an entire /16 but subnetted?

hth

Herbert

[andrewburridge]

Hi Herbert,

Ok, I've changed the VPN pool addressing and still no dice.  Don't suppose you have an further ideas?

The only thing I notice is that on the concentrator there is no route for the address pool.  If I add one it doesn't make a difference either way, but I'm wondering if there should be one.

Oh, and the 192.168.0.0/16 network is just a summary for all the networks behind that L3 device, they are all subnetted.

Thanks,

[Richard Burts]

Andrew

In the chart that you posted about the routing setup it refers to a DMZ network and DMZ gateway. Can you clarify what these are since I do not see them in the drawing that is in that post?

I agree with Herbert that it is cleaner to have the address pool on the concentrator use addresses that do not overlap with the concentrator subnet connecting to the layer 3 switch. And as long as the layer 3 switch has a route to that address pool, and the next hop in the route is the address of the concentrator interface then the separate pool addressing should work just fine.

I have re-read this thread and want to make sure that after some changes that you have made that the problem symptoms are still the same. You told us earlier that: "Now the client can ping the interfaces on its local LAN (concentrator  interface 192.168.0.253, and the L3 switch, 192.168.0.253), but it  cannot reach the rest of our internal LAN behind the layer 3 switch." Is this still an accurate statement of the problem?

As Herbert said earlier this could either be caused by the concentrator not have a correct route for the inside or it could be  because the inside does not have a correct route to the client. In re-reading your description of the routing set up it looks like the concentrator has a default route configured but not the tunnel default route. May I suggest that you try configuring a tunnel default route (in addition to the normal default route) and see whether that makes any difference?

If that does not help the problem then I would suggest that you verify that the devices on the inside do have their default gateway set correctly and that the layer 3 switch does have a route for the VPN address pool with the concentrator interface address as the next hop.

HTH

Rick

[edit] I just focused on the question that you asked about the concentrator possibly needing a route for the address pool. The concentrator does not need any route statements for the address pool - it knows its own address pool, pretty much like having a connected interface subnet. The layer 3 switch is what needs a route for the address pool.

[Richard Burts]

Andrew

I looked again at the drawing that you posted and have a question about it. You show 192.168.0.0/16 as being subnetted for your inside network. Are all the subnets connected through that layer 3 switch or are there other devices providing routing for the inside of your network?

If there are other devices that are providing routing for the inside network, then can you check and see whether they have routes for the address pool on the concentrator?

HTH

Rick

[andrewburridge]

Hey guys,

OK, the 'DMZ Network' is what I'm referring to the network that the public ip of the concentrator is on.  It's basically the internet routeable IP of the box and the network that resides on, so I'm sure you understand why I'm masking it (not that I don't trust you guys!).

The L3 switch has a route to the CVPN address pool via the concentrator private IP.  If I run a traceroute from my internal client, I can confirm that this is working as it should, and the last hop in the trace is the concentrator itself.

The actual scenario is a little different now.  the client still cannot see the wider network, but it now also cannot ping the private interface of the concentrator (now on a different subnet) or go any further.  Does the concentrator definitely not need a route for the address pool?  I understand that it should know about its own address pool, similar to how a switch would learn about connected routes automatically, but they would still end up in the routing table.  The routing table for the concentrator doesn't have the address pool subnet in.

Just to confirm, the 'tunnel default route' you mention, is this the same config as the tunnel default gateway in the System --> IP Routing -->  Default Gateways menu?  This is set to the private IP of the concentrator. 

Thanks!

[Richard Burts]

Andrew

Yes what I am referred to as tunnel default route is the same as the tunnel default gateway in the System -> IP Routing -> Default Gateway menu.

HTH

Rick

[andrewburridge]

Hey Rick,

Ok cool, so long as we're talking about the same thing!  That is set to the Private LAN IP of the concentrator, so I'm presuming that is correct.

Andy