Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kbulgrien]

I recommended a DFL-210 for an office that needed to put the hammer down on employee use of the internet during business hours.  Overall, the experience is a good one, but a nagging VPN problem exists.  It is a Cisco VPN client issue - the user needs to VPN into a vendor server as part of their normal business activity.

The original network setup was a DSL Modem --> LinkSys WRT54G2 --> Local Network.  This router has all its VPN pass-thru options enabled.  The Cisco Systems VPN Client is version 4.0.2(D).  The VPN client connects properly and establishes a link.  Then another application (MediTech Magic Workstation 3.26c) is used to telnet to a server over the VPN link.  The LinkSys setup works perfectly.

I have yet to get the D-Link DFL-210 to work with this application.  Firmware Version: 2.20.02.12-7178
Jun 25 2008

First off, the Cisco VPN Client was originally configured to use transparent tunnelling via IPSEC over TCP using Port 9500.  I never did get this to work.  The router kept dropping packets due to:

16:52:06 Debug TCP_FLAG 3300016 TCPSequenceNumbers TCP lan wan 192.168.1.20112.34.243.37 19471 9500 tcp_seqno_too_low
drop seqno=16820901 accstart=16820902 accend=16886437 origsent=120 termsent=40 ipdatalen=20 syn=1

I was able to get past this error by modifying the TCP parameters to ignore this error, but then it started dropping packets due to corrupted TCP flags.  I didn't get past that one - didn't try that hard, but felt it was not a good thing to have to go in and modify TCP settings anyway, so I undid the change above and went down another road.

The Cisco VPN client was reconfigured to avoid use of transparent tunneling.  With this configuration, a DFL-210 IP Rule was set up using the pre-defined ipsec-esp service.  Now the VPN Client successfully establishes a connection with the remote server and sets up link, but, the telnet client is unable to contact the remote IP.  There are no drops listed in the DFL-210 log that appear relevant to the issue.  The client is configured to telnet to an ip address (not a name).

I am not experienced with VPN issues and the vendor support person was not able to give any ideas why one could establish the link but not use the connection.

I have not much of an idea how to troubleshoot this issue or resolve it.  Just to be sure something did not get messed up in the client software, I put the WRT54G2 back into the network in place of the DFL-210 and everything works fine.  I put the DFL-210 back in, and the VPN is not usable.  I have the Microsoft Network Monitor on the workstation, but do not really know what to look for.

Any ideas?

[napster]

hey ,

It seems that the netdefend firewall is dropping the telnet session in the IPSEC connectivity.
Do let me know if you have created an IPrule for the IPsec suite on the VPN tunnel.

Also whats the ordering of the IP rule set.

If possible check the logs of the firewall and whats the rule set by which the packet are getting dropped , do let me know the same ?

if the tunnel is formed and theres no data exchange going on the tunnel, i suggest you to run packet tracker like wireshark or ethereal , also run a traceroute on Ip adddress of the remote end of the tunnel.

[Lycan]

You'll also need a rule that allows the remote network access to the LAN net of the 210 and vise versa.

[Fatman]

Here is the skinny.  It looks like we have some miscommunication.

As near as I can tell the OPs issue is passing a tunnel through the DFL.

IP Rules on the DFL would not effect traffic in this tunnel.

Just making sure we are all on the same page.

OP, call BCS Support at 1 877 354 6555.

[napster]

if you have created a IPsec VPN tunnel and the ordering is diffrerent then it might result in failure or dropping of packets because of the indexing.....
couple of allow rules will be required for bidirectional flow of the data over the tunnel just to allow the traffic.

Also make sure that these allow rules are created for all services in bi direction.

[Fatman]

napster,

I could be reading you post wrong, and if I am I apologize.

That said you should never "allow" (see point 2 as well as general security concern) all services in any direction.

Allow would not NAT the traffic which is presumable required since the box is being used to "hammer down on internet usage in an office".  The correct action for outbound traffic (which brings us to point 3) is NAT,

Return traffic attached to an outbound connection does not need to be allowed separately.  Given this a VPN there is a slight exception to this normal rule (due to secondary connections potentially being created).

Following the FAQ at http://support.dlink.com/faq/view.asp?prod_id=2911 and using the service ipsec-suite instead of pptp-suite may yield satisfactory results in a normal case.  This is however not a normal case and I think that the OP is beyond this level of assistance.

What do you mean ordering and indexing, this is ambiguous and I need to know what ordering and indexing you are referring to to make a proper response?