VPN problem...
I recently was relating on the list how a client was having a problem with their Linksys BEFSX41 router and the solution was that Linksys RMA'd the router. They apparently have removed the BEFSX41 model from their active product list so they sent me a BEFVP41 v2 model. I received it yesterday, configured it and tested it from my office network. The router was set to obtain it's WAN address dynamically from it's WAN connection. It connected fine to a wireless bridge that I use for this purpose and I could surf the web from behind it with a PC. I then configured the VPN tunnel exactly as the old router was set up and it immediately connected to the customer's end point and I could ping systems located at the end point LAN. I tore down the setup and put the router in a container to set up at my client's location this morning. I got to the client site and thought that all that was going to be necessary was to set the WAN address of the Linksys router to match the static address being provided by Comcast at the customer location. As soon as I did that I was able to connect to the internet from behind the router. But I then noticed that the VPN was not connected. Since the VPN settings were identical to the previous router there shouldn't have been a problem. For the fun of it I set the router to obtain it's WAN address dynamically and immediately the VPN tunnel connected. I checked the logs but didn't see anything obviously wrong. I did notice that when the router is setup to use a dynamic address, it has the correct date and time. When it's set up with a static address the status page says time unavailable. I think this might be part of the problem. If the router doesn't know the time (perhaps the clock can't be used?) then the VPN connection might not work. I'm also puzzled as to what server it's requesting date/time data from. It has the ability to manually set the time zone but doesn't give any choices as to which ntp server to use. Does anyone have any ideas? So far Linksys support hasn't been very useful. -Alex ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VPN problem...
On Thu, Oct 1, 2009 at 4:59 PM, Alex Hewitt hewitt_t...@comcast.net wrote: If the router doesn't know the time .. then the VPN connection might not work. Quite possible. If it's using X.509 certificates (like SSL does), one can specify effective and expiration dates in the certificate. If they are set, and the LinkSys box is checking them, having the wrong time will likely cause it to conclude its certificate is invalid. Any idea what protocols the LinkSys is using? IPsec? IKE? SSL/TLS? X.509? Does anyone have any ideas? (1) Check for a firmware update. (2) Look for a way to set the clock manually (no time server). (3) Set up a DHCP reservation on the WAN side for the LinkSys box, and give an NTP server in the DHCP options, in the hope that time is actually the problem, and the LinkSys box will listen. Beyond that, you're at the mercy of the vendor. Which leads me to: (4) I've never heard anything good about SOHO+VPN scenarios. Which in turn leads me to: (4)(a) Throw out the SOHO crap and buy a real VPN appliance. (4)(b) Grab a couple PCs, install Linux and OpenVPN, and use that. Again: SOHO stuff has its uses. I had a LinkSys router+WAP+switch at home, and was happy with it. Their products are appropriate for home use, and I recommend them for that. If you're running a real business on them, you're crazy. :) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VPN problem...
On Thu, 2009-10-01 at 16:59 -0400, Alex Hewitt wrote: For the fun of it I set the router to obtain it's WAN address dynamically and immediately the VPN tunnel connected. I checked the logs but didn't see anything obviously wrong. I did notice that when the router is setup to use a dynamic address, it has the correct date and time. When it's set up with a static address the status page says time unavailable. I think this might be part of the problem. If the router doesn't know the time (perhaps the clock can't be used?) then the VPN connection might not work. I'm also puzzled as to what server it's requesting date/time data from. It has the ability to manually set the time zone but doesn't give any choices as to which ntp server to use. Does anyone have any ideas? So far Linksys support hasn't been very useful. Name servers??? The DHCP server provides good name servers. You have a static name server setup that limps along at the client (blocked from recursive queries??). -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VPN problem...
On Thu, Oct 1, 2009 at 5:50 PM, Hewitt_Tech hewitt_t...@comcast.net wrote: Any idea what protocols the LinkSys is using? IPsec? IKE? SSL/TLS? X.509? It's definitely using IKE. Okay, IPsec with IKE can use PSK or X.509 certificates. Which one is your LinkSys using? If it's PSK (pre-shared keys, also called a shared secret), you have to enter the same password into both devices. There will be no clock time element involved. So that isn't the problem. (I think.) If it's X.509 certificates, you either register the device with a Certificate Authority, or you exchange peer certificates between each device. X.509 allows the time stuff. so that *MAY* be the problem. If you want to persue the certificate+time thing: Does the device have the option of letting you load your own certificate and key? If so, you could use OpenSSL's CA support on a Linux box to generate certificates for each device, specifying a Not Before date of 1/1/1900 or whatever the device thinks the date is. One word of warning: If you haven't used the OpenSSL CA stuff already, it is extremely cryptic and very poorly documented. Even by Linux standards. It doesn't help that X.509 is a nightmare, too. It will probabbly be cheaper to just buy a real VPN box than spend the time and effort in figuring it all out -- especially since we're not even sure that's the problem. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VPN problem...
On Thu, 2009-10-01 at 18:50 -0400, Hewitt_Tech wrote: Thanks for the help guys. I fixed it by setting up the cable modem as I was describing. I changed the Linksys router to get it's WAN address dynamically. I then re-configured the cable modem to create a DMZ which only has one computer (in this case the router). I changed the cable modem's DHCP lease to forever so that the IP address being used by the Linksys router wouldn't change. I then noticed that the WAN IP address was switched by the cable modem to what had previously been the gateway address (which was one off the original WAN IP address). I've seen DSL modems with 2 modes of behavior: * bridge mode where they simply translate DSL/Ethernet bits which is what you want if you supply the router * NAT/router mode where the modem assumes router/firewall duties I don't know if the cable modems offer similar capabilities. The DSL mode was controlled by the phone company and set by tech-support. I was helping a friend install a wireless router and was lucky to encounter a phone company tech support person who knew what she was doing. Perhaps your cable modem switched from bridge mode to router mode when the customer router was removed. So it's up and running despite the weirdness that the Linksys router was displaying. -Alex -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VPN problem...
On Thu, Oct 1, 2009 at 7:48 PM, Lloyd Kvam pyt...@venix.com wrote: I've seen DSL modems with 2 modes of behavior: * bridge mode ... * NAT/router ... I don't know if the cable modems offer similar capabilities. It's a bit different in cable-modem-land. DSL is typically running some kind of PPP feed, so in bridge mode, you need to run your own PPPoE service. Cable is presented more like a regular Ethernet broadcast medium. Most cable modems I've seen act like bridges: You're on one big subnet with all your neighbors. You can see their broadcast traffic. You request a DHCP lease, just like you do on a corporate LAN, and get it from a cable company DHCP server somewhere. This is what I've seen Comcast provide in every residential install. I have seen cable modems with integrated routers. Conceptually, these are the same as other SOHO routers, except the Internet port is a coaxial F connector instead of an Ethernet jack. They typically combine a NAT router, firewall, WAP, Ethernet switch, coffee maker, etc., just like the more general SOHO gateways do. When we subscribed to Comcast's business service with a static IP address, they gave us something like the later. It appears to be a halfheartedly[1] re-badged SMC8014. Built-in four port Ethernet switch. It was configured to do NAT, and assigned IP addresses via DHCP in the 10.1.10.0/24 subnet. But the static IP address is also configured on the Ethernet switch. In other words, the LAN side of the integrated router has multiple IP addresses. You can manage the LAN side by going to http://10.1.10.1/. Default username is cusadmin; default password is highspeed. I recommend changing the password. :) [1] The front panel says Comcast, but the top of the case still has a giant SMC molded into the plastic. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VPN problem...
Ben Scott dragonh...@gmail.com writes: On Thu, Oct 1, 2009 at 5:50 PM, Hewitt_Tech hewitt_t...@comcast.net wrote: Any idea what protocols the LinkSys is using? IPsec? IKE? SSL/TLS? X.509? It's definitely using IKE. Okay, IPsec with IKE can use PSK or X.509 certificates. Which one is your LinkSys using? [...] If you want to persue the certificate+time thing: Does the device have the option of letting you load your own certificate and key? If so, you could use OpenSSL's CA support on a Linux box to generate certificates for each device, specifying a Not Before date of 1/1/1900 or whatever the device thinks the date is. One word of warning: If you haven't used the OpenSSL CA stuff already, it is extremely cryptic and very poorly documented. Even by Linux standards. It doesn't help that X.509 is a nightmare, too. It will probabbly be cheaper to just buy a real VPN box than spend the time and effort in figuring it all out -- especially since we're not even sure that's the problem. When I started using x.509 certificates with openVPN, I found that the OpenSSL CA stuff was sufficiently documented in an easy-to-understand way--just not in the OpenSSL documentation :) The *OpenVPN* manpage actually provided (and still does) simple instructions in the style of `this is the command that you need to run to generate a CA key and certificate, and this is the commands that you need to run on each system to generate keys and associated certificates signed by the CA that you just created'. When I forget how to use OpenSSL, I still refer to the OpenVPN documentation. -- Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: VPN problem...
On 10/01/2009 08:06 PM, Ben Scott wrote: [1] The front panel says Comcast, but the top of the case still has a giant SMC molded into the plastic. Same model here. After turning off all of its 'features', it seems to work well. The only trick was changing the management interface to run on a private IP range I wasn't using on my LAN and setting the static route on my real firewall so I could still get to it. But with that done I haven't been able to blame anything on their router (up since May 1). -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Telephone: +1.603.448.4440 Email, IM, VOIP: b...@bfccomputing.com VCard: http://bfccomputing.com/vcard/bill.vcf Social networks: bill_mcgonigle/bill.mcgonigle ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
