PPTP/L2TP on interfaces

sevet

This is by far a great FW with the L2TP/PPTP the only limitation for me.

I had to move to a PPTP/L2TP solution as the ISPs are forcing this by giving crappy service on DHCP only service.
Currently I installed a virtual linux with xl2tp client and so making double nat on linux and pfsense.

I'm very experienced in networking, worked at the engineering of one of the ISP's in Israel.
I will try to make a very detailed general explanation of the process (not specific to how it should look on pf-sense):

Setup before the process: l2tp/pptp server (not just IP, can be DNS entry of server), user/password

1.) Router (any router, could be windows client) - sends DHCP request to the cable company (not the ISP).
2.) Router Gets DHCP address from cable company - usually a private address but it doesn't matter if its public
3.) Router also get from DHCP default GW to the cable company and DNSes of the cable company (not DNS of the ISPs)
4.) Router performs DNS query for the l2tp/pptp server IP (the cable company has in their DNS servers all the servers of all the ISP's)
5.) Router should add static route of the IP it got to the l2tp/pptp server to the default GW of the cable company (as when the tunnels is created the default gw changes to it and we then can loose the tunnel)
6.) open l2tp/pptp tunnel to the IP we got
7.) remove the current default gw and change the gw to the tunnel interface (could be that default gw is pushed from the l2tp/pptp protocol so we just use it, but still remove the default gw of the cable company)
8.) DNSes are also pushed from the l2tp/pptp connection

What I do on linux scripts is save the resolve.conf of the cables, also get the default cables gw and resolved ip of the l2tp/pptp server to add the static route so the l2tp/pptp tunnel still goes to the cables GW and the rest of the traffic flows through the ppp0 tunnel interface

example:

I got from the cables a DHCP address of: 172.16.200.100 gw: 172.16.200.1 DNS: 192.168.101.101 (yes dns is private IP)
I resolve l2tp.bezeq.net to: 208.73.210.29
I route add 208.73.210.29/32 to (cables) gw 172.16.200.1
I open l2tp tunnel to: 208.73.210.29
on successful connection I add default gw to ppp0 interface (if not pushed from the tunnel, usually in configuration option on the l2tp client if dgw accepted), I should have also gotten the ISPs DNS servers from the tunnel.

Hope this helps, please let me know if more information is needed.
I would love to see it works on pfsense.

eri--

I created this to follow and not loose the description http://redmine.pfsense.org/issues/1349.

Loke

Need L2TP on WAN interface badly as well. So many changes in 2.0 and still no L2TP and still no DHCP+PPPoE/PPTP/L2TP. I don't understand why. Why so many useless crap added and no badly needed by so many people features…

Ozzik

Why so many useless crap added and no badly needed by so many people features…

hey, come on man, don't say that. These guys work really hard and are not asking for a penny in return. You should be grateful.
Plus, don't forget that if you don't need some feature (or 10 of them) - doesn't mean nobody does, after all - these were all requested things.

This situation with the PPTP/L2TP dialer really sucks, but as I understood from one of the devs - they don't want to break a bunch of already working stuff just to implement this feature. But now that we have a better explanation (thanks, sevet) of this process, maybe it will be easier to work out. Or like I said before, maybe it would be easier to implement as a package, so that we don't have have to wait for the next version.

sevet

@ermal:

I created this to follow and not loose the description http://redmine.pfsense.org/issues/1349.

Thanks for adding this ermal :)

Implementing what I wrote will be great, the next step should be also implementing some sort of keep alive mechanism as l2tp/pptp connections tend to disconnect sometimes…

Usually the l2tp/pptp dialers (like xl2tp for linux) have internal mechanisms to redial when connection is dropped but that can be problematic in some cases:

Explanation:
The one IP we get by resolving the dns entry of the l2tp/pptp server is usually a load balanced IP, some ISPs use simple DNS load balance, so when we resolve the example l2tp.bezeq.net we can get from the DNS more than one IP, sometimes the address represent a load balancer (cluster) that hold many servers under it.
The ISPs tend to (not frequently) refresh those IPs, so systems with long uptime with the method I wrote which the dialer use an IP and not dns entry can try to connect to a server which no longer exist.
The problem in using the DNS entry (not the IP) is that we get the IP for the server from the cables DNS and then we move to the ISP dns, the ISP dns does hold that entry but if we loose the connection we won't reach it....

So there are two issues I deal with implementing this on linux boxes that I connect this way:
1. Detecting the fault
2. Handling the fault

For detection I use a simple ping to the first hop after the tunnel, I put it statically in my scripts, this is not that good as that ip might change as well, for a production grade system like pfsense this can be done as a configuration option what to ping (track ip) or even dynamically maybe doing a trace route and putting the first hop (trace route can be done to any public IP but not private as it might be blocked by anti spoofing mechanisms)

To handle the fault I just clear everything: stop the l2tp/pptp deamon, ifdown the DHCP interface (the one connected to the cables modem) then bring the interface back up get DHCP address and start the process.

A more complicated way would be to just stop the l2tp/pptp daemon remove the static route (we have to remember what it was) change back to the DNS of the cables and start the process from number step 4.

I will be glad to help in anyway if needed.

Loke

@Ozzik:

Why so many useless crap added and no badly needed by so many people features…

hey, come on man, don't say that. These guys work really hard and are not asking for a penny in return. You should be grateful.
Plus, don't forget that if you don't need some feature (or 10 of them) - doesn't mean nobody does, after all - these were all requested things.

I'm grateful, really. Many thanks to guys for doing this really hard work. ;) But really. Is it too hard to implement this feature? No, i don't think so. Every crappy cheap router based on unix got this, m0n0wall got this (mod really, but not important). What so hard in this? All this done with mpd, like PPTP and PPPoE. What's the problem? Damn, pfSense got even L2TP server, but no client. I see the only reason why it's not there. Only Russia and Israel needs this, so who cares right. :-\ So like you said. If someone don't need some feature (L2TP) doesn't mean nobody (plenty of other people) does. But it's not there. Not in 1.2.3 not even in 2.0 feature list. I don't really get it. Why??? ???
I love pfSense! It's a really great BSD based firewall! But so small and meanwhile so important feature missing and this makes me sad. :'( I'm forced to use cheap router only to maintain dialing, but you can imagine performance of this connection.

P.S. No offence please, just trying to understand. ;)

Loke

@sevet:

@ermal:

I created this to follow and not loose the description http://redmine.pfsense.org/issues/1349.

Explanation:
The one IP we get by resolving the dns entry of the l2tp/pptp server is usually a load balanced IP, some ISPs use simple DNS load balance, so when we resolve the example l2tp.bezeq.net we can get from the DNS more than one IP, sometimes the address represent a load balancer (cluster) that hold many servers under it.
The ISPs tend to (not frequently) refresh those IPs, so systems with long uptime with the method I wrote which the dialer use an IP and not dns entry can try to connect to a server which no longer exist.
The problem in using the DNS entry (not the IP) is that we get the IP for the server from the cables DNS and then we move to the ISP dns, the ISP dns does hold that entry but if we loose the connection we won't reach it….

See no problem in this. Can be solved with script.

IF drop L2TP connect -> reconnect IF no luck n times -> release WAN DHCP interface -> renew WAN DHCP interface -> connect to somel2tp.something.com

Quite simplified, but you get the point, i hope :)

gnhb

@Loke:

Need L2TP on WAN interface badly as well. So many changes in 2.0 and still no L2TP and still no DHCP+PPPoE/PPTP/L2TP. I don't understand why. Why so many useless crap added and no badly needed by so many people features…

Status of L2TP is here: http://redmine.pfsense.org/issues/475

DHCP + PPPoE/PPtP does work in pfSense in 2.0. You configure two separate interfaces, one for DHCP from the modem, and one for the actual PPPoE/PPtP link. Check forums of wiki for more details.
GB

Loke

@gnhb:

@Loke:

Need L2TP on WAN interface badly as well. So many changes in 2.0 and still no L2TP and still no DHCP+PPPoE/PPTP/L2TP. I don't understand why. Why so many useless crap added and no badly needed by so many people features…

Status of L2TP is here: http://redmine.pfsense.org/issues/475

DHCP + PPPoE/PPtP does work in pfSense in 2.0. You configure two separate interfaces, one for DHCP from the modem, and one for the actual PPPoE/PPtP link. Check forums of wiki for more details.
GB

Thank you. I'll take a look. But currently i'm really need L2TP on WAN. In my country we have a lot of internet providers, but all of them have very poor REAL speeds/quality :(, except one. And guess what? This provider allow access to the global network only over L2TP tunnel. Without L2TP connection there is no internet access at all. That's the reason i need L2TP capability. Without it there is no real sense to use pfSense. :D

sevet

@gnhb:

@Loke:

Need L2TP on WAN interface badly as well. So many changes in 2.0 and still no L2TP and still no DHCP+PPPoE/PPTP/L2TP. I don't understand why. Why so many useless crap added and no badly needed by so many people features…

Status of L2TP is here: http://redmine.pfsense.org/issues/475

DHCP + PPPoE/PPtP does work in pfSense in 2.0. You configure two separate interfaces, one for DHCP from the modem, and one for the actual PPPoE/PPtP link. Check forums of wiki for more details.
GB

1. If you follow this entire thread you will see that the option built in for two interfaces one for DHCP and on for PPP does not work without modifications
2. The link you gave is the status of L2TP+IPSEC which is not relevant as connecting to the ISP is without the IPSEC and if IPSEC is tried it will not work (windows ISP clients remove the windows default IPSEC of L2TP on the registry for that)
3. We have a new "to be implemented" link thanks to ermal http://redmine.pfsense.org/issues/1349

I don't really get the PPP interface menu, I can't figure out the local IP i need to put in there, what is it for? is it going to be the interface IP and it will access the L2TP server through the wan interface using nat? will there then be a different tunnel interface that will get the IP from the L2TP server? this seems unnecessary to me. (instead just using the Local IP of the interface that has the route to the L2TP server, could be the default route)

All the configurations options for the user to put in should be:
interface type: DHCP+L2TP (or PPTP, L2TP is more important/widely implemented)
L2TP/PPTP server
user name
password

Thats it. (no local ip)
Also, L2TP shouldn't try to use IPSec

Loke

@sevet:

…

All the configurations options for the user to put in should be:
interface type: DHCP+L2TP (or PPTP, L2TP is more important/widely implemented)
L2TP/PPTP server
user name
password

Thats it. (no local ip)
Also, L2TP shouldn't try to use IPSec

Totally agree with sevet. No local IP and no IPSec. And yes, DHCP+PPPoE/PPTP/L2TP doesn't work at all. About PPTP. Many providers already refused from using this type of VPN because of low max speeds could be reached using this protocol. Instead they migrate on L2TP. So L2TP is present and near future as PPTP is past. And it's still not implemented. This is nonsense.

@sevet:

We have a new "to be implemented" link thanks to ermal http://redmine.pfsense.org/issues/1349

Target version 2.1 :'( So how many years we need to wait for this feature? :D

I think on the ticket page must be a "vote" button. So developers can analyze how many people need asked features and set priorities for those tickets on the basis of votes number. ::)

Micky

I think on the ticket page must be a "vote" button. So developers can analyze how many people need asked features and set priorities for those tickets on the basis of votes number.

As far as i understand the pfSense dev team chooses what to focus on based on their commercial need and not by public demand.
You can always add a bounty to a feature you want
http://forum.pfsense.org/index.php/board,34.0.html

P.S. Ежели руки дойдут написать самому, то обязательно поделюсь с публикой. Однако времени на данный момент на это не хватает.

(from http://forum.pfsense.org/index.php/topic,24734.msg174490.html#msg174490)

Is it too hard to implement this feature? No, i don't think so.

you're implying that this can be easily implemented, so why no to do so?
its an open source software, you're welcome to add patches…..

As much as i would like DHCP+L2TP/PPTP implemented i don't see how this attitude is helpful, the devs don't owe us anything
and it is their time & effort. instead of this, how about helping with logs & info when asked.....
or even more useful is to try and debug the connection and point exactly what's not working.

P.S thanks to gnhb who put time into this (and ermal)! hopefully he, Evgeny or one of the devs will finish it, as i wrote earlier, with some changes it is possible to get it working.

P.P.S DHCP+PPPoE fully working (as far as i saw over the forums) but DHCP+PPTP have the same problems as L2TP (mainly handling default gateway before and after dialing as far as i remember)

Loke

@Micky:

P.S. Ежели руки дойдут написать самому, то обязательно поделюсь с публикой. Однако времени на данный момент на это не хватает.

(from http://forum.pfsense.org/index.php/topic,24734.msg174490.html#msg174490)

Is it too hard to implement this feature? No, i don't think so.

you're implying that this can be easily implemented, so why no to do so?
its an open source software, you're welcome to add patches…..

As you already noticed this is my post and i really have no time at this point to do this. It's not hard to make this work under FreeBSD, but pfSense… Need to fully understand the architecture of system. Yes, it's BSD based, yes it open source, but the problem in time needed to understand the structure of the system. If someone can at least point me at source of information about how pfSense built maybe it will be much easier(faster) to do this. I'm working in huge telecommunication corp and really have no much of free time :).
As i said if i'll do this i'll surely share with public. ;)

eri--

Ask your huge management to give you time on this or the money needed.
Otherwise the answer is when its done.

gnhb

@sevet:

1. If you follow this entire thread you will see that the option built in for two interfaces one for DHCP and on for PPP does not work without modifications
2. The link you gave is the status of L2TP+IPSEC which is not relevant as connecting to the ISP is without the IPSEC and if IPSEC is tried it will not work (windows ISP clients remove the windows default IPSEC of L2TP on the registry for that)
3. We have a new "to be implemented" link thanks to ermal http://redmine.pfsense.org/issues/1349

I don't really get the PPP interface menu, I can't figure out the local IP i need to put in there, what is it for? is it going to be the interface IP and it will access the L2TP server through the wan interface using nat? will there then be a different tunnel interface that will get the IP from the L2TP server? this seems unnecessary to me. (instead just using the Local IP of the interface that has the route to the L2TP server, could be the default route)

All the configurations options for the user to put in should be:
interface type: DHCP+L2TP (or PPTP, L2TP is more important/widely implemented)
L2TP/PPTP server
user name
password

Thats it. (no local ip)
Also, L2TP shouldn't try to use IPSec

Yep, you're right on all points. I mis-understood you. I actually started to implement support for this in 2.0 but didn't finish it. I'm still willing to put some time in on it though. Your description is the clearest we've gotten yet, so that's very helpful.

Regarding your local IP question. It's an available field but not required. We just exposed underlying variables in mpd5 without knowing if they'll be useful to everyone or no-one. :) Sounds like it's probably useful to no one so far, based on how ISP's are using L2TP. Anyway, just use what you need for your setup. Empty fields will be ignored.

I'll take another look at this soon. I think 2.0 is feature frozen so if I get something useful going it will be in a different repository.

Ermal, any possibility to still put this in 2.0?

GB

Loke

@ermal:

Ask your huge management to give you time on this or the money needed.
Otherwise the answer is when its done.

I'm fully understand this.:)
Besides i need this for my own purposes, not for company. So why should they. ;D

@gnhb:

I'll take another look at this soon. I think 2.0 is feature frozen so if I get something useful going it will be in a different repository.

Ermal, any possibility to still put this in 2.0?

Actually it's not necessary to put this in 2.0. It would be great to make this feature to be available through package in 2.0 and include this in main repository in later versions. ;)

As for empty field with local IP, it's not necessary for mpd to work, but GUI claims it's missing local IP when you trying to apply changes. At least in case of PPTP (there is no L2TP on WAN). Local IP is useless in our case because internet providers provides IP (and other conf) to us by DHCP. And it appears to be confusing to many people because of all this. :)
Btw what ver of mpd uses pfSense 2.0 RC-1 at this moment? As far as i understand it's mpd5. Am i right?

eri--

Well for l2tp the changes should not be many intrusive.
If someone prepares a diff i will see how intrusive it is before release.

Loke

Ok. We all understand that we getting pfSense completely free of charge. But guys already made and will make in future a huge work. Any work should be paid in a particular way. And if we need some unplanned by developers features we could say "thank you" for those features and we can do this even before this feature implemented.
Few posts ago i wrote about "Vote" button on ticket's page. What if this votes will reflect not only number of people who need asked feature, but also who ready to support pfSense project with some amount of $. So there can be placed "Thank you" button. Pressing this button on feature ticket page we providing support for the project and developers got our gratitude for their work.
I suppose many people need discussed here feature (PPTP/L2TP on interfaces). So why not say "thank you" together. In this way we are not buying features but supporting their implementation. And this not mean developers owe this feature to us, no. This only make them more interested in particular feature to be done.
Do you love pfSense, do you want it became even more great? Spare few coins on the project. No fixed amount. As much as you can. I think guys deserve that much at least for their work.
I think this can make things in this project better. And make it grow faster.

P.S. Don't throw tomatoes in me and sorry for my english.

Loke

I've managed to make L2TP on WAN work.
Changes are similar to Micky's, but much easier. So what i've done:
In /etc/inc/interfaces.inc
after line 1175 added next:

	else if ($ppp['type'] == "pptp")
		$type = "l2tp";

so now we got:

	if ($ppp['type'] == "ppp")
		$type = "modem";
	else if ($ppp['type'] == "pptp")
		$type = "l2tp";
	else
		$type = $ppp['type'];

in line 1494 (was 1492 in orig) replacing this:

		if ($type == "pptp" || $type == "l2tp") {
			$mpdconf .= << <eod<br>set pptp self {$localips[$pid]}
	set pptp peer {$gateways[$pid]}
	set pptp disable windowing

EOD;</eod<br>

with this:

		if ($type == "pptp") {
			$mpdconf .= << <eod<br>set pptp peer {$gateways[$pid]}
	set pptp disable windowing

EOD;
		}

		if ($type == "l2tp") {
			$mpdconf .= << <eod<br>set l2tp peer {$gateways[$pid]}

EOD;
		}</eod<br></eod<br>

What we have now is instead of PPTP we got L2TP.
I know it's a silly way, but it works. On interfaces page is still looks like it's PPTP, but really it's L2TP.
After two simple changes /var/etc/mpd_wan.conf looks this way:


startup:
	# configure the console
	set console close
	# configure the web server
	set web close

default:
pptpclient:
	create bundle static wan
	set iface name pptp0
	set iface route default
	set iface disable on-demand
	set iface idle 0
	set iface enable tcpmssfix
	set iface up-script /usr/local/sbin/ppp-linkup
	set iface down-script /usr/local/sbin/ppp-linkdown
	set ipcp ranges 0.0.0.0/0 0.0.0.0/0
	set ipcp enable req-pri-dns
	set ipcp enable req-sec-dns
	#log -bund -ccp -chat -iface -ipcp -lcp -link

	create link static wan_link0 l2tp
	set link action bundle wan
	set link disable multilink
	set link keep-alive 10 60
	set link max-redial 0
	set link disable chap pap
	set link accept chap pap eap
	set link disable incoming
	set link mtu 1492
	set auth authname "your login"
	set auth password your pass
	set l2tp peer 10.0.0.28
	open

After those few changes all you need is:
1. Assign WAN as PPTP and fill in all required fields. Local IP also need to be filled because frontend will not allow you apply changes without it.
2. Enter the shell via SSH (or use "Command Promt" in "Diagnostics") and delete one of assigned to physical WAN interface aliases.
To do this you need to say in shell: ifconfig "your physical interface" delete "Local IP" (one you've assigned in step1) or reboot your firewall (1st way is more reasonable IMHO).
3. Assign your physical interface as OPT so you can see it's configuration (optional).

All those simple changes gives us DHCP+L2TP on WAN. To make this work in normal way more changes need to be done.
Iv'e done most of needed changes to add L2TP not just replace PPTP. Will share after final tests.

L2TP.png_thumb

L2TP_routes.png_thumb

Loke

Ok. Now all changes are tested with positive results. :)
For now i'll attach few screens for demonstration. Diffs i'll post later.
This how /var/etc/mpd_wan.conf looks now:

startup:
	# configure the console
	set console close
	# configure the web server
	set web close

default:
l2tpclient:
	create bundle static wan
	set iface name l2tp0
	set iface route default
	set iface disable on-demand
	set iface idle 0
	set iface enable tcpmssfix
	set iface up-script /usr/local/sbin/ppp-linkup
	set iface down-script /usr/local/sbin/ppp-linkdown
	set ipcp ranges 0.0.0.0/0 0.0.0.0/0
	set ipcp enable req-pri-dns
	set ipcp enable req-sec-dns
	#log -bund -ccp -chat -iface -ipcp -lcp -link

	create link static wan_link0 l2tp
	set link action bundle wan
	set link disable multilink
	set link keep-alive 10 60
	set link max-redial 0
	set link disable chap pap
	set link accept chap pap eap
	set link disable incoming
	set link mtu 1492
	set auth authname "your_login"
	set auth password your_pass
	set l2tp peer 10.0.0.28
	open

Everything seems to work fine except l2tp auto-connect on restart. But for pptp everything works fine. I suppose in some place few lines for l2tp missing ::)

interfaces_conf_l2tp.png_thumb

interfaces_l2tp.png_thumb

routes_l2tp.png_thumb

status_l2tp.png_thumb