Trouble routing to a different network segment over VPN

I added that:

Persistent Routes:
Network Address  Netmask        Gateway Address  Metric
172.21.0.0              255.255.0.0  192.168.250.49       1

But still can't ping 172.21.0.0/16 network:

Pinging 172.21.10.125 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 172.21.10.125:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Thanks for trying but there must be a working solution for this.

Best Regards,
Chris

OK. can you provide the output of a "route print" ? (from the command line)

Here's a route print output as requested:-

===========================================================================
Active Routes:
Network Destination                Netmask                Gateway                Interface                Metric
127.0.0.0                                 255.0.0.0               127.0.0.1                127.0.0.1                1
172.21.0.0                               255.255.0.0           192.168.250.49      192.168.250.49      1
192.168.1.0                             255.255.255.0       192.168.1.100        192.168.1.100        25
192.168.1.100                         255.255.255.255   127.0.0.1                127.0.0.1                25
192.168.1.255                         255.255.255.255   192.168.1.100        192.168.1.100        25
192.168.250.0                         255.255.255.0       192.168.250.49      192.168.250.49      25
192.168.250.49                       255.255.255.255   127.0.0.1                127.0.0.1                25
192.168.250.255                     255.255.255.255   192.168.250.49      192.168.250.49      25
224.0.0.0                                 240.0.0.0               192.168.1.100        192.168.1.100        25
224.0.0.0                                 240.0.0.0               192.168.250.49      192.168.250.49      25
255.255.255.255                     255.255.255.255   192.168.1.100        192.168.1.100        1
255.255.255.255                     255.255.255.255   192.168.250.49      192.168.250.49      1
===========================================================================
Persistent Routes:
Network Address                   Netmask                 Gateway Address                               Metric
172.21.0.0                               255.255.0.0           192.168.250.49                                     1

Was your VPN connected when you got the above routing table information? If not, could you please provide the same info, but when you are connected? I ask because I dont see a route in there to 172.20.0.0 which should show up when you connect to the VPN.

Also, just for verification, when the VPN is connected, can you connect to a 172.20.x.x device? (the main network)

Hi,

Yea sorry, school boy error. I previously did a 'route -f' after being connected so no wonder 172.20.0.0/16 wasn't showing! My apologies.

I'm now connected via VPN and, yes, I can access servers on 172.20.0.0/16 network. Please find attached a text file with my latest route print.

Thanks for your patience.

Chris

Ok, your routing table is correct! That's good. Can you do a tracert to a device on the 172.21.0.0 subnet and provide the output? Thanks.

Please find attached a tracert to a server on 172.21.0.0/16 network.

are you able to successfully tracert to a 172.16.0.0 device? From the 172.21.0.0. tracert it shows that either ICMP is disabled or there's the data's just not getting across the VPN.

Please find attached a tracert to a 172.20.0.0/16 device- all seems fine for this subnet.

Thanks again.

According to the windows routing table it should be working. I'm it's the way that the VPN is configured on the PIX/ASA/Concentrator that's only allowing traffic to 172.20.0.0 through the tunnel. Can you access the PIX/ASA/Concentrator? Or is this config'd by someone else?

I have access to the PIX via Cisco ASDM. However, I'm no PIX engineer! Is there anything you can suggest?

Do you have access to it via SSH? I'm not so keen with the ASDM, I'm a CLI kinda guy! (LOL) But actually I'll be out of the EE relm for the rest of the day today. What you'll be lookin for is a line as follows:
vpngroup [groupname] split-tunnel [#]
the above # correlates to an access-list that should look similar to
access-list [#] permit ip 172.20.0.0 255.255.0.0 192.168.250.0 255.255.255.0
You'll want to add to that
access-list [#] permit ip 172.21.0.0 255.255.0.0 192.168.250.0 255.255.255.0
This will put the route for 172.21.0.0 into the VPN itself.
I'll check back tomorrow to how it went.

Any luck?

Hello,

When you posted that I thought it all made sense. I then spent the next couple of hours trying to figure out why it wasn't working! I was using the ASDM at first but then tried the CLI route. I got as far as 'enable' and authenticating but couldn't figure out what commands to execute: if it was Solaris I might've had an clue!

So I have full root access via GUI and CLI but no idea from there. If you could guide me, obviously I'll increase the points for this question.

Thanks in advance,
Chris

And here's where I am using CLI.

can you provide a "show run" from the CLI of the PIX? Then I can see exactly how the split-tunnel is setup and define what commands need to be typed in. Thanks.
(pix#show run)

Please find attached the output of 'show run'.

Chris

Sorry for the delay, we went to lunch! But here's what you need:
1. login via SSH
2. use the following commands:
config t
access-list VPN-STAFF_splitTunnelAcl extended permit ip 172.21.0.0 255.255.0.0 any
exit
copy run start
then just hit enter for the default saved config name
3. Go ahead and reconnect your VPN.
4. bring up the VPN client console
5. click on Status
6. Click on the Route Details tab and you should see all the routes in it, including 172.21.0.0

Hello,

Thanks for your diligence! I did exactly as you said and I have the expected results but I still cannot ping the devices on that subnet. Sorry to be a nuisance! I've increased the points to 500 so I hope I can get this sorted soon- let me know if there's anything else I can do.

Best Regards,
Chris

Increased points.

Can you connect to a device on the 172.21.0.0 subnet? How does the data get from the PIX to the 172.21.0.0 network? Is there another router or firewall it goes through?

Hi,

I can't connect to a device on 172.21.0.0 subnet. We have an ISA server acting as a firewall but I looked yesterday for existing rules and it looked pretty empty. Do you think I may need to add a parameter to this? It's Microsoft's ISA Server.

Chris

How does the data get from the PIX to the 172.21.0.0 network? Is there another router or firewall it goes through? Also, can you try a tracert to the 172.21.0.0 network again, now that the route for it is coming from the PIX I'm hoping it gets to the PIX atleast and then maybe it dies off.

Also, I see a route in the PIX to the 172.21.0.0 network and it's going to 172.20.3.10 (what's this)?

Okay if I do a tracert it hits 172.20.3.10 which is a proxy server and also handles the extranet. You're right: it dies after that but at least it's getting somewhere! Funny thing is I can do a separate tracert and sometimes it reads extranet.upco.co.uk and other times upco-proxy.upco.co.uk; I'm assuming this is because they're essentially the same box with the same IP and the DNS will have duplicate entries for the host names.

Thanks again,
Chris

Alright, now we're getting somewhere. This proxy server, is that the ISA? We need to add a rule to it allowing traffic from 192.168.250.0/24 subnet to the 172.21.0.0/16 subnet. Then you should be able to access the 172.21.0.0 subnet !

No they're different servers. Basically the ISA server 10.250.250.10 and the proxy is 172.20.3.10. The proxy is just a virtual machine sat on a XEN server and I port stuff out on the extranet in a config file with vi-  I'm not aware of any rules on there but I've seen the ISA management console and there are a few rules setup there but I'm lost after that!

Can you login to a machine on the 172.20.0.0 subnet and do a tracert to a device on the 172.21.0.0 so we can see how it gets there?Thanks.

Interesting, it looks like it hits the proxy twice.

Well the routing is correct, so there's something in that proxy that's not allowing traffic from 192.168.150.0 to 172.21.0.0. What kind of proxy server is it? What OS/app used to do the poxying? Are there two network cards in the proxy? Maybe one for 172.20.0.0 and one for 172.21.0.0? Is the 172.21.0.0 the extranet subnet?

Please find attached some info about the proxy [172.20.3.10].

The 172.21.0.0 is our remote site in another office. We never got firewall rules setup to access servers from 172.20.0.0 but instead setting up the persistent routes you saw earlier:-

route -p add 172.21.0.0 mask 255.255.0.0 172.20.3.10 metric 1

Do think the proxy perhaps could have a rule somewhere to allow the traffic we've allowed on the PIX?

Many thanks,
Chris

Can you edit the "proxy_read_maps" on the Proxy? It appears that the proxy_read_maps tell the proxy who the authorized user subnets are. Does this sound familiar?

From the list I sent you of find / -name *proxy* I've opened them with vi and can't see anything familiar. This is a bit new to me as I haven't had anything to do with building the network infrastructure. Feel free to give up at any time!

Chris

LOL...were there's a will, there's a way! From the tracerts we can see that somehow the Proxy is also routing to the 172.21.0.0 network, do you know how the 172.20.0.0 is physically connected to the 172.21.0.0 network? There must be a layer 3 device,  there has to be something that connects the two devices and it will need to have a 172.21.x.x address...do you have any idea what this is?

HOLD ON...before going too deep into the proxy...we can get to the proxy just fine, I'm thinking that whatever connects the 172.20.0.0 and 172.21.0.0 network has some type of filtering or maybe the routing isn't in place.
1. can you prove a "route" from the proxy? Maybe the proxy doesn't know how to get back to 192.168.150.0, and we can see what the proxy's default route is.

Okay I've got some more info for you. That what you meant?

Here you go:
route add -net 192.168.149.0 netmask 255.255.255.0 gw 172.20.1.1
This will tell the Proxy how to route traffic back to the VPN users. The other thing is, (if this doesnt fix it) that the devices on 172.21.0.0 have to know how to get back to 192.168.149.0.

UPCO-PROXY# route add -net 192.168.149.0 netmask 255.255.255.0 gw 172.20.1.1
route: bad value: netmask

Should that be 255.255.0.0?

Oh, it's a different command for NetBSD than for Debian. Here you go:
route add -net 192.168.149.0 -netmask 255.255.255.0 172.20.1.1
This should work.

Hello, sorry I nipped out. I'll be making dinner soon so that will be me for the day but feel free to drop me some more advice.

I added that successfully but it something is choking it still. Can't ping and only tracerts to  the proxy! This is going to be a well-earned 500 points. I'd give you more if I could.

Many thanks, speak to tomorrow.
Chris

OK. After you put in the route can you provide a "route" again to make sure it's in the routing table and see if you can ping from the proxy to your VPN address. If that ping works then we're making progress and the next step would be to remote to a 172.21.0.0 device and provide a "route print" so we can see if a route for the 192.168.149.0 network is needed. So what's for dinner? I love to cook ...MMMMMM.. talk to you tomorrow!

Any luck?

Hello, I'm actually at work at the moment so have no way of checking anything through the VPN connection but I did manage to do as you said and could in fact ping from the proxy to my VPN address 192.168.250.49. However, I've not yet been able to provide route table information from a device on 172.21.0.0/16 subnet: this is because this network is managed by an on-site administrator so I'm awaiting a request to provide the route table info- I'll let you know when I have it. Thanks again for your patience.

Best Regards,
Chris

I'm having to arm wrestle to get access to a machine on that subnet- I don't manage the infrastructure there so you can well imagine my predicament!

I'll get access, the guy just wants answers as he wasn't aware of this issue. I asked for netstat -r sent in an email but haven't got it as of yet. I'll let you know when I do.

Thanks for your patience, speak to you shortly.

Office politics prevail! I'm giving you the points regardless. Thanks for your time and patience.

Chris