[BBxer]

Hello to all on the forum, it has been some time since my last post... feels like a Catholic confessional.

I have recently installed on a T-Mobile 9900 the release 9900jAllLang_PBr7.1.0_rel998_PL5.1.0.230_A7.1.0.28 4 for testing the WiFi tethering feature.

My question is if there is a way to change the router ip address / dhcp handed to clients. The default is 10.0.0.1 and I am unable to use a 10.x network with my VPN routing solution. I need to use standard 192.168.x.x which nearly all devices are configured to use.

If this cannot be performed, I would ask why did RIM / Blackberry have to use something different... and hope that they update with a manual settings in the future firmware releases. Otherwise this feature makes the phone worthless for my needs.

Another note worth mentioning, the SSID does not save after reboots. Might want to fix that as well.

[stevew]

Your VPN should be setup to accomodate your needs, not you setting up your device to accomodate your VPN's needs, as your BB isn't what the issue is here. The IP address you require - comes from the VPN, not the BB.

Example - I'm running an LT2TP VPN on a Sonicwall PRO3060 with 2 tunnels to two different physical locations/networks. We have a Sonicwall and a few Fortigate's which all connect different physical locations through IP Sec (full-time) VPN tunnels

The L2TP VPN doesn't care about your BB IP; only user authentication and matching VPN client client is required to initiate the connection . The L2TP VPN will then assign its own (admin pre-set) private IP to the client computers/devices/BB's etc...regardless of the BB-issued IP. This is how a VPN is configured when using DHCP. It will see the public IP - not the private one you are trying to specify

Your BB-issued (private or public) IP is NOT relevant to the Firewall's client-assigned VPN. The VPN will see the public BB (WAN) IP, not the private one, and the L2TP VPN-assigned IP will be the one your admin has set in the router's DHCP server for that VPN, if you're using an L2TP or client based VPN.

If your VPN appliance supports SSL, or IP SEC VPN's, they could easily be configured to work the same as the L2TP VPN I described above.

I only use L2TP because my notebooks are MAC, which use either an L2TP or SSL VPN client in the native OS, without adding a 3rd party VPN client like IPSEC. When I'm in one of the physical locations on WiFi (not the Mobile Hotspot), I'm actually on the IP SEC (PPTP) FIREWALL VPN - so I get the (reserved) IP from the DHCP from the Firewall. In that case, you would need to have an IP in the range assigned in the Firewall/VPN device, if you were using say, a static IP you assigned, which you won't need to do in any case.

My Sonicwall firmware version doesn't support SSL, so I chose to use L2TP. MAC's don't support IP SEC just using the native OS only. You'd need to use a 3rd party MAC CLIENT IPSEC VPN if you want to go to IPSEC VPN on MAC.

As to your issue with the SSID not saving after a reboot, some others have reported the same thing, although I have never seen that.

Bottom line - your VPN issue will not be an issue if you or your admin setup the VPN configuration correctly. It sounds to me as if you're on IPSEC VPN between two or more VPN firewalls...and unless you configure a client based VPN to work as I briefly described above, you won't gain access through the Mobile Hotspot...but trust me, it can be done; I use my L2TP VPN through Mobile Hotspot for full network access all the time, while on the road. Your Firewall/Router appliance should support multiple VPN types simultaneously, if it's a real VPN Firewall. You just need to configure it correctly.

I know this is a lot to take in, but I hope this gives you a clearer understanding of the VPN issue you think you are experiencing!

[err0s]

Nope - if the end device is getting a 10.x.x.x address from the hotspot's DHCP, and the VPN's end node you are trying to connect to is another 10.x.x.x then you definitely have a problem. When the client tries to connect to a 10.x.x.x it's going to look in its local route tables and not through the tunnel.

Stevew gives a great description of how two VPN gateways negotiate and encrypt (PHASE 1), but does not address the tunnel creation between the endpoints/nodes (PHASE 2).

What is needed is a way to change the IP address the hotspot issues to the host, and unfortunately the current code does not supply a user friendly way to adjust this. Using a 10.0.0.1 is extremely short sited as it conflicts with a good 90% of the corporate IP addressing schemes I've run into.

[dc/dc]

Originally Posted by err0s

Nope - if the end device is getting a 10.x.x.x address from the hotspot's DHCP, and the VPN's end node you are trying to connect to is another 10.x.x.x then you definitely have a problem. When the client tries to connect to a 10.x.x.x it's going to look in its local route tables and not through the tunnel.

Stevew gives a great description of how two VPN gateways negotiate and encrypt (PHASE 1), but does not address the tunnel creation between the endpoints/nodes (PHASE 2).

What is needed is a way to change the IP address the hotspot issues to the host, and unfortunately the current code does not supply a user friendly way to adjust this. Using a 10.0.0.1 is extremely short sited as it conflicts with a good 90% of the corporate IP addressing schemes I've run into.

Anyone using the actual 10.0.0.0 network is shortsighted. If you want to use class A, at least be creative. I use it regularly to segregate unauthenticated WLAN traffic from the live network, but I always use some sort of scheme to split octets 2 and 3 into a logical breakout. I usually use octet 2 to denote a site and then make octet 3 the same as the VLAN.

[stevew]

Originally Posted by err0s

Nope - if the end device is getting a 10.x.x.x address from the hotspot's DHCP, and the VPN's end node you are trying to connect to is another 10.x.x.x then you definitely have a problem. When the client tries to connect to a 10.x.x.x it's going to look in its local route tables and not through the tunnel.

Stevew gives a great description of how two VPN gateways negotiate and encrypt (PHASE 1), but does not address the tunnel creation between the endpoints/nodes (PHASE 2).

What is needed is a way to change the IP address the hotspot issues to the host, and unfortunately the current code does not supply a user friendly way to adjust this. Using a 10.0.0.1 is extremely short sited as it conflicts with a good 90% of the corporate IP addressing schemes I've run into.

No no no - when the hotspot is in use, the WAN address of the BB is the ONLY thing the tunnel will see, not the Hotspot LAN IP on the connected device, so it doesn't matter which address/subnet the device is getting, unless I'm missing something here.

I use my MAC's through a VPN tunnel with the 10.x.x.x BB assigned address, but, the address the tunnel see's, is the BB's WAN address, not the HotSpot LAN IP handed out to the MAC. I only had to create an L2TP VPN to do this...which is what I said above. This is why I said what said above - you have to create a VPN that will support user authentication. What happens in this case, with our Sonicwall's/Fortigate's, is that the BB WAN IP will get a private IP address assigned by the Firewall, regardless of the 10.x.x.x address handed out to the connected devices.

I can traverse the IPSEC VPN'S all day long using the L2TP VPN. I don't see where there's an issue, except if the OP doesn't have the capability to set it up, but even if that were the case, I'm sure there's a network admin somewhere in that equation?

Not sure why the 10.x.x.x address is a problem, since it never gets transmitted beyond the HotSpot...but maybe I'm just not getting where the issue is?

This DOES work - I use it all the time and I'm the one who set it up.

I think you're forgetting that the private address of the device or the BB is irrelevant, since the BB is a WAN assigned IP router connecting through the firewall VPN. That being said, unless the BB had a 192.xxx.xxx.xxx WAN IP, or whatever the firewall is configured for, it would always have to be configured to connect. The key here is that the OP is tethering --

There is no way short of creating a user-authenticating VPN to do this, given that we never know what the WAN IP of the Bold will be on any given day. I'm not a vastly experienced firewall expert, and perhaps I am missing something here, so if I'm wrong, I stand corrected. I just know enough to be dangerous...LOL