#243139 - 14/04/2005 00:58
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Oh, and a follow up. In the second group of numbers, there's a subnet mask of ".254", which is what was written on the form by the DSL tech. But the router won't actually let me use that value. What was plugged into the router when they set it up was actually ".252" and that works. Interesting.
|
|
Top
|
|
|
|
|
#243140 - 14/04/2005 01:01
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Quote:
do I have to throw out the current, working configuration and re-configure the DSL router with the first set of numbers if I want to use those static IPs?
Tried this, and it didn't work, by the way.
So how AM I supposed to use those static IPs?
|
|
Top
|
|
|
|
|
#243141 - 14/04/2005 06:19
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 17/12/2000
Posts: 2665
Loc: Manteca, California
|
The static IP's give the machines that have them, a public presence on the WAN. They can be contacted directly, assuming there isn't something blocking the pipe. With static your don't need to mess around with nat or port forwarding, vpn routers, or anything. You can load ssh or vpn software directly onto the static addressed computers and let them contact the remote vpn device directly.
PS You might want to check your subnet masks carefully. They are what determine if a packet stays on the LAN or is passed to the WAN. Given the list of static addresses earlier the mask should have been 255.255.255.216 216 is 39 after it was converted to binary, had all the digits inverted and then converted back to decimal.
Hope someone else will correct this if wrong.
_________________________
Glenn
|
|
Top
|
|
|
|
|
#243142 - 14/04/2005 10:03
Re: VPN Help
[Re: gbeer]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Hm. When I plugged those numbers into the DSL router, the internet connection stopped working. I wonder how SBC expects me to use those numbers, then.
|
|
Top
|
|
|
|
|
#243143 - 14/04/2005 11:14
Re: VPN Help
[Re: tfabris]
|
enthusiast
Registered: 08/08/2000
Posts: 351
Loc: chicago
|
Tony,
By default, SBC delivers their routers set up with NAT enabled, which may not be what you want. It turns out to be easy to fix, but you can't do it through the administrative web interface on the box. You need to telnet in, and change settings that way. I called SBC, and they transferred me to a support guy from the router hardware vendor, who walked me through it. I'm not sure why they don't document this for business class customers, as it would seem that many of those would rather run in bridging mode.
--Dan.
|
|
Top
|
|
|
|
|
#243144 - 14/04/2005 11:18
Re: VPN Help
[Re: tfabris]
|
old hand
Registered: 27/02/2003
Posts: 777
Loc: Washington, DC metro
|
From this IP chart, your provider wants the 64.125.107.154 on the outside interface, 64.197.129.38 on inside interface in a two devcie model (though it really shouldn't matter which of the 6 addresses you choose for your gateway - the whole subnet exists on the far side of the .107.154 address from the ISP's viewpoint - I prefer starting from the bottom), and the other 5 IP addresses on your various devices (with one presumably dedicated to your DMZ).
The old fashioned, two device (one router, one firewall) model would be to have the router set up with .107.154 on the serial interface (internet side), .129.33 on the ethernet interface, and the default gateway in the router set to .107.103 (to send all outbound traffic to your ISP).
You would then set the a firewall with .129.34 as the "outside" interface (it could be just a crossover cable to the router's ethernet interface), 192.168.1.1 as the "trusted" interface, and 192.168.2.1 for your DMZ, with the firewall having a default gateway of .129.33 (this sends traffic to your router's ethernet interface, and the router then forwards outbound traffic to the ISP).
You then would have a 192.168.1.0/24 internal subnet for your "inside" computers and devices, all devices having a default gateway of the firewall's trusted interface (.1.1).
You would also have a 192.168.2.0/24 DMZ subnet for your semi-public computers and devices, all having a default gateway of .2.1. The firewall would NAT your additional public IP addressses (.35-.38) into the the DMZ based on your DMZ rules.
If you have an "all in one" type router/firewall, it'd work something like what I described above, with the router/firewall unit having the entire .129.32/29 subnet for aliases on the DMZ subnet.
The entire DMZ setup depends on your firewall options, whether port forwarding or one-to-one address forwarding, or a combination of the two.
-jk
|
|
Top
|
|
|
|
|
#243145 - 14/04/2005 11:56
Re: VPN Help
[Re: djc]
|
carpal tunnel
Registered: 19/01/2002
Posts: 3584
Loc: Columbus, OH
|
I think it'll be a heck of a lot easier to just put your modem in bridge mode and then plug it into your SonicWall and manage the rest from there (using the same settings you're using now.)
_________________________
~ John
|
|
Top
|
|
|
|
|
#243146 - 14/04/2005 13:27
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
I'll explain what all of this means and you can draw conclusions from that based on what you want to do.
Quote:
Customer's IP's or LAN IP's (For routers):
Static IP addresses:
64.197.129.33
64.197.129.34
64.197.129.35
64.197.129.36
64.197.129.37
Gateway:
64.197.129.38
Subnet Mask:
255.255.255.248
WAN Side (For routers):
IP Address:
69.125.107.154
Subnet Mask:
255.255.255.254
Gateway:
69.125.107.153
Let's start with the second part, the WAN. The IP address is the address you need to configure on your outermost IP device. This is the address that the ISP knows should be directly on the other side of their pipe. The gateway is what you should set the default route of that device to. It's the address of their device directly on the other side of the pipe from you.
The .254 netmask is a special case, and it's a fairly newly designed special case, which is why your router/modem/whatever won't take it. A subnet mask of .254 means that there are only two IP addresses in that subnet, but subnets are defined to have the first and last addresses be network and broadcast addresses, which are unusable by hosts. This has been changed to allow .254 netmasks to be a special case intended to specify a network used to connect two hosts together, and the network and broadcast address concepts are discarded, since they're useless in that configuration anyway. The old way to do that was to use a .252 netmask, which would be 4 addresses: the two hosts and the network and broadcast addresses. The point of the change is that in the new method, you get a 50% savings in IP addresses for those networks, which are fairly common these days. Anyway, using a .252 works for you because it incoporates the .254 network. I imagine that the ISP knows that it's possible for your device not to understand the .254 netmask, so probably kept the IP address for itself that's the one that would be a host address in the .252 network, otherwise your gateway would appear to be a network or broadcast address, and I'm not even sure that that would work, and if it did, it'd be less than optimal. (I can't tell if they've done the right thing without having at least the last octet as your actual number, and either you've changed it or your ISP is wildly screwed up.) The other problem is that you won't be able to communicate with the hosts that are in the other half of that .252 network at all.
Phew.
Now onto the first set of addresses, your static IPs. What's going on is that your ISP is routing the x.x.x.32/255.255.255.248 network to you via the WAN IP address. (In this case, your numbers work out, so you might have copied the last octets here. If so, the .32 and .39 addresses are your network and broadcast addresses.) That is, the ISP knows that it's not directly connected to that network, but it knows that they're accessible via your pipe. That means that you can do virtually anything you want to within your network. They have suggested that you configure the .38 address (again, if your numbers are vaguely accurate) as the inside of your router and use that as the gateway/default route for all the other computers, which get the other IP addresses as their own. Of course, you could set those IP addresses up in your firewall as NAT destination addresses, or on individual hosts or whatever. But you can do absolutely anything with that network you want to.
The "normal" thing to do would be to configure your firewall with all those addresses, use most of them for NAT, and use one or two as passthrough (or nearly so) for your DMZ hosts. Preferably, you'd want multiple internal interfaces on your firewall for that to separate the DMZ hosts from the others. (That would mean at least 3 interfaces total.) Or if you don't have that many interfaces, have the DMZ hosts not behind the firewall at all on the same network as the outside interface of the firewall. Of course, that means they'd be directly attached to the internet with no defenses but their own.
I hope that information helps you figure out what you need to do.
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#243147 - 14/04/2005 13:42
Re: VPN Help
[Re: gbeer]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
Quote:
They are what determine if a packet stays on the LAN or is passed to the WAN. Given the list of static addresses earlier the mask should have been 255.255.255.216 216 is 39 after it was converted to binary, had all the digits inverted and then converted back to decimal.
Hope someone else will correct this if wrong.
You are wrong. I'm not entirely sure what you're saying, but you're wrong. The .248 netmask fits the address he gave (.33 to .38) perfectly.
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#243148 - 14/04/2005 13:50
Re: VPN Help
[Re: JBjorgen]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Wow, fantastic information and advice in this thread. Thanks very much, guys! Bitt, the explanation of the 252 versus 254 netmask is especially eye-opening. I was completely unaware of that. John, thanks for the explanation of the internal/external addressing. I think part of my confusion was due to most of that being either hidden or not configurable on my Netopia DSL router. Quote:
I think it'll be a heck of a lot easier to just put your modem in bridge mode and then plug it into your SonicWall and manage the rest from there (using the same settings you're using now.)
I'd pretty much come to this conclusion myself last night, actually. It's simply a pain trying to configure that Netopia DSL router to do what I want. It's got a check box for bridge mode, I should just reset the thing and put it in bridge mode, then do everything from the sonicwall.
|
|
Top
|
|
|
|
|
#243149 - 14/04/2005 14:10
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
This is only tangentially relevant, but you might come across it at some point, so I'll go ahead and point it out. You can't make a subnet out of any random grouping of sequential IP addresses, even if it's a correct number of them (which will always be a power of two). The math involved means that 69.125.107.32/255.255.255.248 is a valid network of eight addresses, but 69.125.107.30/255.255.255.248 is not. That's the reason I claimed your .254 WAN network settings are screwed up -- because they can't make a valid network. The reason for this is that an IP address is made up of two numbers, the network number and the host number. The netmask defines how many bits the network number takes up, and, therefore, how many are left over for the host number. Obviously, all of the IP addresses in a given network must have the same network number. For an easy example, assume a netmask of 255.255.255.0. We're all fairly familar with that. That means that your network could encompass, for example, 192.168.1.0 to 192.168.1.255, but not 192.168.1.16 to 192.168.2.15. That seems obvious, but the math becomes a little more complex when you're translating binary numbers into decimal numbers that aren't as tidy as that example. Also, you may see netmasks described differently. For example, 192.168.1.0/255.255.255.0 might also be listed as 192.168.1.0/24. The old-style netmasks are really, in binary, a bunch of ones followed by a bunch of zeroes. The new way simply describes how many ones there are. There's a direct mapping: /25 is .128, /26 is .192, /27 is .224, /28 is .240, /29 is .248, /30 is .252, /31 is .254, and /32 is .255. Netmasks can be smaller, too, but you're not really going to encounter any of those. I point that out so that you can use aggis, which is a handy-dandy utility for figuring out network addressing. It requires that its input be in new-style format.
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#243150 - 14/04/2005 15:51
Re: VPN Help
[Re: wfaulk]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
This is good information, thanks. I'd pretty much known most of that, but it makes me wonder about something specific. Meatballman might know the answer to this one. I'm using these instructions to configure the SonicWall as an L2TP server for Windows clients. This instruction sheet says: When creating a L2TP IP pool on the SonicWALL device, the IP addresses must be a unique IP subnet – you cannot specify IP addresses from the LAN (or any other) interface subnet on the device.But that's exactly what I *want* it to do. I want the people who are tunneling in to get fed IP addresses from the same pool as what's on the office LAN. So I'd want them to be in the same subnet. Do you think it possible to specify the DHCP pool on the SonicWall, and specify the LAN-side netmask, so that it can dole out half of the addresses in 192.168.2.xxx pool to the local DHCP users, and use the other half for the L2TP clients? What would those netmasks look like?
|
|
Top
|
|
|
|
|
#243151 - 14/04/2005 16:01
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
See? This is why I don't like Sonicwall. Those rules are highly unclear and apparently arbitrary. If they'd just come out and say what they mean in normal IP-speak instead of trying to be friendly about it, then you might not be able to understand it, but at least I would. As it is, I don't understand it and neither do you.
It's like you have to have a SonicWall expert instead of an IP expert. Sure, Ciscos and whatnot require some expertise, but that's just based on "what's the syntax", not "what the fuck are they talking about".
My guess is that you must use an IP address on the WAN side, but you only have one IP address assigned there. I'm not sure what they mean by unique, either. Maybe they mean globally routable (that is, not in the 10/8, 172.16/12, or 192.168/16 ranges)?
Edited by wfaulk (14/04/2005 16:05)
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#243152 - 14/04/2005 16:29
Re: VPN Help
[Re: tfabris]
|
old hand
Registered: 27/02/2003
Posts: 777
Loc: Washington, DC metro
|
Does the SonicWall NAT them to an IP address on the local subnet after assigning an IP from the "unique" subnet? Or does the firewall cleanly route between the local subnet and the unique subnet, and simply treat both as part of a larger "trusted" area?
-jk
|
|
Top
|
|
|
|
|
#243153 - 14/04/2005 16:32
Re: VPN Help
[Re: jmwking]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
I don't know. To either your question, or Bitt's. Maybe Meatballman would know.
|
|
Top
|
|
|
|
|
#243154 - 14/04/2005 16:55
Re: VPN Help
[Re: tfabris]
|
old hand
Registered: 27/02/2003
Posts: 777
Loc: Washington, DC metro
|
So go ahead and try it! Use a differnet subnet (in my earlier example, try a pool in 192.168.3.0), and try connecting (from outside the firewall, of course - a dialup connection would work for testing). See what IP you get assigned on your remote computer. Then try to connect to a machine over a port you know (a web connection, some sort of terminal/vnc, etc), and do a netstat /a type of command to see what IP is connecting to the inside computer. Someone who obsesses over obscure registry entries to change miniscule windows settings should be able to poke at a firewall. Just save your existing firewall configuration so you can restore it when^h^h^h^h if you mess it up.  -jk
|
|
Top
|
|
|
|
|
#243155 - 14/04/2005 16:59
Re: VPN Help
[Re: jmwking]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Yeah, I was gonna do that tonight.
3ven if I have to assign VPN users a 192.168.3.xxx subnet, I can add 192.168.3.xxx as a second valid address in the server configuration and then all should work at that point.
|
|
Top
|
|
|
|
|
#243156 - 14/04/2005 17:02
Re: VPN Help
[Re: tfabris]
|
old hand
Registered: 27/02/2003
Posts: 777
Loc: Washington, DC metro
|
I'm not sure you'll need to add the address to the server, so long as any firewall-type software on the server recognizes the 192.168.3.0 subnet as part of the "trusted" environment. We have 20 some subnets as part of our trusted network, and our internal servers are quite content to trust the routers to send the packets where they're supposed to go.
-jk
|
|
Top
|
|
|
|
|
#243157 - 14/04/2005 17:20
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 19/01/2002
Posts: 3584
Loc: Columbus, OH
|
Don't worry, the SonicWall will route the traffic between the two subnets and it will work the way you want it to work.
EDIT: yeah...what jmwking said. 
_________________________
~ John
|
|
Top
|
|
|
|
|
#243158 - 15/04/2005 00:00
Re: VPN Help
[Re: JBjorgen]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Quote:
Don't worry, the SonicWall will route the traffic between the two subnets and it will work the way you want it to work.
It doesn't seem to be doing that.
I got it all working, as far as I could tell, according to these instructions. I put that annoying Netopia DSL modem in Bridge mode, and did everything on the Sonicwall. I can now, using those instructions, connect to the sonicwall L2TP VPN server from a remote computer.
The internal company network lies on the 192.168.2.xxx subnet. The main company file server is 192.168.2.1 and the internal LAN address of the SonicWall is now 192.168.2.2.
But because of that limitation stated in those instructions, the people dialing into the sonicwall vpn cannot use 192.168.2.xxx addresses. If I try to tell the sonicwall to give them those addresses, it complains that matches its internal subnet and won't let me save those changes.
So I configure it to give the VPN users addresses in the 192.168.3.xxx subnet instead, and that works, and I can connect to the VPN, except.... I can't ping the main server on the 192.168.2.xxx subnet. 3 doesn't route to 2.
One work around would be simply to add 192.168.3.1 as an alternate IP address for the main server. Then it would lie on both subnets and respond appropriately to the VPN users. This will work. However, I can foresee a day when I add more servers, and I don't want to have to remember to add two IP addresses to every server I add.
So, any ideas?
|
|
Top
|
|
|
|
|
#243159 - 15/04/2005 00:09
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Quote:
One work around would be simply to add 192.168.3.1 as an alternate IP address for the main server.
Hmph, that doesn't even work.
I have no way of knowing if this VPN connection is even working unless I can ping something on the local LAN. And everything on the local LAN is on .2.
|
|
Top
|
|
|
|
|
#243161 - 15/04/2005 02:34
Re: VPN Help
[Re: tfabris]
|
pooh-bah
Registered: 12/02/2002
Posts: 2298
Loc: Berkeley, California
|
Quote:
When creating a L2TP IP pool on the SonicWALL device, the IP addresses must be a unique IP subnet – you cannot specify IP addresses from the LAN (or any other) interface subnet on the device.
I know knowthing about VPN's specifically, but I read through the whole linked document, and the only interpretation of that comment that I can figure out is that the IP's can't be from the LAN IP (dhcp) pool. The whole point of a VPN is that the IP's will be in the subnet, but since lower level traffic isn't getting through any existing DHCP server won't be able to hand out addresses. I assume the way to get around having seperate pools is to have a radius server that interfaces with the DHCP server, but since you're NATing you shouldn't have any shortage of IPs so that's kind of moot.
Matthew
|
|
Top
|
|
|
|
|
#243162 - 15/04/2005 05:07
Re: VPN Help
[Re: wfaulk]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Quote:
This will, apparently, kill any TCP session that's been open for 15 minutes, no matter if it's being used. Or maybe there's an idle thing. I don't quite remember, but I do remember it turning off legitimate TCP traffic. Anyway, the setting is there as a global setting, but the global setting doesn't actually affect anything. You have to set it in the connection-specific area.
Do you happen to remember exactly which screen this is on?
I've been having some behavior on the unit that indicates it might possibly be doing this to me.
Man, that's bad if that's what it's doing. You'd think they'd fix that.
|
|
Top
|
|
|
|
|
#243163 - 15/04/2005 10:39
Re: VPN Help
[Re: tfabris]
|
old hand
Registered: 27/02/2003
Posts: 777
Loc: Washington, DC metro
|
You probably can't just add the .3.1 address to the server as the server doesn't sit on the same physical network segment as the rest of the .3.0/24 subnet (which I suspect exists soley within the sonicwall box).
Can you ping from a .3.x address to any .2.x address (not just the server) and get a reply? Vice versa? Does the firewall have any log files showing what it's doing with the packets? Do you have any sort of sniffer to see if any .3.0 packets are entering the .2.0 subnet?
-jk
|
|
Top
|
|
|
|
|
#243164 - 15/04/2005 11:08
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 19/01/2002
Posts: 3584
Loc: Columbus, OH
|
Quote:
Do you happen to remember exactly which screen this is on?
Under Firewall->Advanced there is a a setting called "TCP Connection Inactivity Timeout - Default Connection Timeout (minutes):" This setting does not set the Timeout for everything on the box. It simply specifies what the default timeout will be for each new Access Rule that's created in the firewall. Each Access Rule has its own timeout.
Select the rule that reads "LAN * Any Allow" and hit configure. Go to the Advanced tab and you will find the setting "TCP Connection Inactivity Timeout (minutes):" Set it to whatever you like.
The default for the box is 5 minutes on every rule. If you want a specific service to have a higher timeout than the others, just create an Allow rule for that service and specify it there.
You accomplish bandwidth management in the same way.
_________________________
~ John
|
|
Top
|
|
|
|
|
#243165 - 15/04/2005 13:30
Re: VPN Help
[Re: JBjorgen]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Excellent. Found those screens. Taken care of. Hope that solves the problem. The problem was that the router seemed to "disappear" after a few minutes, and needed a reboot.
|
|
Top
|
|
|
|
|
#243166 - 15/04/2005 13:39
Re: VPN Help
[Re: jmwking]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Quote:
Can you ping from a .3.x address to any .2.x address (not just the server) and get a reply? Vice versa?
No, at least not that I can tell.
Quote:
Does the firewall have any log files showing what it's doing with the packets?
Hm. I'll look.
Quote:
Do you have any sort of sniffer to see if any .3.0 packets are entering the .2.0 subnet?
I could run ethereal I suppose, haven't tried that yet. I'm hoping that the SonicWall people know the answer to this question already and can help me. I think my support ticket sufficiently describes the problem. Crossing my fingers.
|
|
Top
|
|
|
|
|
#243167 - 15/04/2005 17:14
Re: VPN Help
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Gah. I'm talking to Apu Nahasapeemapetilon.
|
|
Top
|
|
|
|
|
#243168 - 15/04/2005 17:32
Re: VPN Help
[Re: tfabris]
|
old hand
Registered: 27/02/2003
Posts: 777
Loc: Washington, DC metro
|
You should get Jim Hogan involved. -jk
|
|
Top
|
|
|
|
|
|
Previous Topic
Index