News: This forum is now permanently frozen.
Pages: [1]
Topic: PPTP VPN IP assingment issue  (Read 3972 times)
« on: January 20, 2010, 17:06:20 »
basher590 *
Posts: 7

Hello,

I have recently taken over as the admin of a m0n0wall. I have used a fair few firewalls in my time but this is the first time with one of these.

I am trying to get the PPTP VPN server working. It was already setup, with the Server address being 192.168.124.19 (which is free on the LAN) and the client scope/remote address range being 192.168.124.0/28
The LAN subnet is 192.168.124.0/24

There are rules in the pptp section to allow any source/ protocol to any destinaction etc.

When I make a connection it logs in fine and assigns me the IP address 192.168.124.0 and obviously I cannot get to anything on the lan as .0 is the network address. So I changed the PPTP client subnet on the monowall to be 192.168.124.64/28 (also free on the LAN)

Saved the changes etc (it didn't ask me to apply) but when I connect I still get assigned the 192.168.124.0 address.
I have tried setting my client with a static address but the monowall rejects it when it tries to register on the network.
Do I need to reboot the box in order for the changes to take effect or am I missing something else?
It's running version 1.3b15
there is NO DHCP on the LAN interface of the monowall

Cheers

Chris
« Reply #1 on: March 02, 2010, 09:28:19 »
txalamar *
Posts: 1

Hi!

I have exactly the same issue. It seems to be a PC version bug. It doesn't happend with alix version. Pfsense has the same issue since it's based on monowall.

Do you plan a solution in the near?

Thank you Smiley
« Reply #2 on: March 04, 2010, 20:03:47 »
msbaker *
Posts: 8

You probably need to reboot the firewall to get PPTP to work right. My recollection was that was the way I got PPTP working in the past.

It is a bad idea to set the PPTP remote address range to overlay 192.168.xxx.0. The two ends of a class C 192.168.xxx block are considered the network and/or broadcast addresses. So you don't really want the PPTP remote address range to overlay 192.168.xxx.255 either. If you get back a PPTP remote address of 192.168.xxx.0 it will be useless.

As you have done, A good choice would be some block in the middle that is not be used. For example, set the client DHCP address range to:
  192.168.124.10-100 with a subnet mask of 255.255.255.0 and set the PPTP remote address range to 192.168.124.192/28 ( IP addresses 192.168.124.192 to 207). Then set the PPTP server to some address outside the remote address range, say 192.168.124.222.

You also need to add firewall rules under the PPTP VPN tab that allows PPTP traffic through. It sounds like you also have done this. I usually set this to allow any to any, since I use PPTP for admin access from the Internet (WAN) to devices behind monowall.

Just reboot monowall and all should be well.

One other caveat. You need to make sure that the Class C 192.168.124.xxx networks used by monowall do not conflict with the local network you are connecting from with the client. So if you are connecting from home behind a NAT firewall make sure the home IP addresses uses a different network block. Otherwise the client IP stack thinks this is a local IP address and doesn't route it through PPTP. That is why I ALWAYS choose less common class C address blocks for the monowall firewall LAN and OPTx subnets. So if I need to connect from some remote site at a place with free wifi, I am unlikely to conflict with the default 192.168.1.xxx or 192.168.255.x network blocks that many small wireless routers default to.

I've used PPTP just fine with the above setup for several years to remotely manage devices behind monowall with private IP addresses. I've used this same setup on 1.3b4 and onward as well as the final 1.3 RTM release. My only problem was that I got bit once by the caveat I mentioned above. So now I always change the monowall default LAN class C network during initial configuration.

-msbaker
« Reply #3 on: September 09, 2010, 14:17:26 »
basher590 *
Posts: 7

Hey,
I know this is late, but I just wanted to say thank you for replying to my post. Shocked)
I haven't been on here since my initial configuration glitches of monowall, which just goes to show how stable and robust it is.   Grin
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines