Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
MPD5 PPTP and L2TP server problem with FreeBSD 9.2-RELEASE-p1
174 views
Skip to first unread message
Dr. Rolf Jansen
Nov 16, 2013, 4:48:38 PM11/16/13
to
Hello!
On my FreeBSD home server I installed MPD 5.7 for it providing PPTP and L2TP Dial-In VPN connectivity for external clients, which worked very well. In the last week, I upgraded my home server from 9.1 RELEASE-p7 to 9.2-RELEASE-p1, using freebsd-update.
Now, the server behaves strange after a PPTP or a L2TP/IPsec-VPN connection had been established. The VPN client can access resources on the server, but not in the LAN and WAN, as it could on 9.1. Even more bugging is, that LAN clients cannot access the internet anymore, once a VPN connection was made, and the problem persists even after the VPN was disconnected, and persists after the mpd5 and racoon were killed, and any dangling SA and SPD had been flushed. netstat -nr and sockstat -4 show nothing strange. For getting back WAN connectivity for LAN clients, I need to restart the server.
First, I thought that this could be a problem of the ipsec patches that I applied to my custom kernel, and I did some tests with PPTP by mpd5 using a pristine 9.2 GENERIC one. The same happened with that. Once an external client established a PPTP-VPN connection, all the internal LAN clients were effectively clipped from he internet.
For the time being, I disabled mpd5, and switched to sl2tps, which is also based on netgraph, and it doesn't show said problem in the otherwise unmodified L2TP/IPsec setup - PPTP stays disabled though.
I really would like to have back a working mpd5, since it is more versatile, and since sl2tps shows a different problem, namely it does not tear-down the proxy-arp routes, that it installed into the routing tables.
I did not send a PR up to now. Can somebody confirm this problem? My best educated guess is, that this is a kernel (or kernel module) regression, but I am not sure. So, what category should a PR have -- Kernel or ports net/mpd5?
Best regards
Rolf
_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
On my FreeBSD home server I installed MPD 5.7 for it providing PPTP and L2TP Dial-In VPN connectivity for external clients, which worked very well. In the last week, I upgraded my home server from 9.1 RELEASE-p7 to 9.2-RELEASE-p1, using freebsd-update.
Now, the server behaves strange after a PPTP or a L2TP/IPsec-VPN connection had been established. The VPN client can access resources on the server, but not in the LAN and WAN, as it could on 9.1. Even more bugging is, that LAN clients cannot access the internet anymore, once a VPN connection was made, and the problem persists even after the VPN was disconnected, and persists after the mpd5 and racoon were killed, and any dangling SA and SPD had been flushed. netstat -nr and sockstat -4 show nothing strange. For getting back WAN connectivity for LAN clients, I need to restart the server.
First, I thought that this could be a problem of the ipsec patches that I applied to my custom kernel, and I did some tests with PPTP by mpd5 using a pristine 9.2 GENERIC one. The same happened with that. Once an external client established a PPTP-VPN connection, all the internal LAN clients were effectively clipped from he internet.
For the time being, I disabled mpd5, and switched to sl2tps, which is also based on netgraph, and it doesn't show said problem in the otherwise unmodified L2TP/IPsec setup - PPTP stays disabled though.
I really would like to have back a working mpd5, since it is more versatile, and since sl2tps shows a different problem, namely it does not tear-down the proxy-arp routes, that it installed into the routing tables.
I did not send a PR up to now. Can somebody confirm this problem? My best educated guess is, that this is a kernel (or kernel module) regression, but I am not sure. So, what category should a PR have -- Kernel or ports net/mpd5?
Best regards
Rolf
_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
Florian Smeets
Nov 16, 2013, 5:13:35 PM11/16/13
to
On 16/11/13 22:48, Dr. Rolf Jansen wrote:
> Hello!
gateway_enable="YES" in /etc/rc.conf. This is caused by some changes in
the rc system and the scripts it calls on interface creation. This bit
me too.
It looks like directly setting net.inet.ip.forwarding in sysctl.conf has
never been officially supported. Though the last time I used
gateway_enable was probably in the 4.X days, and setting it in
sysctl.conf has always worked for me, until now :)
Florian
> Hello!
>
> Now, the server behaves strange after a PPTP or a L2TP/IPsec-VPN
> connection had been established. The VPN client can access resources
> on the server, but not in the LAN and WAN, as it could on 9.1. Even
> more bugging is, that LAN clients cannot access the internet anymore,
> once a VPN connection was made, and the problem persists even after
> the VPN was disconnected, and persists after the mpd5 and racoon were
> killed, and any dangling SA and SPD had been flushed. netstat -nr and
> sockstat -4 show nothing strange. For getting back WAN connectivity
> for LAN clients, I need to restart the server.
>
Do you set net.inet.ip.forwarding in /etc/sysctl.conf? Try setting
> Now, the server behaves strange after a PPTP or a L2TP/IPsec-VPN
> connection had been established. The VPN client can access resources
> on the server, but not in the LAN and WAN, as it could on 9.1. Even
> more bugging is, that LAN clients cannot access the internet anymore,
> once a VPN connection was made, and the problem persists even after
> the VPN was disconnected, and persists after the mpd5 and racoon were
> killed, and any dangling SA and SPD had been flushed. netstat -nr and
> sockstat -4 show nothing strange. For getting back WAN connectivity
> for LAN clients, I need to restart the server.
>
gateway_enable="YES" in /etc/rc.conf. This is caused by some changes in
the rc system and the scripts it calls on interface creation. This bit
me too.
It looks like directly setting net.inet.ip.forwarding in sysctl.conf has
never been officially supported. Though the last time I used
gateway_enable was probably in the 4.X days, and setting it in
sysctl.conf has always worked for me, until now :)
Florian
Dr. Rolf Jansen
Nov 16, 2013, 5:52:06 PM11/16/13
to
Many thanks for the helpful hint.
Best regards
Rolf
Raimundo Santos
Nov 16, 2013, 9:22:35 PM11/16/13
to
On 16 November 2013 20:52, Dr. Rolf Jansen <r...@obsigna.com> wrote:
>
> Am 16.11.2013 um 20:13 schrieb Florian Smeets <f...@smeets.im>:
>
> > On 16/11/13 22:48, Dr. Rolf Jansen wrote:
> >
> >
> > Do you set net.inet.ip.forwarding in /etc/sysctl.conf? Try setting
> > gateway_enable="YES" in /etc/rc.conf. This is caused by some changes in
> > the rc system and the scripts it calls on interface creation. This bit
> > me too.
> >
> > It looks like directly setting net.inet.ip.forwarding in sysctl.conf has
> > never been officially supported. Though the last time I used
> > gateway_enable was probably in the 4.X days, and setting it in
> > sysctl.conf has always worked for me, until now :)
>
same problem to me:
>
> Am 16.11.2013 um 20:13 schrieb Florian Smeets <f...@smeets.im>:
>
> > On 16/11/13 22:48, Dr. Rolf Jansen wrote:
> >
> >
> > Do you set net.inet.ip.forwarding in /etc/sysctl.conf? Try setting
> > gateway_enable="YES" in /etc/rc.conf. This is caused by some changes in
> > the rc system and the scripts it calls on interface creation. This bit
> > me too.
> >
> > It looks like directly setting net.inet.ip.forwarding in sysctl.conf has
> > never been officially supported. Though the last time I used
> > gateway_enable was probably in the 4.X days, and setting it in
> > sysctl.conf has always worked for me, until now :)
>
http://thread.gmane.org/gmane.os.freebsd.devel.net/40700/focus=40701
Eugene's follow up was very instructive. By now, my production router have
gateway_enable="YES" even with sysctl.conf configured to forward packets.
Where can we send a PR? As sugested by Eugene, it is not fault of MPD,
right?
cheers,
Raimundo Santos
Dr. Rolf Jansen
Nov 17, 2013, 7:38:58 PM11/17/13
to
Am 17.11.2013 um 00:22 schrieb Raimundo Santos <rai...@gmail.com>:
> On 16 November 2013 20:52, Dr. Rolf Jansen <r...@obsigna.com> wrote:
>
>> Am 16.11.2013 um 20:13 schrieb Florian Smeets <f...@smeets.im>:
>>
>>> On 16/11/13 22:48, Dr. Rolf Jansen wrote:
>>>
>>>
>>> Do you set net.inet.ip.forwarding in /etc/sysctl.conf? Try setting
>>> gateway_enable="YES" in /etc/rc.conf. This is caused by some changes in
>>> the rc system and the scripts it calls on interface creation. This bit
>>> me too.
>>>
>>> It looks like directly setting net.inet.ip.forwarding in sysctl.conf has
>>> never been officially supported. Though the last time I used
>>> gateway_enable was probably in the 4.X days, and setting it in
>>> sysctl.conf has always worked for me, until now :)
>
> same problem to me:
> http://thread.gmane.org/gmane.os.freebsd.devel.net/40700/focus=40701
>
> Eugene's follow up was very instructive. By now, my production router have
> gateway_enable="YES" even with sysctl.conf configured to forward packets.
>
> Where can we send a PR? As sugested by Eugene, it is not fault of MPD,
> right?
A PR can be send using the following web interface:
> On 16 November 2013 20:52, Dr. Rolf Jansen <r...@obsigna.com> wrote:
>
>> Am 16.11.2013 um 20:13 schrieb Florian Smeets <f...@smeets.im>:
>>
>>> On 16/11/13 22:48, Dr. Rolf Jansen wrote:
>>>
>>>
>>> Do you set net.inet.ip.forwarding in /etc/sysctl.conf? Try setting
>>> gateway_enable="YES" in /etc/rc.conf. This is caused by some changes in
>>> the rc system and the scripts it calls on interface creation. This bit
>>> me too.
>>>
>>> It looks like directly setting net.inet.ip.forwarding in sysctl.conf has
>>> never been officially supported. Though the last time I used
>>> gateway_enable was probably in the 4.X days, and setting it in
>>> sysctl.conf has always worked for me, until now :)
>
> same problem to me:
> http://thread.gmane.org/gmane.os.freebsd.devel.net/40700/focus=40701
>
> Eugene's follow up was very instructive. By now, my production router have
> gateway_enable="YES" even with sysctl.conf configured to forward packets.
>
> Where can we send a PR? As sugested by Eugene, it is not fault of MPD,
> right?
http://www.freebsd.org/send-pr.html
For an overview of the PR system, you might want to read the following:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/contrib-how.html#CONTRIB-GENERAL
I switched to gateway_enable="YES" in rc.conf, and in addition I disabled devd. I don't need to edit the sysctl directly, it was only a habit.
Best regards
Rolf
Raimundo Santos
Nov 22, 2013, 10:26:35 AM11/22/13
to
On 17 November 2013 22:38, Dr. Rolf Jansen <r...@obsigna.com> wrote:
> I switched to gateway_enable="YES" in rc.conf, and in addition I disabled
> devd. I don't need to edit the sysctl directly, it was only a habit.
Me too got this habit.
> I switched to gateway_enable="YES" in rc.conf, and in addition I disabled
> devd. I don't need to edit the sysctl directly, it was only a habit.
I do not see the real need to do a PR by now, no time to evaluate if the
problems noted by Eugene worth the PR.
Thank you.
Hooman Fazaeli
Nov 22, 2013, 3:15:18 PM11/22/13
to
On 11/22/2013 6:56 PM, Raimundo Santos wrote:
> On 17 November 2013 22:38, Dr. Rolf Jansen <r...@obsigna.com> wrote:
>
>> I switched to gateway_enable="YES" in rc.conf, and in addition I disabled
>> devd. I don't need to edit the sysctl directly, it was only a habit.
>
> Me too got this habit.
>
> I do not see the real need to do a PR by now, no time to evaluate if the
> problems noted by Eugene worth the PR.
>
> Thank you.
> _______________________________________________
IMHO, It is wrong to check forwarding status from gateway_enable.
> On 17 November 2013 22:38, Dr. Rolf Jansen <r...@obsigna.com> wrote:
>
>> I switched to gateway_enable="YES" in rc.conf, and in addition I disabled
>> devd. I don't need to edit the sysctl directly, it was only a habit.
>
> Me too got this habit.
>
> I do not see the real need to do a PR by now, no time to evaluate if the
> problems noted by Eugene worth the PR.
>
> Thank you.
> _______________________________________________
rc.conf settings are meant for startup configuration and not indicators
of the running status of the system.
A PR would be the least contribution to fixing the problem and
saving the time of other freebsd users.
--
Best regards.
Hooman Fazaeli
0 new messages