I experienced this problem on SSH-Sentinel, and then upgraded to its commercial successor - SafeNet's SoftRemote - but continue to be virtually shut out of my target LAN.
Target LAN is accessed by Linksys (BEF)VP-41, with static IP address on the Net. Subnet there is 192.168.1.0 255.255.255.0.
I can only ping 192.168.1.50 on the target LAN. This is the gateway address we set (in Linky configuration) for the "target" LAN, on the VP-41.
I know from experience, and from many threads on this forum, that for Linky-to-Linky, Linksys requires that the subnets be distinctly different, or else routing thru the tunnel(s) doesn't happen.
Linky-to-Linky, between numerically distinct subnets - I was able to get to other machines on the target LAN - such as a Webserver on 192.168.1.25.
One reason for trying the Software Client, is that both the SSH and SafeNet literature profess that you can use (e.g., on your laptop) an address that looks like it "belongs" to the target subnet. In my example, that address is 192.168.1.114.
The Sentinel- and SoftRemote-suggested handling is to make ...114 a "virtual" address.
When you see this played out, installed on an XP machine, you find that SoftRemote creates a "VA miniport" with the 192.168.1.114 address.
Less of this was visible in Sentinel, though you could visit the virtual widget's specs in the Registry.
With the virtual address, SoftRemote does connect! This is more than you get attempting Linky-Linky tunneling.
The Linky VPN Summary table shows it thinks the address that is connecting to it is ...114. The logs mention a "VID" being a part of the data sent during negotiation. I'm guessing this refers to a "virtual ID."
Pings only reach the target LAN's internal gateway address - not others!
"Pathping" to the accessible address (...50) shows a pattern I believe to be tunneling. I say that, because after some idle time, pinging ...50 can re-open the tunnel. I saw that in the Sentinel logs, and verified it by inspecting the Linksys. This is true in Sentinel and SoftRemote.
The tunnel-opening ping was logged by Sentinel as a 'trigger." Successive pings didn't appear in the log. I am guessing that once open, the traffic just scoots into the tunnel.
Changing my virtual address from ..1.114 to ..2.114 gave me full access! I can hear the routing hardliners now: "I could have told ya!"
I remain disappointed that I can't get ..1.114 working better. The tunnel was created, but (except for successfully pinging ..1.50 on the target LAN) seems to have routing problems after that point.
Reaching ..1.50 is giving me hope I can make a virtual ..1.114 talk to other members of the target LAN.
Perhaps, the Virtual Adaptor miniport, and my real-world Lan Adaptor need to talk. From pathpinging an address other than ..1.50, it appears that pings for these other target LAN addresses never even get into the tunnel. This smacks of a local routing and/or SoftRemote problem.
When trying this on Sentinel, I even went into the registry, and entered various gateway addresses, although there was no GUI counterpart. No matter - nothing helped.
While I'm reading up on miniports, I hope someone has insight into using Virtual addresses.
Since the compelling logic of systems having DHCP serve out client addresses to remote clients is to have addresses that belong to the subnet, I can't believe there isn't some way to SPECIFY a virtual address that "belongs" to the target segment.
Here are the VA miniport readings (maybe something needs to be done to change the server reading).
Device Name.....SafeNet VA miniport
Device Type.....isdn
Server type.....PPP
Transports......TCP/IP
Authentication..MD5 CHAP
Compression.....(none)
PPP multilink
.framing........Off
Server IP addr..192.168.1.114
Client IP addr..192.168.1.114
...Bruce
Target LAN is accessed by Linksys (BEF)VP-41, with static IP address on the Net. Subnet there is 192.168.1.0 255.255.255.0.
I can only ping 192.168.1.50 on the target LAN. This is the gateway address we set (in Linky configuration) for the "target" LAN, on the VP-41.
I know from experience, and from many threads on this forum, that for Linky-to-Linky, Linksys requires that the subnets be distinctly different, or else routing thru the tunnel(s) doesn't happen.
Linky-to-Linky, between numerically distinct subnets - I was able to get to other machines on the target LAN - such as a Webserver on 192.168.1.25.
One reason for trying the Software Client, is that both the SSH and SafeNet literature profess that you can use (e.g., on your laptop) an address that looks like it "belongs" to the target subnet. In my example, that address is 192.168.1.114.
The Sentinel- and SoftRemote-suggested handling is to make ...114 a "virtual" address.
When you see this played out, installed on an XP machine, you find that SoftRemote creates a "VA miniport" with the 192.168.1.114 address.
Less of this was visible in Sentinel, though you could visit the virtual widget's specs in the Registry.
With the virtual address, SoftRemote does connect! This is more than you get attempting Linky-Linky tunneling.
The Linky VPN Summary table shows it thinks the address that is connecting to it is ...114. The logs mention a "VID" being a part of the data sent during negotiation. I'm guessing this refers to a "virtual ID."
Pings only reach the target LAN's internal gateway address - not others!
"Pathping" to the accessible address (...50) shows a pattern I believe to be tunneling. I say that, because after some idle time, pinging ...50 can re-open the tunnel. I saw that in the Sentinel logs, and verified it by inspecting the Linksys. This is true in Sentinel and SoftRemote.
The tunnel-opening ping was logged by Sentinel as a 'trigger." Successive pings didn't appear in the log. I am guessing that once open, the traffic just scoots into the tunnel.
Changing my virtual address from ..1.114 to ..2.114 gave me full access! I can hear the routing hardliners now: "I could have told ya!"
I remain disappointed that I can't get ..1.114 working better. The tunnel was created, but (except for successfully pinging ..1.50 on the target LAN) seems to have routing problems after that point.
Reaching ..1.50 is giving me hope I can make a virtual ..1.114 talk to other members of the target LAN.
Perhaps, the Virtual Adaptor miniport, and my real-world Lan Adaptor need to talk. From pathpinging an address other than ..1.50, it appears that pings for these other target LAN addresses never even get into the tunnel. This smacks of a local routing and/or SoftRemote problem.
When trying this on Sentinel, I even went into the registry, and entered various gateway addresses, although there was no GUI counterpart. No matter - nothing helped.
While I'm reading up on miniports, I hope someone has insight into using Virtual addresses.
Since the compelling logic of systems having DHCP serve out client addresses to remote clients is to have addresses that belong to the subnet, I can't believe there isn't some way to SPECIFY a virtual address that "belongs" to the target segment.
Here are the VA miniport readings (maybe something needs to be done to change the server reading).
Device Name.....SafeNet VA miniport
Device Type.....isdn
Server type.....PPP
Transports......TCP/IP
Authentication..MD5 CHAP
Compression.....(none)
PPP multilink
.framing........Off
Server IP addr..192.168.1.114
Client IP addr..192.168.1.114
...Bruce
