From: Jason A. Pattie (pattieja_at_pcxperience.com)
Date: Wed Sep 11 2002 - 16:41:07 CEST
In the scenario that one of our clients has, they are using SSHSentinel
(currently in the process of migrating from 1.3 beta2 to 1.3.2.2) to
connect to one of four interconnected offices. Currently, each of the
four locations has a static IP address but is not resolved by DNS on the
Internet. So the SSHSentinel connections have to use the IP address (I
am assuming). If we move to DHCP (since there seems to be an issue with
Virtual IP's working with the test laptop we have setup which was an
upgrade from 1.3beta2 to 1.3.2.2 over a dialup connection), it is my
understanding that each connection entry definition will need to use the
"any" keyword instead of the custom IP ranges we had setup with
"understandable" network names (like St.LouisNet, KCNet, etc.). Now,
however, each connection is just an IP address (which is meaningless to
the end users) with the work "(any)" after it in the list of VPN's to
bring up. So, is it possible to add a feature to SSHSentinel that would
allow the VPN tunnel to be "renamed" (if only for legibility in
SSHSentinel), but would retain the IP address. For now, I am going to
enter each of those four IP addresses into the LMHOSTS file to see
whether I can use "hostnames" instead of IP addresses and assign
meaningful hostnames to each of the four IP addresses.
Thanks.
P.S. They successfully worked with 1.3beta2 with a normal VPN
connection where their ISP assigned IP address was being used without a
Virtual IP setting (DHCP or other). However, they would like to be able
to connect to any of the offices other than the main office and be able
to get their e-mail which resides in the main office. What was
happening was that they would connect to their home base office and
attempt to retrieve their e-mail. The request would go through their
VPN tunnel, get forwarded across the WAN VPN to the main office, get
decrypted at the main office and sent to the mail server. The mail
server was then seeing their ISP assigned IP address, routing the return
packet to the default gateway, which then sent the packet out the
Internet to the road warrior machine instead of back through the WAN VPN
to the RW's home base office security gateway to be directed through the
RW tunnel back to the RW machine. I successfully tested using both a
Virtual IP and DHCP using a Win98 session in VMware (using network cards
in VMware). However, testing with the client using a modem failed to
work in the Virtual IP scenario (it seems that no packets are sent out
the modem when the VPN is selected to be brought up; only the status bar
in the negotiation window immediately goes really fast to the right and
always fails to make a connection). Testing with DHCP got a little
farther, as SSHSentinel was able to negotiate an DHCP IP address
successfully, but then it still sent the status bar to the right and
always fails to bring up the tunnel. However, there do not appear to be
any error messages in the FreeS/WAN logs and I successfully worked all
the "issues" out of the firewall rules, so they aren't dropping the DHCP
broadcast attempts any longer. In the Virtual IP attempt, when no
packets are sent out the modem, I don't even see anything coming in to
the security gateway logs. Absolutely nothing is logged in that
scenario. In the DHCP scenario, the Diagnostics work, but it is unable
to bring up a tunnel. It would be really great if I don't have to
unload the 1.3beta2 and then install 1.3.2.2. But if that's what it
takes, that's what it takes.
Thanks for any input.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean._______________________________________________ Users mailing list Users_at_lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.4 : Thu Sep 12 2002 - 05:20:02 CEST