cFP and VPN problem

[peter_smith]

Hello Everybody!


We made earlier a system where we placed a cFP 2100 module on the local network. The system is in another country than my company. We would like to see the cFP as if it would be on the local subnet anywhere we are currently.
So an other company who manages the local network at the cFP set up a VPN  Server (a D-Link device) with IPSec.
It seems that the VPN connection works fine, as when I log in to the device via a VPN client, I can see all the devices (computers, other routers, cFP) on the network with their local address.

The only problem is that MAX cannot find any devices in the Remote Systems. If I add manually the controller via the Create New Remote Device (Not on the local subnet) Dialog, MAX says that the device is already in my configuration.
If I choose the option to replace the existing device with the new one, there happens nothing. Only the name of the cFP disappears from the MAX and becomes replaced with the IP address of the cFP.

The status stays Disconnected even if I try to press the Refresh button.

When I log in to the VPN, I can ping the cFP with its local IP address (192.168.10.100).

If I run MAX on my machine, and expand the Remote Systems, it starts to Search for devices. After that point I'm not able to ping the cFP any more until I restart the VPN device.

The IT says that such things can happen because of Broadcast Storms ??!

I'm not very sophisticated in networking, but for me VPN should do the following: If I log in to a VPN server, it should look like exactly as if I would connect my computer to a switch on that remote LAN.

Is there ANYBODY who managed to do such a configuration?
If Yes, what VPN device did you use?

For VPN we have to use IPSec, or L2FP or something very secure connection method. (PPTP should be forgotten).


Thank You all in advance!


Peter Kovacs

[Matthew_Williams]

Hi Peter.  We use cFP controllers across a VPN all the time, so it is possible.

We typically use consumer grade VPN routers like a Linksys WRV-200, one at each end.

I think MAX uses protocols other than TCP/IP.  If you can ping your cFP, then ICMP is
working.  Are there any protocol options in your client or server?  I would enable everything
for now.

Are you able to connect to the cFP controller with ftp or http?

Is the VPN server the default gateway for the cFP?  It shouldn't matter, just a thought.

Matt

[peter_smith]

Hi Matthew!

First of all Thank You for your reply!

I've set the Gateway on the cFP to the internal (LAN side) address of the VPN device. Before I did that I was unable to even ping the cFP. So Default Gateway is very important!
Now ping and FTP works fine until I start MAX on my machine. After that it tries to search the available Remote devices, everything seems to stop on the other network. I can't ping anything, FTP also does not work!

I use the Greenbow client to connect to the VPN. It has a trial for 30 days. I can't find any protocol settings in it.

It sounds fine that You were able to manage the VPN connection. Do you need to add the cFPs or other devices in MAX as device on NOT LOCAL subnet? Or can you also use it as if it would be simply connected you machine with a switch?
Can MAX also find devices via the VPN connection?

Thank You in advance!

Best regards,



Peter Kovacs

[Matthew_Williams]

Hi Peter.  That is odd that ping and ftp work until you start MAX.  Any chance you have an IP
conflict?  Can you still ping the IP of the cFP if the cFP is disconnected from the network?
After starting MAX?

After you try MAX, are you able to do anything over the VPN, like connect to printers or shared
volumes?  If you can before, but not after, then it sounds like MAX is breaking something.

We have to enter the IP address of remote cFP controllers when we work over the VPN because
they are on a different subnet, but it works just as expected.

Have you tried with the windows firewall disabled?

When ping is working, try ping -l XX -f <ipofcFP> where XX starts at 1200 and work your way
up to 1500 (by 50 to 100 chunks) to see if ping stops working before you get to 1500.  If it does, for example at 1410 or
some other number < 1500, then you may have an MTU issue with the VPN.  Try setting the
MTU in either the client or the VPN server to whatever the maximum ping packet size is.

Interesting problem.

Matt

[peter_smith]

Hi again!

There are no IP conflict problems on the network.

I tried the ping command as you mentioned, but above 520 it says that the packed needs to be fragmented but DF set.  The result of those ping commands where packets are fragmented are 100% loss.


The problem with the MAX does not start after starting MAX.

Before I start MAX, I can ping the cFP and the PC in the remote network. (There are only 3 routers, 1 PC and 1cFP on the remote network). I cannot ping the routers because their default gateway is not set to the IP of the VPN device. (But they do not need to be reachable, so it does not matter.

After I start MAX I can still ping both the PC and the cFP.
After I expand the Remote Systems part in MAX, it automatically changes to Remote Systems (Searching...)
         This is the point where everything goes wrong.
From this point I cannot ping anymore. Also FTP stops.   The IT man said that it could be because of a broadcast storm ?? (Maybe MAX tries to discover the available devices on the subnet?)

Another interesting thing: I also set up a PPTP server in the VPN device ~half an hour ago. If I connect via PPTP everything goes fine. MAX automatically discovers my cFP. It can communicate with the cFP. I do not need to add it as a device on a remote not local subnet. So it really works as if my laptop would be next to the cFP.

The only problem is that PPTP is not acceptable either for our client either for our company because of security reasons.

Do you use IPSec? Or something other protocol (PPTP,L2F,L2TP)?


Thanks again a lot!

Best regards,


Peter

[Matthew_Williams]

Hi Peter.  There is something very strange going on, but I think you are making progress.

Not being able to ping because the do not fragment bit is set is the expected response when the network
MTU size is smaller than the ping packets with the -f flag.  So your results were exactly as expected, except
that 520 is a very low number.  I have seen as low as ~1300 something when running a vpn over low quality
dsl lines.  I _think_ what is going on is that your network MTU is lower than the default, 1500.  Normally a
network device will respond to an instruction from a router to lower it's MTU, however the cFP controllers,
at least -20xx and probably -21xx, DO NOT respond to an MTU request.  When you first try your normal
ping, the packet size is < 520, so everything works fine.  MAX probably uses larger packets.  The cFP
can't respond, because the cFP is sending response packets > 520, and when the router bounces them
and says to use a smaller MTU, the cFP ignores the request and (probably) tries to retransmit.  This may
be the source of the 'storm'; lots of retries, probably coming from both ends.

So, possible solutions or further testing.

1) Set the MTU in your VPN server.  I am not familiar with the D-Link VPN server, but I know the Linksys
gadgets we use typically have an MTU setting on the first page where you set the (WAN) IP address.
Set the number here to the maximum packet size you can ping with the -f flag.  Your traffic will be
slightly slower, but should work ok.

2) Install a router with a configurable MTU setting between your cFP and the D-Link VPN server, WAN
side to the D-Link.  Set the MTU of this router to your maximum packet size.  This is the solution we
have used at customer sites where the VPN router did not have an MTU setting.  This does significantly
complicate the networking and connection to the cFP, though, and is not plug-and-play.

The PPTP link probably has an MTU setting of 1500, or at least high enough that the cFP responses
don't get bounced.  Try the ping -f test with a packet of 1502.

I'm sorry there isn't an easy fix.  The best solution would be for the cFP controllers to recognize the
MTU command, then everything would just magically work like all other network devices.  Second best
would be an ni-rt.ini token in the cFP to manually set an MTU size.  I have requested either of these
changes, but didn't get an encouraging response.  Maybe the -22xx will be better.

Our vpns usually use IPSEC, but because we have routers on both ends, we are not using a client
on the PC.

Hope this helps, let me know what you find.

Matt