Re: npppd - changing clients' route table

[Stuart Henderson]

On 2021-09-12, Radek  wrote:
> Sorry for the late reply, adding ":framed-ip-netmask=255.255.255.0:" doesn't 
> solve the problem. Tested on Win10.

framed-ip-netmask controls addition of the route on the npppd machine,
not the client. You only use it if you have multiple addresses behind
one VPN client machine. i.e. one machine connects in and provides
service for multiple clients.

PPP does not have support for classless internet addressing, only the
old style classful addressing  where the netmask is fixed depending on
the address itself.

See 
https://en.m.wikipedia.org/wiki/Classful_network#Classful_addressing_definition

As Yasuoka-san wrote, you need to use a network where the "classful"
netmask is 255.255.255.0, which means the address is between 192.0.0.0
and 223.255.255.255, so for a RFC1918 address you must use something
starting with 192.168.

In order to reach 10.55.0.0/24 without setting the default gateway, you
can use the feature of the Microsoft client where it uses DHCP over
L2TP to fetch more information. This lets you tell the client to route
traffic to 10.55.0.0/24 via the VPN without extra config on the client.



> On Mon, 22 Feb 2021 14:55:52 +0900 (JST)
> YASUOKA Masahiko  wrote:
>
>> Hi,
>> 
>> On Sun, 21 Feb 2021 19:18:48 +0100
>> Radek  wrote:
>> >> The interface which terminate the tunnel has "192.168.4.254".
>> >> Right?
>> > Do you mean the other end of the tunnel? It is 10.109.4.254
>> > interface pppx0 address 10.109.4.254 ipcp IPCP
>> 
>> Sorry, "192.168.4.244" should have been "10.109.4.254".
>> 
>> >> How about if you configure the npppd-users
>> >> 
>> >> rdk:
>> >>   :password=pasword:\
>> >>   :framed-ip-address=10.109.4.254:\
>> >>   :framed-ip-netmask=255.255.255.0:
>> >> 
>> >> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
>> >> session authenticated by the above "rdk".
>> > I have tried to configure npppd-users with netmask /24, but it doesnt make 
>> > any changes. Still have all traffic to 10.0.0.0/8 going across the tunnel 
>> > to 10.109.4.254(VPN), but I need to push the traffic to 10.109.3.0/24 
>> > through the tunnel (via 10.109.4.254) and the rest of 10.0.0.0/8 through 
>> > default gw or sometimes some traffic to 10.0.0.0/8 through another tunnel 
>> > at the same time. Now if the PPP tunnel is established the VPN catches all 
>> > the 10.0.0.0/8 traffic.
>> > 
>> > The VPN client (Windows7/10) is configured to NOT use the VPN as remote gw.
>> > 
>> > Example:
>> > I have a public, static IP. There is configured route to 10.55.0.0/24 at 
>> > the ISP's side and I dont need any VPN tunnel to access 10.55.. 
>> > Somewhere over the rainbow is a router with LAN 10.109.3.0/24 and npppd.
>> > If I use the PPP tunnel I can acces 10.109.3.0/24 but at the same time I 
>> > can't access 10.55.0.0/24 because all 10.0.0.0/8 goes across the tunnel.
>> 
>> The route to the natural netmask of the tunnel address, 10.0.0.0/8 in
>> this case, is configured by Windows automatically.  I don't know a way
>> to stop or override this.  But by using another addresses for the
>> tunnel, you can avoid the problem.  Also we can use dhcpd(8) to push
>> routes configuration.
>> 
>> For example,
>> 
>> 1. Use 192.168.255.0/24 for the tunnel to avoid the conflict on
>>10.0.0.0/8.
>> 
>>ipcp IPCP {
>>   pool-address 192.168.255.1-192.168.255.32
>> :
>>interface pppx0 address 192.168.255.254 ipcp IPCP
>>---
>>rdk:
>> :password=pasword:\
>> :framed-ip-address=192.168.255.32:
>> 
>> 2. Configure dhcpd
>> 
>>/etc/dhcpd-l2tp.conf
>>
>>subnet 192.168.255.0 netmask 255.255.255.0 {
>>  option classless-ms-static-routes 10.109.3.0/24 192.168.255.254;
>>  option classless-static-routes10.109.3.0/24 192.168.255.254;
>>}
>>---
>>   
>>$ doas /usr/sbin/dhcpd -u255.255.255.255 -c /etc/dhcpd-l2tp.conf
>> 
>> > On Sun, 21 Feb 2021 23:18:19 +0900 (JST)
>> > YASUOKA Masahiko  wrote:
>> > 
>> >> Hello,
>> >> 
>> >> On Sat, 20 Feb 2021 21:14:24 +0100
>> >> Radek  wrote:
>> >> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
>> >> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
>> >> > If the client is conencted to VPN all client'

Re: npppd - changing clients' route table

[Radek]

Sorry for the late reply, adding ":framed-ip-netmask=255.255.255.0:" doesn't 
solve the problem. Tested on Win10.

On Mon, 22 Feb 2021 14:55:52 +0900 (JST)
YASUOKA Masahiko  wrote:

> Hi,
> 
> On Sun, 21 Feb 2021 19:18:48 +0100
> Radek  wrote:
> >> The interface which terminate the tunnel has "192.168.4.254".
> >> Right?
> > Do you mean the other end of the tunnel? It is 10.109.4.254
> > interface pppx0 address 10.109.4.254 ipcp IPCP
> 
> Sorry, "192.168.4.244" should have been "10.109.4.254".
> 
> >> How about if you configure the npppd-users
> >> 
> >> rdk:
> >>   :password=pasword:\
> >>   :framed-ip-address=10.109.4.254:\
> >>   :framed-ip-netmask=255.255.255.0:
> >> 
> >> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
> >> session authenticated by the above "rdk".
> > I have tried to configure npppd-users with netmask /24, but it doesnt make 
> > any changes. Still have all traffic to 10.0.0.0/8 going across the tunnel 
> > to 10.109.4.254(VPN), but I need to push the traffic to 10.109.3.0/24 
> > through the tunnel (via 10.109.4.254) and the rest of 10.0.0.0/8 through 
> > default gw or sometimes some traffic to 10.0.0.0/8 through another tunnel 
> > at the same time. Now if the PPP tunnel is established the VPN catches all 
> > the 10.0.0.0/8 traffic.
> > 
> > The VPN client (Windows7/10) is configured to NOT use the VPN as remote gw.
> > 
> > Example:
> > I have a public, static IP. There is configured route to 10.55.0.0/24 at 
> > the ISP's side and I dont need any VPN tunnel to access 10.55.. 
> > Somewhere over the rainbow is a router with LAN 10.109.3.0/24 and npppd.
> > If I use the PPP tunnel I can acces 10.109.3.0/24 but at the same time I 
> > can't access 10.55.0.0/24 because all 10.0.0.0/8 goes across the tunnel.
> 
> The route to the natural netmask of the tunnel address, 10.0.0.0/8 in
> this case, is configured by Windows automatically.  I don't know a way
> to stop or override this.  But by using another addresses for the
> tunnel, you can avoid the problem.  Also we can use dhcpd(8) to push
> routes configuration.
> 
> For example,
> 
> 1. Use 192.168.255.0/24 for the tunnel to avoid the conflict on
>10.0.0.0/8.
> 
>ipcp IPCP {
>   pool-address 192.168.255.1-192.168.255.32
> :
>interface pppx0 address 192.168.255.254 ipcp IPCP
>---
>rdk:
> :password=pasword:\
> :framed-ip-address=192.168.255.32:
> 
> 2. Configure dhcpd
> 
>/etc/dhcpd-l2tp.conf
>
>subnet 192.168.255.0 netmask 255.255.255.0 {
>  option classless-ms-static-routes 10.109.3.0/24 192.168.255.254;
>  option classless-static-routes10.109.3.0/24 192.168.255.254;
>}
>---
>   
>$ doas /usr/sbin/dhcpd -u255.255.255.255 -c /etc/dhcpd-l2tp.conf
> 
> > On Sun, 21 Feb 2021 23:18:19 +0900 (JST)
> > YASUOKA Masahiko  wrote:
> > 
> >> Hello,
> >> 
> >> On Sat, 20 Feb 2021 21:14:24 +0100
> >> Radek  wrote:
> >> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
> >> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> >> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 
> >> > goes via 10.109.4.254
> >> > 
> >> > client> route print 
> >> > Network Destination   Netmask  Gateway  Interface Metric
> >> >   0.0.0.0  0.0.0.0   192.168.1.1
> >> > 192.168.1.101 20
> >> > 10.0.0.0  255.0.0.0 10.109.4.254  
> >> > 10.109.4.1 21
> >> > 10.109.4.1  255.255.255.255 On-link
> >> > 10.109.4.1276
> >> > [...]
> >> 
> >> The interface which terminate the tunnel has "192.168.4.254".
> >> Right?
> >> 
> >> > $ cat /etc/npppd/npppd-users
> >> > rdk:\
> >> > :password=pasword:\
> >> > :framed-ip-address=10.109.4.1:
> >> > #:framed-ip-netmask=255.255.255.0:
> >> 
> >> How about if you configure the npppd-users
> >> 
> >> rdk:
> >>   :password=pasword:\
> >>   :framed-ip-address=10.109.4.254:\
> >>   :framed-ip-netmask=255.255.255.0:
> >> 
> >> ?
> >> 
> >> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
> >> session authenticated by t

Re: npppd(8) and PROXY_AUTHEN_CHALLENGE bad length with Juniper

[Ryan Freeman]

Hello,

On Tue, Mar 09, 2021 at 02:41:43PM +0900, YASUOKA Masahiko wrote:
> Hi,
> 
> I looked into the ICCN packets you sent me separately.  Its "Proxy Authen
> Challenge" length is 31 and "Proxy Authen Type" is PPP CHAP.  The
> message seems to comply RFC 2661.
> 
> Also what I said
> >> It's for CHAP or MSCHAPv1.  If MD5 is selected for PPP CHAP, the
> >> challenge length for CHAP is 16 octet.  The challenge for MSCHAPv1 is
> >> also 8 octet, but npppd doesn't support MSCHAv1 anyway.  So 24 must be
> >> enough for RFC 2661.
> 
> is false.  Length of callenge is "independent of the hash algorithm".
> 
> In RFC 1994 (PPP CHAP):
> |  The Challenge Value is a variable stream of octets.  The
> |  importance of the uniqueness of the Challenge Value and its
> |  relationship to the secret is described above.  The Challenge
> |  Value MUST be changed each time a Challenge is sent.  The length
> |  of the Challenge Value depends upon the method used to generate
> |  the octets, and is independent of the hash algorithm used.
> 
> it doesn't state the limit clearly.
> 
> I suppose 24 had been long enough for many implementations, but
> actually new Junipor is using 31-63
> 
> >> > Feb  8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 Received 
> >> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 40 > 24
> >> > Feb  8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 SendCDN 
> >> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> >> > Feb  8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 Received 
> >> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 62 > 24
> >> > Feb  8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 SendCDN 
> >> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> >> > Feb  8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 Received 
> >> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 46 > 24
> >> > Feb  8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 SendCDN 
> >> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> >> > Feb  8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 Received 
> >> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 63 > 24
> >> > Feb  8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 SendCDN 
> >> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> 
> So I suppose changing the following limit will solve the problem.
> 
>   #define MAX_CHALLENGE_LENGTH24
> 
> Also I found a Junipor's document,
> 
>   
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/challenge-length-edit-dynamic-profiles-chap.html
> 
> the max challenge length can be configured 63 at the maximum.
> 
> I'm thinking change the limit in npppd to 96.

I've completed testing a build of npppd with MAX_CHALLENGE_LENGTH set to 96:

Index: npppd/ppp.h
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/ppp.h,v
retrieving revision 1.21
diff -u -p -r1.21 ppp.h
--- npppd/ppp.h 12 Aug 2017 11:20:34 -  1.21
+++ npppd/ppp.h 9 Mar 2021 19:17:33 -
@@ -82,7 +82,7 @@
 
 #defineMAX_USERNAME_LENGTH 256
 #defineMAX_PASSWORD_LENGTH     256
-#define MAX_CHALLENGE_LENGTH24
+#define MAX_CHALLENGE_LENGTH96
 
 #define INADDR_IPCP_OBEY_REMOTE_REQ0xL


With this in place, things are still working with our upstream's new
equipment!  This has also cleared up the "Proxy Authen Challenge is too
long" errors from layer=chap, and our sessions consistently establish
cleanly:

Mar  8 23:00:45 edge9 npppd[9258]: ppp id=27 layer=lcp dialin-proxy 
user=...@pppoe.example.com auth-type=MD5-CHAP renegotiate=no
Mar  8 23:00:45 edge9 npppd[9258]: ppp id=27 layer=base logtype=Started 
tunnel=L2TP(1.2.3.4:1701)
Mar  8 23:00:45 edge9 npppd[9258]: ppp id=27 layer=lcp logtype=Opened 
mru=1460/1460 auth=MD5-CHAP magic=xx55f2ac/xx65f7d0
Mar  8 23:00:45 edge9 npppd[9258]: ppp id=27 layer=chap proto=chap 
logtype=Success username="...@pppoe.example.com" realm=PGS-DYNAMIC
Mar  8 23:00:45 edge9 npppd[9258]: ppp id=27 layer=ipcp IP Address peer=0.0.0.0 
our=5.6.7.8.
Mar  8 23:00:45 edge9 npppd[9258]: ppp id=27 layer=ipcp logtype=Opened 
ip=5.6.7.8 assignType=dynamic
Mar  8 23:00:45 edge9 npppd[9258]: ppp id=27 layer=base logtype=TUNNELSTART 
user="...@pppoe.example.com" duration=0sec layer2=L2TP 
layer2from=1.2.3.4:1701 auth=MD5-CHAP  ip=5.6.7.8 iface=pppac1 dialin_proxy=yes
Mar  8 23:00:45 edge9 npppd[9258]: ppp id=27 layer=base Using pipex=yes


Thank you again for your help and taking the time to look over the packet
captures.

-Ryan

Ryan Freeman
Senior Systems Administrator
Uniserve Communications
Suite 330 - 333 Terminal Avenue, Vancouver, BC V6A 4C1
Phone: 604.395.3905
Email:  ryan.free...@uniserveteam.com
www.uniserve.com

Re: npppd(8) and PROXY_AUTHEN_CHALLENGE bad length with Juniper

[YASUOKA Masahiko]

Hi,

I looked into the ICCN packets you sent me separately.  Its "Proxy Authen
Challenge" length is 31 and "Proxy Authen Type" is PPP CHAP.  The
message seems to comply RFC 2661.

Also what I said
>> It's for CHAP or MSCHAPv1.  If MD5 is selected for PPP CHAP, the
>> challenge length for CHAP is 16 octet.  The challenge for MSCHAPv1 is
>> also 8 octet, but npppd doesn't support MSCHAv1 anyway.  So 24 must be
>> enough for RFC 2661.

is false.  Length of callenge is "independent of the hash algorithm".

In RFC 1994 (PPP CHAP):
|  The Challenge Value is a variable stream of octets.  The
|  importance of the uniqueness of the Challenge Value and its
|  relationship to the secret is described above.  The Challenge
|  Value MUST be changed each time a Challenge is sent.  The length
|  of the Challenge Value depends upon the method used to generate
|  the octets, and is independent of the hash algorithm used.

it doesn't state the limit clearly.

I suppose 24 had been long enough for many implementations, but
actually new Junipor is using 31-63

>> > Feb  8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 Received 
>> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 40 > 24
>> > Feb  8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>> > Feb  8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 Received 
>> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 62 > 24
>> > Feb  8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>> > Feb  8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 Received 
>> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 46 > 24
>> > Feb  8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>> > Feb  8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 Received bad 
>> > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 63 > 24
>> > Feb  8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none

So I suppose changing the following limit will solve the problem.

  #define MAX_CHALLENGE_LENGTH24

Also I found a Junipor's document,

  
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/challenge-length-edit-dynamic-profiles-chap.html

the max challenge length can be configured 63 at the maximum.

I'm thinking change the limit in npppd to 96.


On Mon, 8 Mar 2021 20:33:21 +
Ryan Freeman  wrote:
> Thank you for the reply!  I have been given permission to show a bit
> more about our setup.  I snipped out some of the original message, and
> I'll post the additions at the bottom.
> 
> On Sat, Mar 06, 2021 at 07:45:03PM +0900, YASUOKA Masahiko wrote:
>> Hi,
>> 
>> On Fri, 5 Mar 2021 19:07:45 +
>> Ryan Freeman  wrote:
>> > Full disclosure: this took place over the course of about a month, and
>> > I've done my best to include the relevant info..
>> > 
>> > Unsure if this is really a bug, and I don't have a real diff for a fix, 
>> > just a
>> > work-around, so misc it is.
>> > 
>> > This is done with OpenBSD 6.8-stable, syspatch 001 through 012 installed.
>> > We considered trying -current, but noticed no activity in the npppd tree
>> > that might make a difference.
>> > 
>> > 'old' and 'new' equipment types from upstream are both Juniper, though
>> > unsure of exact models.  Old  should be Juniper ERX of some type, new
>> > I only know this from packet capture: Juniper Networks/Unisphere(4874).
>> > 
>> > I work for a small ISP and we are exploring the use of npppd(8) for
>> > termination of L2TP with incumbent for xDSL connections. 
>> > 
>> > Working with the provider, their 'old' equipment works fine[1], however,
>> > the 'new' network would always cause these errors upon receipt of Proxy 
>> > AVP:
>> > 
>> > Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 Received bad 
>> > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 33 > 24
>> > Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>> > 
>> > Looking at RFC 2661, I can't actually figure where a limit of 24 is 
>> > imposed,
>> >
> ...snip...
>> 
>> Yes.  The limit is come from 

Re: npppd(8) and PROXY_AUTHEN_CHALLENGE bad length with Juniper

[Ryan Freeman]

Thank you for the reply!  I have been given permission to show a bit
more about our setup.  I snipped out some of the original message, and
I'll post the additions at the bottom.

On Sat, Mar 06, 2021 at 07:45:03PM +0900, YASUOKA Masahiko wrote:
> Hi,
> 
> On Fri, 5 Mar 2021 19:07:45 +
> Ryan Freeman  wrote:
> > Full disclosure: this took place over the course of about a month, and
> > I've done my best to include the relevant info..
> > 
> > Unsure if this is really a bug, and I don't have a real diff for a fix, 
> > just a
> > work-around, so misc it is.
> > 
> > This is done with OpenBSD 6.8-stable, syspatch 001 through 012 installed.
> > We considered trying -current, but noticed no activity in the npppd tree
> > that might make a difference.
> > 
> > 'old' and 'new' equipment types from upstream are both Juniper, though
> > unsure of exact models.  Old  should be Juniper ERX of some type, new
> > I only know this from packet capture: Juniper Networks/Unisphere(4874).
> > 
> > I work for a small ISP and we are exploring the use of npppd(8) for
> > termination of L2TP with incumbent for xDSL connections. 
> > 
> > Working with the provider, their 'old' equipment works fine[1], however,
> > the 'new' network would always cause these errors upon receipt of Proxy AVP:
> > 
> > Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 Received bad 
> > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 33 > 24
> > Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 SendCDN 
> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> > 
> > Looking at RFC 2661, I can't actually figure where a limit of 24 is imposed,
> >
...snip...
> 
> Yes.  The limit is come from MAX_CHALLENGE_LENGTH in ppp.h.
> 
>  85 #define MAX_CHALLENGE_LENGTH24

Thank you!

> 
> In RFC 2661,
> 
>   This AVP MUST be present for Proxy Authen Types 2 and 5. The
>   Challenge field contains the CHAP challenge presented to the
>   client by the LAC.
> 
> Proxy Authen Challenge AVP is for "Proxy Authen Types 2 and 5".
> 
>Proxy Authen Type (ICCN)
>(snip)
>   Defined Authen Type values are:
>  0 - Reserved
>  1 - Textual username/password exchange
>  2 - PPP CHAP
>  3 - PPP PAP
>  4 - No Authentication
>  5 - Microsoft CHAP Version 1 (MSCHAPv1)
> 
> It's for CHAP or MSCHAPv1.  If MD5 is selected for PPP CHAP, the
> challenge length for CHAP is 16 octet.  The challenge for MSCHAPv1 is
> also 8 octet, but npppd doesn't support MSCHAv1 anyway.  So 24 must be
> enough for RFC 2661.
> 
> I'd like to see the packet capture of ICCN from Juniper to see what is
> happening.  (what authen type is used.)

I will contact you off-list about packet captures.

> >
...snip...
> > Ultimately we managed to get this working by simply omitting the size check
> > as such:
> > 
> > Index: l2tp/l2tp_call.c
> > ===
> > RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp_call.c,v
> > retrieving revision 1.19
> > diff -u -p -r1.19 l2tp_call.c
> > --- l2tp/l2tp_call.c5 Dec 2015 16:10:31 -   1.19
> > +++ l2tp/l2tp_call.c5 Mar 2021 17:46:12 -
> > @@ -546,7 +546,8 @@ l2tp_call_recv_ICCN(l2tp_call *_this, u_
> > dpi->last_recv_lcp.ldata = avp_attr_length(avp);
> > break;
> > case L2TP_AVP_TYPE_PROXY_AUTHEN_CHALLENGE:
> > -   AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall));
> > +   /* XXX: disable to try and skirt 'too long' errors */
> > +   /* AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall)); */
> > memcpy(dpi->auth_chall, avp->attr_value,
> > avp_attr_length(avp));
> > dpi->lauth_chall = avp_attr_length(avp);
> > 
> > We've been running this modified npppd for a week now, our upstream is happy
> > that they can continue phasing out their 'old' gear, and our endusers are
> 
> Do you mean that the endusers can connect with the above diff?

Absolutely.  Prior to disabling that particular size check, endusers do not
get past the RecvICCN stage due to "PROXY_AUTHEN_CHALLENGE too long" error.

> diff --git a/usr.sbin/npppd/npppd/ppp.h b/usr.sbin/npppd/npppd/ppp.h
> index 1bb8bfc6cf3..219b47c6172 100644
> --- a/usr.sbin/npppd/npppd/ppp.h
> +++ b/usr.sbin/npppd/npppd/ppp.h
> @@ -82,7 +82,7 @@
>  
>  #defineMAX_USERNAME_LENGTH     256
>  #defineMA

Re: npppd(8) and PROXY_AUTHEN_CHALLENGE bad length with Juniper

[YASUOKA Masahiko]

Hi,

On Fri, 5 Mar 2021 19:07:45 +
Ryan Freeman  wrote:
> Full disclosure: this took place over the course of about a month, and
> I've done my best to include the relevant info..
> 
> Unsure if this is really a bug, and I don't have a real diff for a fix, just a
> work-around, so misc it is.
> 
> This is done with OpenBSD 6.8-stable, syspatch 001 through 012 installed.
> We considered trying -current, but noticed no activity in the npppd tree
> that might make a difference.
> 
> 'old' and 'new' equipment types from upstream are both Juniper, though
> unsure of exact models.  Old  should be Juniper ERX of some type, new
> I only know this from packet capture: Juniper Networks/Unisphere(4874).
> 
> I work for a small ISP and we are exploring the use of npppd(8) for
> termination of L2TP with incumbent for xDSL connections. 
> 
> Working with the provider, their 'old' equipment works fine[1], however,
> the 'new' network would always cause these errors upon receipt of Proxy AVP:
> 
> Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 Received bad 
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 33 > 24
> Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 SendCDN 
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> 
> Looking at RFC 2661, I can't actually figure where a limit of 24 is imposed,
> though I was tricked as I counted the bits on top of their chart which does
> 
> From RFC 2661, "Proxy Authen Challenge (ICCN)" near page 37:
> 
>0   1   2   3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Challenge... (arbitrary number of octets) |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Looking at npppd's l2tp_subr.h where the error above comes from:
> 
> #define AVP_MAXLEN_CHECK(_avp, _maxlen) \
> do {\
> if ((_avp)->length > (_maxlen) + 6) {   \
> snprintf(emes, sizeof(emes),\
> "Attribute value is too long %s %d > %d",   \
> avp_attr_type_string((_avp)->attr_type),\
> (_avp)->length - 6, (int)(_maxlen));\
> goto size_check_failed; \
> }   \
> } while (/* CONSTCOND */0)
> 
> I drew wild conclusions that perhaps 24 + 6, which lines up with counting
> the bits on the RFC chart above, is how the limit was chosen.

Yes.  The limit is come from MAX_CHALLENGE_LENGTH in ppp.h.

 85 #define MAX_CHALLENGE_LENGTH24

In RFC 2661,

  This AVP MUST be present for Proxy Authen Types 2 and 5. The
  Challenge field contains the CHAP challenge presented to the
  client by the LAC.

Proxy Authen Challenge AVP is for "Proxy Authen Types 2 and 5".

   Proxy Authen Type (ICCN)
   (snip)
  Defined Authen Type values are:
 0 - Reserved
 1 - Textual username/password exchange
 2 - PPP CHAP
 3 - PPP PAP
 4 - No Authentication
     5 - Microsoft CHAP Version 1 (MSCHAPv1)

It's for CHAP or MSCHAPv1.  If MD5 is selected for PPP CHAP, the
challenge length for CHAP is 16 octet.  The challenge for MSCHAPv1 is
also 8 octet, but npppd doesn't support MSCHAv1 anyway.  So 24 must be
enough for RFC 2661.

I'd like to see the packet capture of ICCN from Juniper to see what is
happening.  (what authen type is used.)

> After many more days of packet captures and head scratching, I specifically
> saw that in the RADIUS packet, within the Attribute Value Pairs, it was
> CHAP-Challenge, type 60, that was overflowing this size check.
> 
> On to RFC 2865, page 59: https://tools.ietf.org/html/rfc2865#page-59
> 
> 0   1   2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>| Type  |Length |String...
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> Aha, this chart actually hits exactly 24.  Still no mention of a hard
> size limit, the only thing it dictates is:

This is unrelated.  It's 24 *bits*.

>Length
>   >= 7
> 
> Ultimately we managed to get this working by simply omitting the size check
> as such:
> 
> Index: l2tp/l2tp_call.c
> ===
> RCS file: /c

npppd(8) and PROXY_AUTHEN_CHALLENGE bad length with Juniper

[Ryan Freeman]

Hello!

Full disclosure: this took place over the course of about a month, and
I've done my best to include the relevant info..

Unsure if this is really a bug, and I don't have a real diff for a fix, just a
work-around, so misc it is.

This is done with OpenBSD 6.8-stable, syspatch 001 through 012 installed.
We considered trying -current, but noticed no activity in the npppd tree
that might make a difference.

'old' and 'new' equipment types from upstream are both Juniper, though
unsure of exact models.  Old  should be Juniper ERX of some type, new
I only know this from packet capture: Juniper Networks/Unisphere(4874).

I work for a small ISP and we are exploring the use of npppd(8) for
termination of L2TP with incumbent for xDSL connections. 

Working with the provider, their 'old' equipment works fine[1], however,
the 'new' network would always cause these errors upon receipt of Proxy AVP:

Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 Received bad 
ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 33 > 24
Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 SendCDN 
result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none

Looking at RFC 2661, I can't actually figure where a limit of 24 is imposed,
though I was tricked as I counted the bits on top of their chart which does
hit 32, nothing in the surrounding text actually dictates this size limit:

>From RFC 2661, "Proxy Authen Challenge (ICCN)" near page 37:

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Challenge... (arbitrary number of octets) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Looking at npppd's l2tp_subr.h where the error above comes from:

#define AVP_MAXLEN_CHECK(_avp, _maxlen) \
do {\
if ((_avp)->length > (_maxlen) + 6) {   \
snprintf(emes, sizeof(emes),\
"Attribute value is too long %s %d > %d",   \
avp_attr_type_string((_avp)->attr_type),\
(_avp)->length - 6, (int)(_maxlen));\
goto size_check_failed; \
}   \
} while (/* CONSTCOND */0)

I drew wild conclusions that perhaps 24 + 6, which lines up with counting
the bits on the RFC chart above, is how the limit was chosen.

After many more days of packet captures and head scratching, I specifically
saw that in the RADIUS packet, within the Attribute Value Pairs, it was
CHAP-Challenge, type 60, that was overflowing this size check.

On to RFC 2865, page 59: https://tools.ietf.org/html/rfc2865#page-59

0   1   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   | Type  |Length |String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Aha, this chart actually hits exactly 24.  Still no mention of a hard
size limit, the only thing it dictates is:

   Length
  >= 7

Ultimately we managed to get this working by simply omitting the size check
as such:

Index: l2tp/l2tp_call.c
===
RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp_call.c,v
retrieving revision 1.19
diff -u -p -r1.19 l2tp_call.c
--- l2tp/l2tp_call.c5 Dec 2015 16:10:31 -   1.19
+++ l2tp/l2tp_call.c5 Mar 2021 17:46:12 -
@@ -546,7 +546,8 @@ l2tp_call_recv_ICCN(l2tp_call *_this, u_
dpi->last_recv_lcp.ldata = avp_attr_length(avp);
break;
case L2TP_AVP_TYPE_PROXY_AUTHEN_CHALLENGE:
-   AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall));
+   /* XXX: disable to try and skirt 'too long' errors */
+   /* AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall)); */
memcpy(dpi->auth_chall, avp->attr_value,
avp_attr_length(avp));
dpi->lauth_chall = avp_attr_length(avp);

We've been running this modified npppd for a week now, our upstream is happy
that they can continue phasing out their 'old' gear, and our endusers are
able to get online.

Neither myself nor my colleague can figure out how '24' is chosen for _maxlen,
but as this finally got us moving forward, wanted to share what we had and see
if we are on the right track.

I am thinking that we would want a maximum length set there still, but perhaps
it can be pushed up?  I've seen many of those error types, 

Re: npppd - changing clients' route table

[YASUOKA Masahiko]

Hi,

On Sun, 21 Feb 2021 19:18:48 +0100
Radek  wrote:
>> The interface which terminate the tunnel has "192.168.4.254".
>> Right?
> Do you mean the other end of the tunnel? It is 10.109.4.254
> interface pppx0 address 10.109.4.254 ipcp IPCP

Sorry, "192.168.4.244" should have been "10.109.4.254".

>> How about if you configure the npppd-users
>> 
>> rdk:
>>   :password=pasword:\
>>   :framed-ip-address=10.109.4.254:\
>>   :framed-ip-netmask=255.255.255.0:
>> 
>> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
>> session authenticated by the above "rdk".
> I have tried to configure npppd-users with netmask /24, but it doesnt make 
> any changes. Still have all traffic to 10.0.0.0/8 going across the tunnel to 
> 10.109.4.254(VPN), but I need to push the traffic to 10.109.3.0/24 through 
> the tunnel (via 10.109.4.254) and the rest of 10.0.0.0/8 through default gw 
> or sometimes some traffic to 10.0.0.0/8 through another tunnel at the same 
> time. Now if the PPP tunnel is established the VPN catches all the 10.0.0.0/8 
> traffic.
> 
> The VPN client (Windows7/10) is configured to NOT use the VPN as remote gw.
> 
> Example:
> I have a public, static IP. There is configured route to 10.55.0.0/24 at the 
> ISP's side and I dont need any VPN tunnel to access 10.55.. Somewhere 
> over the rainbow is a router with LAN 10.109.3.0/24 and npppd.
> If I use the PPP tunnel I can acces 10.109.3.0/24 but at the same time I 
> can't access 10.55.0.0/24 because all 10.0.0.0/8 goes across the tunnel.

The route to the natural netmask of the tunnel address, 10.0.0.0/8 in
this case, is configured by Windows automatically.  I don't know a way
to stop or override this.  But by using another addresses for the
tunnel, you can avoid the problem.  Also we can use dhcpd(8) to push
routes configuration.

For example,

1. Use 192.168.255.0/24 for the tunnel to avoid the conflict on
   10.0.0.0/8.

   ipcp IPCP {
  pool-address 192.168.255.1-192.168.255.32
:
   interface pppx0 address 192.168.255.254 ipcp IPCP
   ---
   rdk:
:password=pasword:\
:framed-ip-address=192.168.255.32:

2. Configure dhcpd

   /etc/dhcpd-l2tp.conf
   
   subnet 192.168.255.0 netmask 255.255.255.0 {
 option classless-ms-static-routes 10.109.3.0/24 192.168.255.254;
 option classless-static-routes10.109.3.0/24 192.168.255.254;
   }
   ---
  
   $ doas /usr/sbin/dhcpd -u255.255.255.255 -c /etc/dhcpd-l2tp.conf

> On Sun, 21 Feb 2021 23:18:19 +0900 (JST)
> YASUOKA Masahiko  wrote:
> 
>> Hello,
>> 
>> On Sat, 20 Feb 2021 21:14:24 +0100
>> Radek  wrote:
>> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
>> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
>> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes 
>> > via 10.109.4.254
>> > 
>> > client> route print 
>> > Network Destination   Netmask  Gateway  Interface Metric
>> >   0.0.0.0  0.0.0.0   192.168.1.1
>> > 192.168.1.101 20
>> >     10.0.0.0  255.0.0.0 10.109.4.254  
>> > 10.109.4.1 21
>> > 10.109.4.1  255.255.255.255 On-link10.109.4.1  
>> >   276
>> > [...]
>> 
>> The interface which terminate the tunnel has "192.168.4.254".
>> Right?
>> 
>> > $ cat /etc/npppd/npppd-users
>> > rdk:\
>> > :password=pasword:\
>> > :framed-ip-address=10.109.4.1:
>> > #:framed-ip-netmask=255.255.255.0:
>> 
>> How about if you configure the npppd-users
>> 
>> rdk:
>>   :password=pasword:\
>>   :framed-ip-address=10.109.4.254:\
>>   :framed-ip-netmask=255.255.255.0:
>> 
>> ?
>> 
>> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
>> session authenticated by the above "rdk".
>> 
>> 
>> On Sat, 20 Feb 2021 21:14:24 +0100
>> Radek  wrote:
>> > Hi, 
>> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
>> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
>> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes 
>> > via 10.109.4.254
>> > 
>> > client> route print 
>> > Network Destination   Netmask  Gateway  Interface Metric
>> >   0.0.0.0  0.0.0.0   192.168.1.1
>> > 192.168.1.101 20
>> > 10.0.0.0  255.0.0.0 10.109.4.254  
>> > 

Fw: Re: npppd - changing clients' route table

[Radek]

Hello,

> The interface which terminate the tunnel has "192.168.4.254".
> Right?
Do you mean the other end of the tunnel? It is 10.109.4.254
interface pppx0 address 10.109.4.254 ipcp IPCP

> How about if you configure the npppd-users
> 
> rdk:
>   :password=pasword:\
>   :framed-ip-address=10.109.4.254:\
>   :framed-ip-netmask=255.255.255.0:
> 
> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
> session authenticated by the above "rdk".
I have tried to configure npppd-users with netmask /24, but it doesnt make any 
changes. Still have all traffic to 10.0.0.0/8 going across the tunnel to 
10.109.4.254(VPN), but I need to push the traffic to 10.109.3.0/24 through the 
tunnel (via 10.109.4.254) and the rest of 10.0.0.0/8 through default gw or 
sometimes some traffic to 10.0.0.0/8 through another tunnel at the same time. 
Now if the PPP tunnel is established the VPN catches all the 10.0.0.0/8 traffic.
The VPN client (Windows7/10) is configured to NOT use the VPN as remote gw.

Example:
I have a public, static IP. There is configured route to 10.55.0.0/24 at the 
ISP's side and I dont need any VPN tunnel to access 10.55.. Somewhere over 
the rainbow is a router with LAN 10.109.3.0/24 and npppd.
If I use the PPP tunnel I can acces 10.109.3.0/24 but at the same time I can't 
access 10.55.0.0/24 because all 10.0.0.0/8 goes across the tunnel.


On Sun, 21 Feb 2021 23:18:19 +0900 (JST)
YASUOKA Masahiko  wrote:

> Hello,
> 
> On Sat, 20 Feb 2021 21:14:24 +0100
> Radek  wrote:
> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes 
> > via 10.109.4.254
> > 
> > client> route print 
> > Network Destination   Netmask  Gateway  Interface Metric
> >   0.0.0.0  0.0.0.0   192.168.1.1
> > 192.168.1.101 20
> > 10.0.0.0  255.0.0.0 10.109.4.254  
> > 10.109.4.1 21
> > 10.109.4.1  255.255.255.255 On-link        10.109.4.1   
> >  276
> > [...]
> 
> The interface which terminate the tunnel has "192.168.4.254".
> Right?
> 
> > $ cat /etc/npppd/npppd-users
> > rdk:\
> > :password=pasword:\
> > :framed-ip-address=10.109.4.1:
> > #:framed-ip-netmask=255.255.255.0:
> 
> How about if you configure the npppd-users
> 
> rdk:
>   :password=pasword:\
>   :framed-ip-address=10.109.4.254:\
>   :framed-ip-netmask=255.255.255.0:
> 
> ?
> 
> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
> session authenticated by the above "rdk".
> 
> 
> On Sat, 20 Feb 2021 21:14:24 +0100
> Radek  wrote:
> > Hi, 
> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes 
> > via 10.109.4.254
> > 
> > client> route print 
> > Network Destination   Netmask  Gateway  Interface Metric
> >   0.0.0.0  0.0.0.0   192.168.1.1
> > 192.168.1.101 20
> > 10.0.0.0  255.0.0.0 10.109.4.254  
> > 10.109.4.1 21
> > 10.109.4.1  255.255.255.255 On-link10.109.4.1   
> >  276
> > [...]
> > 
> > I need to redirect the traffic to 10.109.4.254 only if it goes to the 
> > remote LAN (10.109.3.0/24), the rest should go via def gw.
> > How can I configure it on the router/server side ?
> > 
> > $ cat /etc/npppd/npppd.conf
> > # $OpenBSD: npppd.conf,v 1.3 2020/01/23 03:01:22 dlg Exp $
> > # sample npppd configuration file.  see npppd.conf(5)
> > 
> > set max-session 200
> > set user-max-session 4
> > 
> > authentication LOCAL type local {
> > users-file "/etc/npppd/npppd-users"
> > }
> > tunnel L2TP protocol l2tp {
> > listen on X.X.X.X
> > }
> > 
> > ipcp IPCP {
> > pool-address 10.109.4.1-10.109.4.32
> > dns-servers 1.1.1.1
> > }
> > 
> > # use pppx(4) interface.  use an interface per a ppp session.
> > interface pppx0 address 10.109.4.254 ipcp IPCP
> > bind tunnel from L2TP authenticated by LOCAL to pppx0
> > 
> > $ cat /etc/npppd/npppd-users
> > rdk:\
> > :password=pasword:\
> > :framed-ip-address=10.109.4.1:
> > #:framed-ip-netmask=255.255.255.0:
> > 
> > $ dmesg | head
> > OpenBSD 6.8 (GENERIC.MP) #4: Mon Jan 11 10:35:56 MST 2021
> > 
> > r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > -- 
> > Radek
> > 
> 
-- 
Radek

Re: npppd - changing clients' route table

[YASUOKA Masahiko]

Hello,

On Sat, 20 Feb 2021 21:14:24 +0100
Radek  wrote:
> I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
> 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes via 
> 10.109.4.254
> 
> client> route print 
> Network Destination   Netmask  Gateway  Interface Metric
>   0.0.0.0  0.0.0.0   192.168.1.1192.168.1.101 
> 20
> 10.0.0.0  255.0.0.0 10.109.4.254  10.109.4.1  
>21
> 10.109.4.1  255.255.255.255 On-link10.109.4.1
> 276
> [...]

The interface which terminate the tunnel has "192.168.4.254".
Right?

> $ cat /etc/npppd/npppd-users
> rdk:\
> :password=pasword:\
> :framed-ip-address=10.109.4.1:
> #:framed-ip-netmask=255.255.255.0:

How about if you configure the npppd-users

rdk:
  :password=pasword:\
  :framed-ip-address=10.109.4.254:\
  :framed-ip-netmask=255.255.255.0:

?

The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
session authenticated by the above "rdk".


On Sat, 20 Feb 2021 21:14:24 +0100
Radek  wrote:
> Hi, 
> I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
> 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes via 
> 10.109.4.254
> 
> client> route print 
> Network Destination   Netmask  Gateway  Interface Metric
>   0.0.0.0  0.0.0.0   192.168.1.1192.168.1.101 
> 20
> 10.0.0.0  255.0.0.0 10.109.4.254  10.109.4.1  
>21
> 10.109.4.1  255.255.255.255 On-link10.109.4.1
> 276
> [...]
> 
> I need to redirect the traffic to 10.109.4.254 only if it goes to the remote 
> LAN (10.109.3.0/24), the rest should go via def gw.
> How can I configure it on the router/server side ?
> 
> $ cat /etc/npppd/npppd.conf
> # $OpenBSD: npppd.conf,v 1.3 2020/01/23 03:01:22 dlg Exp $
> # sample npppd configuration file.  see npppd.conf(5)
> 
> set max-session 200
> set user-max-session 4
> 
> authentication LOCAL type local {
> users-file "/etc/npppd/npppd-users"
> }
> tunnel L2TP protocol l2tp {
> listen on X.X.X.X
> }
> 
> ipcp IPCP {
> pool-address 10.109.4.1-10.109.4.32
> dns-servers 1.1.1.1
> }
> 
> # use pppx(4) interface.  use an interface per a ppp session.
> interface pppx0 address 10.109.4.254 ipcp IPCP
> bind tunnel from L2TP authenticated by LOCAL to pppx0
> 
> $ cat /etc/npppd/npppd-users
> rdk:\
> :password=pasword:\
> :framed-ip-address=10.109.4.1:
> #:framed-ip-netmask=255.255.255.0:
> 
> $ dmesg | head
> OpenBSD 6.8 (GENERIC.MP) #4: Mon Jan 11 10:35:56 MST 2021
> 
> r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> -- 
> Radek
> 

npppd - changing clients' route table

[Radek]

Hi, 
I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes via 
10.109.4.254

client> route print 
Network Destination   Netmask  Gateway  Interface Metric
  0.0.0.0  0.0.0.0   192.168.1.1192.168.1.101   
  20
10.0.0.0  255.0.0.0 10.109.4.254  10.109.4.1
 21
10.109.4.1  255.255.255.255 On-link10.109.4.1276
[...]

I need to redirect the traffic to 10.109.4.254 only if it goes to the remote 
LAN (10.109.3.0/24), the rest should go via def gw.
How can I configure it on the router/server side ?

$ cat /etc/npppd/npppd.conf
# $OpenBSD: npppd.conf,v 1.3 2020/01/23 03:01:22 dlg Exp $
# sample npppd configuration file.  see npppd.conf(5)

set max-session 200
set user-max-session 4

authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel L2TP protocol l2tp {
listen on X.X.X.X
}

ipcp IPCP {
pool-address 10.109.4.1-10.109.4.32
dns-servers 1.1.1.1
}

# use pppx(4) interface.  use an interface per a ppp session.
interface pppx0 address 10.109.4.254 ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to pppx0

$ cat /etc/npppd/npppd-users
rdk:\
:password=pasword:\
:framed-ip-address=10.109.4.1:
#:framed-ip-netmask=255.255.255.0:

$ dmesg | head
OpenBSD 6.8 (GENERIC.MP) #4: Mon Jan 11 10:35:56 MST 2021

r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

-- 
Radek

Re: npppd - problem with simultaneous sessions

[Radek]

Hi,

> When the problem is happening, is the counter "dropped due to missing 
> IPsec protection" incremented?
Yes, it is.

No VPN session:
$ netstat -sp udp
udp:
360413 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
39898 with no checksum
108780 input packets software-checksummed
135430 output packets software-checksummed
187992 dropped due to no socket
50819 broadcast/multicast datagrams dropped due to no socket
970 dropped due to missing IPsec protection
0 dropped due to full socket buffers
121602 delivered
222326 datagrams output
285255 missed PCB cache

First VPN session:
$ netstat -sp udp
udp:
360863 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
40104 with no checksum
108780 input packets software-checksummed
135518 output packets software-checksummed
188056 dropped due to no socket
50885 broadcast/multicast datagrams dropped due to no socket
970 dropped due to missing IPsec protection
0 dropped due to full socket buffers
121922 delivered
222532 datagrams output
285534 missed PCB cache

Second VPN session (the first ses. was disconencted)
[root@@fw-u/home/rdk:]netstat -sp udp
udp:
361306 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
40446 with no checksum
108780 input packets software-checksummed
135660 output packets software-checksummed
188109 dropped due to no socket
50888 broadcast/multicast datagrams dropped due to no socket
977 dropped due to missing IPsec protection
0 dropped due to full socket buffers
122309 delivered
222708 datagrams output
285800 missed PCB cache

and after ~2 minutes:
[root@@fw-u/home/rdk:]netstat -sp udp
udp:
361814 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
40862 with no checksum
108780 input packets software-checksummed
135837 output packets software-checksummed
188150 dropped due to no socket
50900 broadcast/multicast datagrams dropped due to no socket
1005 dropped due to missing IPsec protection
0 dropped due to full socket buffers
122764 delivered
222912 datagrams output
286078 missed PCB cache

On Fri, 08 Jan 2021 18:15:37 +0900 (JST)
YASUOKA Masahiko  wrote:

> Hi,
> 
> >> It seems that only last person can use the tunnel.  This reminds me
> >> problems through NAT.
> > True. Can it be caused by wrong PF rules?
> 
> No, I don't think so.
> 
> I suppose I could repeat the problem.
> 
> When the problem is happening, is the counter "dropped due to missing 
> IPsec protection" incremented?
> 
>% netstat -sp udp
>udp:
>655 datagrams received
>0 with incomplete header
>0 with bad data length field
>0 with bad checksum
>297 with no checksum
>356 input packets software-checksummed
>236 output packets software-checksummed
>46 dropped due to no socket
>0 broadcast/multicast datagrams dropped due to no socket
>3 dropped due to missing IPsec protection
>0 dropped due to full socket buffers
>609 delivered
>236 datagrams output
>354 missed PCB cache
> 
> I started looking into this problem.
> 
> On Thu, 7 Jan 2021 09:45:07 +0100
> radek  wrote:
> > Hi,
> >
> >> It seems that only last person can use the tunnel.  This reminds me
> >> problems through NAT.
> > True. Can it be caused by wrong PF rules?
> >
> >> Both sessions seem to be connected from A.B.C.D.  Are the clients
> >> behind a NAT?
> > Yes, both client are behind the same router/NAT.
> > I have a 66/i386 box running npppd on producion and my two clients 
> > can be connected the same time flawlessly.
> >
> >> How about the npppd side?  Does the client directly connect to
> >>
> >> > tunnel L2TP protocol l2tp {
> >> > listen on X.Y.Z.13
> >> > }
> >>
> >> X.Y.Z.13 ?  Or a NAT is there?
> > It is directly connected do X.Y.Z.13, no NAT.
> >
> > On Thu, 07 Jan 2021 16:27:57 +0900 (JST)
> > YASUOKA Masahiko  wrote:
> >
> >> Hi,
> >>
> >> On Wed, 6 Jan 2021 21:33:49 +0100
> >> Radek  wrote:
> >> > I have a box with relatively fresh install of 6

Re: npppd - problem with simultaneous sessions

[YASUOKA Masahiko]

Hi,


It seems that only last person can use the tunnel.  This reminds me
problems through NAT.

True. Can it be caused by wrong PF rules?


No, I don't think so.

I suppose I could repeat the problem.

When the problem is happening, is the counter "dropped due to missing 
IPsec protection" incremented?


  % netstat -sp udp
  udp:
  655 datagrams received
  0 with incomplete header
  0 with bad data length field
  0 with bad checksum
  297 with no checksum
  356 input packets software-checksummed
  236 output packets software-checksummed
  46 dropped due to no socket
  0 broadcast/multicast datagrams dropped due to no socket
  3 dropped due to missing IPsec protection
  0 dropped due to full socket buffers
  609 delivered
  236 datagrams output
  354 missed PCB cache

I started looking into this problem.

On Thu, 7 Jan 2021 09:45:07 +0100
radek  wrote:

Hi,


It seems that only last person can use the tunnel.  This reminds me
problems through NAT.

True. Can it be caused by wrong PF rules?


Both sessions seem to be connected from A.B.C.D.  Are the clients
behind a NAT?

Yes, both client are behind the same router/NAT.
I have a 66/i386 box running npppd on producion and my two clients 
can be connected the same time flawlessly.



How about the npppd side?  Does the client directly connect to

> tunnel L2TP protocol l2tp {
> listen on X.Y.Z.13
> }

X.Y.Z.13 ?  Or a NAT is there?

It is directly connected do X.Y.Z.13, no NAT.

On Thu, 07 Jan 2021 16:27:57 +0900 (JST)
YASUOKA Masahiko  wrote:


Hi,

On Wed, 6 Jan 2021 21:33:49 +0100
Radek  wrote:
> I have a box with relatively fresh install of 68/amd64, fully
> syspatched. There is a npppd server running on it. The problem is
> that I can have only one nppp session at one time. If the second
> vpn user connects the box, the first nppp session hangs/drops. I
> probably have missed something obvious in my setup but I really
> can't find what it is.

It seems that only last person can use the tunnel.  This reminds me
problems through NAT.

> Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base
> logtype=TUNNELSTART user="rdk" duration=1sec layer2=L2TP
> layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.1 
iface=pppx0


> Jan  6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=base
> logtype=TUNNELSTART user="rdk-test" duration=1sec layer2=L2TP
> layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.11 
iface=pppx0


Both sessions seem to be connected from A.B.C.D.  Are the clients
behind a NAT?

How about the npppd side?  Does the client directly connect to

> tunnel L2TP protocol l2tp {
> listen on X.Y.Z.13
> }

X.Y.Z.13 ?  Or a NAT is there?

On Wed, 6 Jan 2021 21:33:49 +0100
Radek  wrote:
> Hi @misc,
>
> I have a box with relatively fresh install of 68/amd64, fully
> syspatched. There is a npppd server running on it. The problem is
> that I can have only one nppp session at one time. If the second
> vpn user connects the box, the first nppp session hangs/drops. I
> probably have missed something obvious in my setup but I really
> can't find what it is.
>
> Please help me to solve the problem.
> Thank you.
>
> $cat /etc/npppd/npppd.conf
> authentication LOCAL type local {
> users-file "/etc/npppd/npppd-users"
> }
> tunnel L2TP protocol l2tp {
> listen on X.Y.Z.13
> }
> ipcp IPCP {
> pool-address 10.109.4.1-10.109.4.32
> dns-servers 1.1.1.1
> }
> # use pppx(4) interface.  use an interface per a ppp session.
> interface pppx0 address 10.109.4.254 ipcp IPCP
> bind tunnel from L2TP authenticated by LOCAL to pppx0
>
> $cat /etc/hostname.enc0
> up
>
>
> $cat /etc/sysctl.conf
> net.inet.ip.forwarding=1
> net.inet.ipcomp.enable=1
> net.inet.esp.enable=1
> net.inet.gre.allow=1
> net.pipex.enable=1
>
> $cat /etc/rc.conf.local
> ipsec=YES
> ipsec_rules=/etc/ipsec.conf
> isakmpd_flags="-K"
> npppd_flags=""
>
> $cat /etc/ipsec.conf
> wan_ipv4 = X.Y.Z.13
> ike passive esp transport \
>  proto udp from $wan_ipv4 to any port 1701 \
>  main auth "hmac-sha1" enc "3des" group modp1024 \
>  quick auth "hmac-sha1" enc "aes" group modp1024 \
>  psk "pskpskpsk"
>
> $cat /etc/pf.conf
> [...]
> vpn_if = "pppx"
> vpn_local  = "10.109.4.0/24"
>
> pass in on $ext_if proto udp from any to (egress:0) port
> {isakmp,ipsec-nat-t,l2tp}
> pass in on $ext_if proto {ah,esp}
> pass log proto { gre } from any to any keep state
>
> # filter all IPSec traffic on the enc interface
> pass on enc0 keep state (if-bound)
>
> # allow all trafic in on and o

Re: npppd - problem with simultaneous sessions

[radek]

Hi, 

> It seems that only last person can use the tunnel.  This reminds me 
> problems through NAT.
True. Can it be caused by wrong PF rules?

> Both sessions seem to be connected from A.B.C.D.  Are the clients 
> behind a NAT?
Yes, both client are behind the same router/NAT.
I have a 66/i386 box running npppd on producion and my two clients can be 
connected the same time flawlessly.

> How about the npppd side?  Does the client directly connect to
> 
> > tunnel L2TP protocol l2tp {
> > listen on X.Y.Z.13
> > }
> 
> X.Y.Z.13 ?  Or a NAT is there?
It is directly connected do X.Y.Z.13, no NAT.

On Thu, 07 Jan 2021 16:27:57 +0900 (JST)
YASUOKA Masahiko  wrote:

> Hi,
> 
> On Wed, 6 Jan 2021 21:33:49 +0100
> Radek  wrote:
> > I have a box with relatively fresh install of 68/amd64, fully 
> > syspatched. There is a npppd server running on it. The problem is 
> > that I can have only one nppp session at one time. If the second 
> > vpn user connects the box, the first nppp session hangs/drops. I 
> > probably have missed something obvious in my setup but I really 
> > can't find what it is.
> 
> It seems that only last person can use the tunnel.  This reminds me 
> problems through NAT.
> 
> > Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base 
> > logtype=TUNNELSTART user="rdk" duration=1sec layer2=L2TP 
> > layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.1 iface=pppx0
> 
> > Jan  6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=base 
> > logtype=TUNNELSTART user="rdk-test" duration=1sec layer2=L2TP 
> > layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.11 iface=pppx0
> 
> Both sessions seem to be connected from A.B.C.D.  Are the clients 
> behind a NAT?
> 
> How about the npppd side?  Does the client directly connect to
> 
> > tunnel L2TP protocol l2tp {
> > listen on X.Y.Z.13
> > }
> 
> X.Y.Z.13 ?  Or a NAT is there?
> 
> On Wed, 6 Jan 2021 21:33:49 +0100
> Radek  wrote:
> > Hi @misc,
> >
> > I have a box with relatively fresh install of 68/amd64, fully 
> > syspatched. There is a npppd server running on it. The problem is 
> > that I can have only one nppp session at one time. If the second 
> > vpn user connects the box, the first nppp session hangs/drops. I 
> > probably have missed something obvious in my setup but I really 
> > can't find what it is.
> >
> > Please help me to solve the problem.
> > Thank you.
> >
> > $cat /etc/npppd/npppd.conf
> > authentication LOCAL type local {
> > users-file "/etc/npppd/npppd-users"
> > }
> > tunnel L2TP protocol l2tp {
> > listen on X.Y.Z.13
> > }
> > ipcp IPCP {
> > pool-address 10.109.4.1-10.109.4.32
> > dns-servers 1.1.1.1
> > }
> > # use pppx(4) interface.  use an interface per a ppp session.
> > interface pppx0 address 10.109.4.254 ipcp IPCP
> > bind tunnel from L2TP authenticated by LOCAL to pppx0
> >
> > $cat /etc/hostname.enc0
> > up
> >
> >
> > $cat /etc/sysctl.conf
> > net.inet.ip.forwarding=1
> > net.inet.ipcomp.enable=1
> > net.inet.esp.enable=1
> > net.inet.gre.allow=1
> > net.pipex.enable=1
> >
> > $cat /etc/rc.conf.local
> > ipsec=YES
> > ipsec_rules=/etc/ipsec.conf
> > isakmpd_flags="-K"
> > npppd_flags=""
> >
> > $cat /etc/ipsec.conf
> > wan_ipv4 = X.Y.Z.13
> > ike passive esp transport \
> >  proto udp from $wan_ipv4 to any port 1701 \
> >  main auth "hmac-sha1" enc "3des" group modp1024 \
> >  quick auth "hmac-sha1" enc "aes" group modp1024 \
> >  psk "pskpskpsk"
> >
> > $cat /etc/pf.conf
> > [...]
> > vpn_if = "pppx"
> > vpn_local  = "10.109.4.0/24"
> >
> > pass in on $ext_if proto udp from any to (egress:0) port 
> > {isakmp,ipsec-nat-t,l2tp}
> > pass in on $ext_if proto {ah,esp}
> > pass log proto { gre } from any to any keep state
> >
> > # filter all IPSec traffic on the enc interface
> > pass on enc0 keep state (if-bound)
> >
> > # allow all trafic in on and out to the VPN network
> > pass on $vpn_if from $vpn_local
> > pass on $vpn_if to $vpn_local
> >
> > # NAT VPN traffic going out on the public interface with the public 
> > IP
> > match out log on $ext_if inet proto { tcp, udp, icmp } from 
> > $vpn_local nat-to ($ext_if) set prio (3,7)
> >
> > some logs...
> >
> > Jan  6 20:53:14 fw-u last message repeated 4 t

Re: npppd - problem with simultaneous sessions

[YASUOKA Masahiko]

Hi,

On Wed, 6 Jan 2021 21:33:49 +0100
Radek  wrote:
I have a box with relatively fresh install of 68/amd64, fully 
syspatched. There is a npppd server running on it. The problem is 
that I can have only one nppp session at one time. If the second 
vpn user connects the box, the first nppp session hangs/drops. I 
probably have missed something obvious in my setup but I really 
can't find what it is.


It seems that only last person can use the tunnel.  This reminds me 
problems through NAT.


Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base 
logtype=TUNNELSTART user="rdk" duration=1sec layer2=L2TP 
layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.1 iface=pppx0


Jan  6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=base 
logtype=TUNNELSTART user="rdk-test" duration=1sec layer2=L2TP 
layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.11 iface=pppx0


Both sessions seem to be connected from A.B.C.D.  Are the clients 
behind a NAT?


How about the npppd side?  Does the client directly connect to


tunnel L2TP protocol l2tp {
listen on X.Y.Z.13
}


X.Y.Z.13 ?  Or a NAT is there?

On Wed, 6 Jan 2021 21:33:49 +0100
Radek  wrote:

Hi @misc,

I have a box with relatively fresh install of 68/amd64, fully 
syspatched. There is a npppd server running on it. The problem is 
that I can have only one nppp session at one time. If the second 
vpn user connects the box, the first nppp session hangs/drops. I 
probably have missed something obvious in my setup but I really 
can't find what it is.


Please help me to solve the problem.
Thank you.

$cat /etc/npppd/npppd.conf
authentication LOCAL type local {
    users-file "/etc/npppd/npppd-users"
}
tunnel L2TP protocol l2tp {
listen on X.Y.Z.13
}
ipcp IPCP {
pool-address 10.109.4.1-10.109.4.32
dns-servers 1.1.1.1
}
# use pppx(4) interface.  use an interface per a ppp session.
interface pppx0 address 10.109.4.254 ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to pppx0

$cat /etc/hostname.enc0
up


$cat /etc/sysctl.conf
net.inet.ip.forwarding=1
net.inet.ipcomp.enable=1
net.inet.esp.enable=1
net.inet.gre.allow=1
net.pipex.enable=1

$cat /etc/rc.conf.local
ipsec=YES
ipsec_rules=/etc/ipsec.conf
isakmpd_flags="-K"
npppd_flags=""

$cat /etc/ipsec.conf
wan_ipv4 = X.Y.Z.13
ike passive esp transport \
 proto udp from $wan_ipv4 to any port 1701 \
 main auth "hmac-sha1" enc "3des" group modp1024 \
 quick auth "hmac-sha1" enc "aes" group modp1024 \
 psk "pskpskpsk"

$cat /etc/pf.conf
[...]
vpn_if = "pppx"
vpn_local  = "10.109.4.0/24"

pass in on $ext_if proto udp from any to (egress:0) port 
{isakmp,ipsec-nat-t,l2tp}

pass in on $ext_if proto {ah,esp}
pass log proto { gre } from any to any keep state

# filter all IPSec traffic on the enc interface
pass on enc0 keep state (if-bound)

# allow all trafic in on and out to the VPN network
pass on $vpn_if from $vpn_local
pass on $vpn_if to $vpn_local

# NAT VPN traffic going out on the public interface with the public 
IP
match out log on $ext_if inet proto { tcp, udp, icmp } from 
$vpn_local nat-to ($ext_if) set prio (3,7)


some logs...

Jan  6 20:53:14 fw-u last message repeated 4 times
Jan  6 20:53:16 fw-u isakmpd[11638]: attribute_unacceptable: 
ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC

Jan  6 20:53:16 fw-u last message repeated 2 times
Jan  6 20:53:16 fw-u isakmpd[11638]: attribute_unacceptable: 
GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 logtype=Started 
RecvSCCRQ from=A.B.C.D:1701/udp tunnel_id=1/26 protocol=1.0 
winsize=8 hostname=w520 vendor=Microsoft firm=0601

Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 SendSCCRP
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 RecvSCCN
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 SendZLB
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 RecvZLB
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 RecvICRQ 
session_id=1
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 SendICRP 
session_id=6499
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 RecvICCN 
session_id=1 calling_number= tx_conn_speed=1 framing=sync
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 
logtype=PPPBind ppp=0
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base 
logtype=Started tunnel=L2TP(A.B.C.D:1701)

Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 SendZLB
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp 
logtype=Opened mru=1360/1400 auth=MS-CHAP-V2 magic=e916be4d/3c630a24
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp RecvId 
magic=3c630a24 text=MSRASV5.20
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp RecvId 
magic=3c630a24 text=MSRAS-0-W520
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp RecvId 
magic=3c630a24 text=.=. .`.M
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=chap 
proto=mschap_

npppd - problem with simultaneous sessions

[Radek]

Hi @misc,

I have a box with relatively fresh install of 68/amd64, fully syspatched. There 
is a npppd server running on it. The problem is that I can have only one nppp 
session at one time. If the second vpn user connects the box, the first nppp 
session hangs/drops. I probably have missed something obvious in my setup but I 
really can't find what it is.

Please help me to solve the problem. 
Thank you.

$cat /etc/npppd/npppd.conf
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel L2TP protocol l2tp {
listen on X.Y.Z.13
}
ipcp IPCP {
pool-address 10.109.4.1-10.109.4.32
dns-servers 1.1.1.1
}
# use pppx(4) interface.  use an interface per a ppp session.
interface pppx0 address 10.109.4.254 ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to pppx0
 
$cat /etc/hostname.enc0
up


$cat /etc/sysctl.conf
net.inet.ip.forwarding=1
net.inet.ipcomp.enable=1
net.inet.esp.enable=1
net.inet.gre.allow=1
net.pipex.enable=1

$cat /etc/rc.conf.local
ipsec=YES
ipsec_rules=/etc/ipsec.conf
isakmpd_flags="-K"
npppd_flags=""

$cat /etc/ipsec.conf
wan_ipv4 = X.Y.Z.13
ike passive esp transport \
 proto udp from $wan_ipv4 to any port 1701 \
 main auth "hmac-sha1" enc "3des" group modp1024 \
 quick auth "hmac-sha1" enc "aes" group modp1024 \
 psk "pskpskpsk"

$cat /etc/pf.conf
[...]
vpn_if = "pppx"
vpn_local  = "10.109.4.0/24"

pass in on $ext_if proto udp from any to (egress:0) port 
{isakmp,ipsec-nat-t,l2tp}
pass in on $ext_if proto {ah,esp}
pass log proto { gre } from any to any keep state

# filter all IPSec traffic on the enc interface
pass on enc0 keep state (if-bound)

# allow all trafic in on and out to the VPN network
pass on $vpn_if from $vpn_local
pass on $vpn_if to $vpn_local

# NAT VPN traffic going out on the public interface with the public IP
match out log on $ext_if inet proto { tcp, udp, icmp } from $vpn_local nat-to 
($ext_if) set prio (3,7)

some logs...

Jan  6 20:53:14 fw-u last message repeated 4 times
Jan  6 20:53:16 fw-u isakmpd[11638]: attribute_unacceptable: 
ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
Jan  6 20:53:16 fw-u last message repeated 2 times
Jan  6 20:53:16 fw-u isakmpd[11638]: attribute_unacceptable: GROUP_DESCRIPTION: 
got MODP_2048, expected MODP_1024
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 logtype=Started RecvSCCRQ 
from=A.B.C.D:1701/udp tunnel_id=1/26 protocol=1.0 winsize=8 hostname=w520 
vendor=Microsoft firm=0601
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 SendSCCRP
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 RecvSCCN
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 SendZLB
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 RecvZLB
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 RecvICRQ session_id=1
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 SendICRP 
session_id=6499
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 RecvICCN session_id=1 
calling_number= tx_conn_speed=1 framing=sync
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 logtype=PPPBind ppp=0
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base logtype=Started 
tunnel=L2TP(A.B.C.D:1701)
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 SendZLB
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp logtype=Opened 
mru=1360/1400 auth=MS-CHAP-V2 magic=e916be4d/3c630a24
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp RecvId magic=3c630a24 
text=MSRASV5.20
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp RecvId magic=3c630a24 
text=MSRAS-0-W520
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp RecvId magic=3c630a24 
text=.=. .`.M
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=chap proto=mschap_v2 
logtype=Success username="rdk" realm=LOCAL
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=mppe mismatch 
our=40bit,128bit,56bit,stateless peer=stateless
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=ipcp IP Address peer=0.0.0.0 
our=10.109.4.1.
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=ipcp logtype=Opened 
ip=10.109.4.1 assignType=dynamic
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base logtype=TUNNELSTART 
user="rdk" duration=1sec layer2=L2TP layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  
ip=10.109.4.1 iface=pppx0
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=mppe logtype=Opened 
our=128bit,stateless peer=128bit,stateless
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base Using pipex=yes
Jan  6 20:53:43 fw-u isakmpd[11638]: attribute_unacceptable: 
ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
Jan  6 20:53:43 fw-u last message repeated 2 times
Jan  6 20:53:43 fw-u isakmpd[11638]: attribute_unacceptable: GROUP_DESCRIPTION: 
got MODP_2048, expected MODP_1024
Jan  6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 logtype=Started RecvSCCRQ 
from=A.B.C.D:1701/udp tunnel_id=2/20 protocol=1.0 winsize=8 hostname=x 
vendor=Micro

Re: npppd failed enable pipex: Invalid argument

[Marko Cupać]

On Mon, 17 Aug 2020 00:36:35 +0300
Vitaliy Makkoveev  wrote:

> Hello Marko.
> 
> Can I propose you to try upcoming 6.8? We moved pppac(4) and pppx(4)
> output processing out of kernel lock. pppx(4) output is still
> serialised by netlock, but I hope we'll made it per-cpu before 6.8
> release.
> 
> Also, for curiosity reasons, what is your pppx(4) clients count? 

Hi Vitaliy,

I can try 6.8 snapshot and test 2-3 simultaneous clients, but
unfortunately not in "real life" production.

In April, during WFH boom in early days of lockdown I had up to 150
concurrent clients, nowadays they average around 50. But not too much
traffic, ~20Mbit/s in total (people mostly RDP over pptp).

I'll report how I fare with 6.8 snapshots.

Regards,

-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: npppd failed enable pipex: Invalid argument

[Vitaliy Makkoveev]

> On 10 Aug 2020, at 14:00, Marko Cupać  wrote:
> 
>>> On 4 Aug 2020, at 17:04, Marko Cupać  wrote:
>>> 
>>> Hi,
>>> 
>>> I have recently upgraded (actually installed from scratch and copied
>>> config files) one of my firewalls from 6.6 to 6.7, and (sys)patched
>>> it to 017_dix. Everything works great except my npppd setup. It
>>> starts fine, but upon connecting over pptp I get the following
>>> records in log:
>>> (...)
>>> Aug  4 15:48:48 nat2 npppd[66557]: ppp id=0 layer=base failed
>>> enable pipex: Invalid argument
>> 
>> On Tue, 4 Aug 2020 18:31:44 +0300
>> Vitaliy Makkoveev  wrote:
>> 
>> In kernel timeout was disabled for pppx(4). Remove please
>> "idle-timeout”.
> 
> Sorry for late reply, I haven't had the chance to test until now. That
> was it, after removing idle-timeout, npppd accepts pptp connections.
> 
> Once again you saved me with npppd, thank you!

Hello Marko.

Can I propose you to try upcoming 6.8? We moved pppac(4) and pppx(4)
output processing out of kernel lock. pppx(4) output is still serialised
by netlock, but I hope we'll made it per-cpu before 6.8 release.

Also, for curiosity reasons, what is your pppx(4) clients count? 

Re: npppd failed enable pipex: Invalid argument

[Marko Cupać]

> > On 4 Aug 2020, at 17:04, Marko Cupać  wrote:
> > 
> > Hi,
> > 
> > I have recently upgraded (actually installed from scratch and copied
> > config files) one of my firewalls from 6.6 to 6.7, and (sys)patched
> > it to 017_dix. Everything works great except my npppd setup. It
> > starts fine, but upon connecting over pptp I get the following
> > records in log:
> > (...)
> > Aug  4 15:48:48 nat2 npppd[66557]: ppp id=0 layer=base failed
> > enable pipex: Invalid argument
>
> On Tue, 4 Aug 2020 18:31:44 +0300
> Vitaliy Makkoveev  wrote:
>
> In kernel timeout was disabled for pppx(4). Remove please
> "idle-timeout”.

Sorry for late reply, I haven't had the chance to test until now. That
was it, after removing idle-timeout, npppd accepts pptp connections.

Once again you saved me with npppd, thank you!
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

npppd failed enable pipex: Invalid argument

[Marko Cupać]

Hi,

I have recently upgraded (actually installed from scratch and copied
config files) one of my firewalls from 6.6 to 6.7, and (sys)patched it
to 017_dix. Everything works great except my npppd setup. It starts
fine, but upon connecting over pptp I get the following records in log:

Aug  4 15:48:48 nat2 npppd[66557]: pptpd ctrl=0 call=28381 logtype=PPPBind ppp=0
Aug  4 15:48:48 nat2 npppd[66557]: ppp id=0 layer=base logtype=TUNNELSTART 
user="someuser" duration=0sec layer2=SOMECOMPANY layer2from=PU.BL.IC.IP:58242 
auth=MS-CHAP-V2  ip=TU.NN.EL.IP iface=pppx0
Aug  4 15:48:48 nat2 npppd[66557]: ppp id=0 layer=base failed enable pipex: 
Invalid argument
Aug  4 15:48:48 nat2 npppd[66557]: pptpd ctrl=0 call=28381 logtype=PPPUnbind
Aug  4 15:48:48 nat2 npppd[66557]: ppp id=0 layer=base logtype=TUNNELUSAGE 
user="someuser" duration=0sec layer2=SOMECOMPANY layer2from=PU.BL.IC.IP:58242 
auth=MS-CHAP-V2 data_in=290bytes,11packets data_out=239bytes,10packets 
error_in=0 error_out=0 mppe=yes mppe_in=128bits,stateless 
mppe_out=128bits,stateless iface=pppx0
Aug  4 15:48:48 nat2 npppd[66557]: pptpd ctrl=0 call=28381 logtype=Terminated
Aug  4 15:48:48 nat2 npppd[66557]: pptpd ctrl=0 logtype=Finished

pipex is enabled in sysctl.conf:

me@myfw:~ $ sysctl net.pipex.enable
net.pipex.enable=1

Identical npppd.conf works flawlessly on another CARP member which is
still at 6.6:

# GLOBAL
set max-session 200
set user-max-session 1

# TUNNEL
tunnel SOMECOMPANY protocol pptp {
listen on PU.BL.IC.IP
pptp-hostname somehost.example.org
pptp-vendor-name "openbsd-npppd"
ingress-filter yes
mppe required
mppe-key-length 128
mppe-key-state stateless
idle-timeout 1800
}

# IPCP
ipcp SOMECOMPANY {
pool-address "PR.IVA.TE.0/24"
dns-servers SO.ME.IP.ADD
allow-user-selected-address no
}

# INTERFACE
interface pppx0 address PR.IVA.TE.1 ipcp SOMECOMPANY

# AUTHENTICATION
authentication RADIUS type radius {
strip-nt-domain yes
strip-atmark-realm yes
authentication-server {
address SO.ME.IP.ADD secret "somepass"
}
accounting-server {
address SO.ME.IP.ADD secret "somepass"
}
}

bind tunnel from SOMECOMPANY authenticated by RADIUS to pppx0

Here's dmesg:

OpenBSD 6.7 (GENERIC.MP) #5: Tue Jul 21 13:50:07 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17027289088 (16238MB)
avail mem = 16498622464 (15734MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x788cf000 (234 entries)
bios0: vendor HP version "P89" date 10/21/2019
bios0: HP ProLiant DL360 Gen9
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP UEFI MCEJ SSDT HEST BERT ERST EINJ BGRT HPET PMCT WDDT 
APIC MCFG SLIT SRAT SPMI RASF SPCR MSCT BDAT PCCT DMAR SSDT SSDT SSDT
acpi0: wakeup devices PEX4(S4) BR05(S4) BR03(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.31 MHz, 06-4f-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.00 MHz, 06-4f-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.00 MHz, 06-4f-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE

Re: npppd failed enable pipex: Invalid argument

[Vitaliy Makkoveev]

> On 4 Aug 2020, at 17:04, Marko Cupać  wrote:
> 
> Hi,
> 
> I have recently upgraded (actually installed from scratch and copied
> config files) one of my firewalls from 6.6 to 6.7, and (sys)patched it
> to 017_dix. Everything works great except my npppd setup. It starts
> fine, but upon connecting over pptp I get the following records in log:
> 
> Aug  4 15:48:48 nat2 npppd[66557]: pptpd ctrl=0 call=28381 logtype=PPPBind 
> ppp=0
> Aug  4 15:48:48 nat2 npppd[66557]: ppp id=0 layer=base logtype=TUNNELSTART 
> user="someuser" duration=0sec layer2=SOMECOMPANY layer2from=PU.BL.IC.IP:58242 
> auth=MS-CHAP-V2  ip=TU.NN.EL.IP iface=pppx0
> Aug  4 15:48:48 nat2 npppd[66557]: ppp id=0 layer=base failed enable pipex: 
> Invalid argument
> Aug  4 15:48:48 nat2 npppd[66557]: pptpd ctrl=0 call=28381 logtype=PPPUnbind
> Aug  4 15:48:48 nat2 npppd[66557]: ppp id=0 layer=base logtype=TUNNELUSAGE 
> user="someuser" duration=0sec layer2=SOMECOMPANY layer2from=PU.BL.IC.IP:58242 
> auth=MS-CHAP-V2 data_in=290bytes,11packets data_out=239bytes,10packets 
> error_in=0 error_out=0 mppe=yes mppe_in=128bits,stateless 
> mppe_out=128bits,stateless iface=pppx0
> Aug  4 15:48:48 nat2 npppd[66557]: pptpd ctrl=0 call=28381 logtype=Terminated
> Aug  4 15:48:48 nat2 npppd[66557]: pptpd ctrl=0 logtype=Finished
> 
> pipex is enabled in sysctl.conf:
> 
> me@myfw:~ $ sysctl net.pipex.enable
> net.pipex.enable=1
> 
> Identical npppd.conf works flawlessly on another CARP member which is
> still at 6.6:
> 
> # GLOBAL
> set max-session 200
> set user-max-session 1
> 
> # TUNNEL
> tunnel SOMECOMPANY protocol pptp {
>listen on PU.BL.IC.IP
>pptp-hostname somehost.example.org
>pptp-vendor-name "openbsd-npppd"
>   ingress-filter yes
>mppe required
>mppe-key-length 128
>mppe-key-state stateless
>idle-timeout 1800

In kernel timeout was disabled for pppx(4). Remove please "idle-timeout”.

> }
> 
> # IPCP
> ipcp SOMECOMPANY {
>pool-address "PR.IVA.TE.0/24"
>dns-servers SO.ME.IP.ADD
>allow-user-selected-address no
> }
> 
> # INTERFACE
> interface pppx0 address PR.IVA.TE.1 ipcp SOMECOMPANY
> 
> # AUTHENTICATION
> authentication RADIUS type radius {
>strip-nt-domain yes
>strip-atmark-realm yes
>authentication-server {
>address SO.ME.IP.ADD secret "somepass"
>}
>accounting-server {
>address SO.ME.IP.ADD secret "somepass"
>}
> }
> 
> bind tunnel from SOMECOMPANY authenticated by RADIUS to pppx0
> 
> Here's dmesg:
> 
> OpenBSD 6.7 (GENERIC.MP) #5: Tue Jul 21 13:50:07 MDT 2020
>
> r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17027289088 (16238MB)
> avail mem = 16498622464 (15734MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x788cf000 (234 entries)
> bios0: vendor HP version "P89" date 10/21/2019
> bios0: HP ProLiant DL360 Gen9
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S5
> acpi0: tables DSDT FACP UEFI MCEJ SSDT HEST BERT ERST EINJ BGRT HPET PMCT 
> WDDT APIC MCFG SLIT SRAT SPMI RASF SPCR MSCT BDAT PCCT DMAR SSDT SSDT SSDT
> acpi0: wakeup devices PEX4(S4) BR05(S4) BR03(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.31 MHz, 06-4f-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.00 MHz, 06-4f-01
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT

npppd docs for tun change to pppac

[Kaya Saman]

Hi,


I just updated my system from 6.6 (old current) to 6.7 (current) which 
went through fine.


I realized that the npppd setup I had stopped working. Something that 
threw me off in the man pages was the lingering reference to the old tun 
interface which has since been reworked to pppac.



man npppd:

SEE ALSO
 gre(4), pipex(4), pppx(4), tun(4), npppd.conf(5), npppctl(8), 
sysctl(8)



Of course the actual code has been changed based on the mail threads here:

openbsd-archive.7691.n7.nabble.com/move-PIPEX-from-tun-4-into-pppac-4-a-dedicated-PPP-access-concentrator-td382139.html

https://bsdsec.net/articles/openbsd-6-7-released-may-19-2020


I guess the tun(4) reference needs to be removed? Currently the pppac 
manual command is an alias to pppx(4) so I'm not entirely sure if 
pppac(4) needs to be added in place of tun(4) or a dedicated manual page 
specifically for pppac needs to be written (as it would kind of 
duplicate the existing pppx(4)), or just a simple removal of tun as it 
has been already done with npppd.conf(5)??



Regards,


Kaya

Re: npppd pptp hangs

[Vitaliy Makkoveev]

On Sat, Apr 04, 2020 at 08:22:27PM +0200, Marko Cupać wrote:
> On 2020-03-31 10:07, Marko Cupać wrote:
> > On Mon, 30 Mar 2020 14:33:46 +0300
> > Vitaliy Makkoveev  wrote:
> > 
> > > On Mon, Mar 30, 2020 at 02:28:08PM +0300, Vitaliy Makkoveev wrote:
> > > > You have pipex(4) disabled. Is it still hangs with disabled
> > > > pipex(4)? As I discovered
> > > > (https://marc.info/?t=15852997681=1=2), npppd with pipex(4)
> > > > enabled and non-NULL "idle-timeout" option will crash kernel. You
> > > > can disable this option in yout npppd.conf an reenable pipex(4).
> > > > Looks like crashes should gone.
> > > And don't use pppac(4) with pipex enabled, use pppx(4). Crash you
> > > reported https://marc.info/?t=15850622592=1=2 is actual for
> > > pppac(4).
> > > 
> > 
> > Thanks for the instruction.
> > 
> > I have:
> >  - left net.pipex.enable=1
> >  - replaced tun1 with pppx0 in npppd.conf
> >  - removed 'pipex no' from npppd.conf
> > 
> > So far so good, I'll send update if I experience further hangs.
> 
> No crash since changing interface from tun to pppx.
> 
> Thanx!
Ok :)
> 
> -- 
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
> 
> Marko Cupać
> https://www.mimar.rs/
> 

Re: npppd pptp hangs

[Marko Cupać]

On 2020-03-31 10:07, Marko Cupać wrote:

On Mon, 30 Mar 2020 14:33:46 +0300
Vitaliy Makkoveev  wrote:


On Mon, Mar 30, 2020 at 02:28:08PM +0300, Vitaliy Makkoveev wrote:
> You have pipex(4) disabled. Is it still hangs with disabled
> pipex(4)? As I discovered
> (https://marc.info/?t=158529976800001=1=2), npppd with pipex(4)
> enabled and non-NULL "idle-timeout" option will crash kernel. You
> can disable this option in yout npppd.conf an reenable pipex(4).
> Looks like crashes should gone.
And don't use pppac(4) with pipex enabled, use pppx(4). Crash you
reported https://marc.info/?t=15850622592=1=2 is actual for
pppac(4).



Thanks for the instruction.

I have:
 - left net.pipex.enable=1
 - replaced tun1 with pppx0 in npppd.conf
 - removed 'pipex no' from npppd.conf

So far so good, I'll send update if I experience further hangs.


No crash since changing interface from tun to pppx.

Thanx!

--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: npppd pptp hangs

[Marko Cupać]

On Mon, 30 Mar 2020 14:33:46 +0300
Vitaliy Makkoveev  wrote:

> On Mon, Mar 30, 2020 at 02:28:08PM +0300, Vitaliy Makkoveev wrote:
> > You have pipex(4) disabled. Is it still hangs with disabled
> > pipex(4)? As I discovered
> > (https://marc.info/?t=15852997681=1=2), npppd with pipex(4)
> > enabled and non-NULL "idle-timeout" option will crash kernel. You
> > can disable this option in yout npppd.conf an reenable pipex(4).
> > Looks like crashes should gone.
> And don't use pppac(4) with pipex enabled, use pppx(4). Crash you
> reported https://marc.info/?t=15850622592=1=2 is actual for
> pppac(4).
> 

Thanks for the instruction.

I have:
 - left net.pipex.enable=1
 - replaced tun1 with pppx0 in npppd.conf
 - removed 'pipex no' from npppd.conf

So far so good, I'll send update if I experience further hangs.

The instruction on pppx(4) you gave me came as surprising news to me. I
have been using npppd since it still had undocumented 'old style'
config. Once npppd.conf got its manpage (was it 5.3?) I've set up tun1
as PPTP interface and it worked great with up to ~20 clients all these
years. I was very satisfied that all PPTP traffic went through single
interface (as opposed to my previous setup with poptop which created
separate tun interface for each session), as I had the ability to graph
its traffic from SNMP data.

I guess I was 'holding it wrong' all this time, and yet it worked well
:)

Thank you once again.

-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: npppd pptp hangs

[Vitaliy Makkoveev]

On Mon, Mar 30, 2020 at 02:28:08PM +0300, Vitaliy Makkoveev wrote:
> You have pipex(4) disabled. Is it still hangs with disabled pipex(4)?
> As I discovered (https://marc.info/?t=15852997681=1=2), npppd
> with pipex(4) enabled and non-NULL "idle-timeout" option will crash
> kernel. You can disable this option in yout npppd.conf an reenable
> pipex(4). Looks like crashes should gone.
And don't use pppac(4) with pipex enabled, use pppx(4). Crash you
reported https://marc.info/?t=15850622592=1=2 is actual for
pppac(4).

Re: npppd pptp hangs

[Vitaliy Makkoveev]

On Mon, Mar 30, 2020 at 12:47:13PM +0200, Marko Cupać wrote:
> On Sat, 28 Mar 2020 01:46:41 +0300
> Vitaliy Makkoveev  wrote:
> 
> > Can you try latest snapshot?
> 
> Unfortunately, the box that runs npppd is the most important machine on
> my network (GRE/IPsec hub for multiple branch offices), I can't take the
> risk.
> 
> > Can you share your npppd.conf?
> 
> Below, I have redacted sensitive information. Perhaps it is worth
> mentioning that npppd listens on IP address of CARP interface.
> 
> ---npppd.conf.start---
> # GLOBAL
> set max-session 200
> set user-max-session 1
> 
> # TUNNEL
> tunnel EXAMPLEORG protocol pptp {
> listen on IP.ADD.RE.SS
> pptp-hostname vpn.example.org
> pptp-vendor-name "openbsd-npppd"
>   ingress-filter yes
>   pipex no
> mppe required
> mppe-key-length 128
> mppe-key-state stateless
> idle-timeout 1800
> }
> 
> # IPCP
> ipcp KAPPASTAR {
> pool-address "IP.ADD.RE.SS/24"
> dns-servers IP.ADD.RE.SS
> allow-user-selected-address no
> }
> 
> # INTERFACE
> interface tun1 address IP.ADD.RE.SS ipcp EXAMPLEORG
> 
> # AUTHENTICATION
> authentication RADIUS type radius {
> strip-nt-domain yes
> strip-atmark-realm yes
> authentication-server {
> address IP.ADD.RE.SS secret "ThisIsNotRealPassword"
> }
> accounting-server {
> address IP.ADD.RE.SS secret "ThisIsNotRealPassword"
> }
> }
> 
> bind tunnel from EXAMPLEORG authenticated by RADIUS to tun1
> ---npppd.conf.end---
> 
> Thank you in advance for looking into it.
> -- 
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
> 
> Marko Cupać
> https://www.mimar.rs/
>

You have pipex(4) disabled. Is it still hangs with disabled pipex(4)?
As I discovered (https://marc.info/?t=15852997681=1=2), npppd
with pipex(4) enabled and non-NULL "idle-timeout" option will crash
kernel. You can disable this option in yout npppd.conf an reenable
pipex(4). Looks like crashes should gone.

Re: npppd pptp hangs

[Marko Cupać]

On Sat, 28 Mar 2020 01:46:41 +0300
Vitaliy Makkoveev  wrote:

> Can you try latest snapshot?

Unfortunately, the box that runs npppd is the most important machine on
my network (GRE/IPsec hub for multiple branch offices), I can't take the
risk.

> Can you share your npppd.conf?

Below, I have redacted sensitive information. Perhaps it is worth
mentioning that npppd listens on IP address of CARP interface.

---npppd.conf.start---
# GLOBAL
set max-session 200
set user-max-session 1

# TUNNEL
tunnel EXAMPLEORG protocol pptp {
listen on IP.ADD.RE.SS
pptp-hostname vpn.example.org
pptp-vendor-name "openbsd-npppd"
ingress-filter yes
pipex no
mppe required
mppe-key-length 128
mppe-key-state stateless
idle-timeout 1800
}

# IPCP
ipcp KAPPASTAR {
pool-address "IP.ADD.RE.SS/24"
dns-servers IP.ADD.RE.SS
allow-user-selected-address no
}

# INTERFACE
interface tun1 address IP.ADD.RE.SS ipcp EXAMPLEORG

# AUTHENTICATION
authentication RADIUS type radius {
strip-nt-domain yes
strip-atmark-realm yes
authentication-server {
address IP.ADD.RE.SS secret "ThisIsNotRealPassword"
}
accounting-server {
address IP.ADD.RE.SS secret "ThisIsNotRealPassword"
}
}

bind tunnel from EXAMPLEORG authenticated by RADIUS to tun1
---npppd.conf.end---

Thank you in advance for looking into it.
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: npppd pptp hangs

[Vitaliy Makkoveev]

> On 24 Mar 2020, at 12:09, Marko Cupać  wrote:
> 
> On Tue, 24 Mar 2020 09:34:09 +0100
> Marko Cupać  wrote:
> 
>> On Tue, 24 Mar 2020 07:13:27 +1000
>> Stuart Longland  wrote:
>> 
>>> On 23/3/20 10:26 pm, Marko Cupać wrote:
>>>> Anything I can do to avoid future hangs?
> 
> I got another hang, this time killing npppd process crashed complete OS
> (sorry for photo, I don't have serial console set up):
> 
> https://oblak.mimar.rs/index.php/s/Cc9J745jH93RK6j
> 
> At the time when npppd wouldn't accept new connections, and npppctl
> won't return anything, but before the crash, i noticed high CPU usage
> in top:
> 
> 45125 _ppp  640 3128K 6340K onproc/3  -39:05 99.85% npppd
> 
> Pehaps bugs@ would be more appropriate list?
> 
> -- 
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
> 
> Marko Cupać
> https://www.mimar.rs/
> 
Can you try latest snapshot? Can you share your npppd.conf?

Re: npppd pptp hangs

[Marko Cupać]

On Tue, 24 Mar 2020 09:34:09 +0100
Marko Cupać  wrote:

> On Tue, 24 Mar 2020 07:13:27 +1000
> Stuart Longland  wrote:
> 
> > On 23/3/20 10:26 pm, Marko Cupać wrote:
> > > Anything I can do to avoid future hangs?

I got another hang, this time killing npppd process crashed complete OS
(sorry for photo, I don't have serial console set up):

https://oblak.mimar.rs/index.php/s/Cc9J745jH93RK6j

At the time when npppd wouldn't accept new connections, and npppctl
won't return anything, but before the crash, i noticed high CPU usage
in top:

45125 _ppp  640 3128K 6340K onproc/3  -    39:05 99.85% npppd

Pehaps bugs@ would be more appropriate list?

-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: npppd pptp hangs

[Marko Cupać]

On Tue, 24 Mar 2020 07:13:27 +1000
Stuart Longland  wrote:

> On 23/3/20 10:26 pm, Marko Cupać wrote:
> > Anything I can do to avoid future hangs?
> 
> Whilst probably not the answer you're looking for: moving away from
> PPTP would be a good start.
> 
> The MSCHAPv2 authentication used in PPTP is vulnerable to dictionary
> attacks and the RC4 cipher used in MPPE (the security layer of PPTP)
> is laughably weak in today's security context.  Whilst MSCHAPv2 can be
> replaced with EAP-TLS, there's no fix for MPPE.
> 
> IPSec (which is built into OpenBSD) or OpenVPN (in ports) would be
> vastly superior options.

Indeed, I am also waiting for the day when I'll be able to point iked
to Microsoft's implementation of a RADIUS server (NPS), which will
authenticate Active Directory domain-joined machines by their machine
certificate and hopefully with additional domain user password for 2FA,
authorise them by Active Directory group membership, and log their
accounting in format which can be easily parsed and converted into
human-readable statistics with currently available parsers.

Uh, that sounded like I'm some kind of Microsoft fanboy, but I'm not. I
just have to provide hundreds of Windows users a way to access resources
on a corporate network in order to keep my bills paid. npppd's pptp
helps me brilliantly (anyone remember poptop? that was hell :)

Anyway, I use IPSec extensively to connect branch office routers, both
in tunnel mode for passive clients with dynamic IPs, and in transport
mode for protecting GRE tunnels (OSPF). Lately I'm adding multipath
redundancy over multiple ISPs using rdomains. OpenVPN also has a place
on my network. OpenBSD is a miracle :)

Pardon my blatant self-promotion on link below, but I think it's a
win-win situation - I get eternal fame and glory on the Internet, and
list readers get copy/paste howto set up npppd pptp server with RADIUS
authentication. Could come handy in this "end of days" situation where
everyone works remotely :D

https://www.mimar.rs/blog/how-to-set-up-pptp-vpn-server-with-openbsd-and-npppd

Best regards,

-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: npppd pptp hangs

[Stuart Longland]

On 23/3/20 10:26 pm, Marko Cupać wrote:
> Anything I can do to avoid future hangs?

Whilst probably not the answer you're looking for: moving away from PPTP
would be a good start.

The MSCHAPv2 authentication used in PPTP is vulnerable to dictionary
attacks and the RC4 cipher used in MPPE (the security layer of PPTP) is
laughably weak in today's security context.  Whilst MSCHAPv2 can be
replaced with EAP-TLS, there's no fix for MPPE.

IPSec (which is built into OpenBSD) or OpenVPN (in ports) would be
vastly superior options.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

npppd pptp hangs

[Marko Cupać]

Hi,

my npppd pptp server has recently got increase from ~20 to >200
concurrent users. So far it worked flawlessly for years, but before few
minutes it become unresponsive.

It stopped logging at one point (I have log redirected to its own file,
/var/log/npppd). npppctl also hanged, returning nothing. I couldn't
restart it with rcctl, or kill it with HUP. I had to resort to `kill
-9', and it started fine afterwards.

It appears that already established sessions worked, but with poor
performance.

I have lots of these in log (I saw them earlier as well but they
weren't causing problems AFAIK):

Mar 23 12:03:26 nat1 /bsd: pipex: ppp=1869 iface=tun1 protocol=PPTP id=45012 
Received bad data packet: out of sequence: seq=1266880(1266946-1267010) 
ack=1915237(1915368-1915471)
Mar 23 12:03:26 nat1 /bsd: pipex: ppp=1869 iface=tun1 protocol=PPTP id=45012 
Received bad data packet: out of sequence: seq=1266881(1266946-1267010) 
ack=1915239(1915368-1915472)
Mar 23 12:03:26 nat1 /bsd: pipex: ppp=1869 iface=tun1 protocol=PPTP id=45012 
Workaround the out-of-sequence PPP framing problem: 1215 => 1151
Mar 23 12:06:59 nat1 /bsd: pipex: ppp=1847 iface=tun1 protocol=PPTP id=45439 
received packet caused window overflow. seq=218469(218273-218337)may lost 196 
packets.

Also, at the time before killing it there's:

Mar 23 13:13:37 nat1 /bsd: splassert: pipex_destroy_session: want 2 have 0
Mar 23 13:13:37 nat1 last message repeated 95 times


Anything I can do to avoid future hangs?

Thank you in advance,

-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: NPPPD Server behind a firewall

[Damian McGuckin]

On Wed, 16 Oct 2019, Stuart Henderson wrote:

I would srongly recommend switching to IKEv2 if you can, it is far 
easier to come up with a config that still gives decent crypto with 
mixed client platforms. (Internal client on Apple OS and non-ancient 
Windows - strongswan on Android/Linux).


I do not disagree.

I just need to move an existing NPPPD to behind a firewall in the short 
term that serves several iPads and Windows PCs. Once I have the move done, 
I want to move expand to IKEv2. I was also under the impression that IKEv2 
was faster.


The IPsec side should be ok as long as everything supports nat-t (not 
unusual).


I am still stuck and will try some new things on Monday.

Regards - Damian

Re: NPPPD Server behind a firewall

[Stuart Henderson]

>> There are ways to make even Windows clients use actual crypto with IPsec if
>> needed, though last I checked it could not be done from the GUI but required
>> powershell commands. (I don't have a URL handy, sorry, but this information
>> wasn't very hard to find when I needed it.)
>
> Thanks. I will investigate. This has to work with iPads as well. Yuk!

I would srongly recommend switching to IKEv2 if you can, it is far easier
to come up with a config that still gives decent crypto with mixed client
platforms. (Internal client on Apple OS and non-ancient Windows -
strongswan on Android/Linux).

>> I suspect getting IPsec SAs going with both peers behind NAT is tricky.
>
> I agree.

The IPsec side should be ok as long as everything supports nat-t (not unusual).

Re: NPPPD Server behind a firewall

[Damian McGuckin]

On Mon, 14 Oct 2019, Stefan Sperling wrote:


On Mon, Oct 14, 2019 at 05:55:58PM +1100, Damian McGuckin wrote:

Because I had a working L2TP server setup on $L2TP, I was not going to
go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf

ike passive esp transport \
proto udp from egress to any port 1701 \
main auth "hmac-sha1" enc "3des" group modp1024 \
quick auth "hmac-sha1" enc "3des" group modp1024 \
psk "MYSECRET"


As an aside, you should avoid use of 3des because it is effecively 
plaintext.


I take your point about 3des but I was starting from a known configuration 
which works (albiet with the external interface hacing a Public IP)



There are ways to make even Windows clients use actual crypto with IPsec if
needed, though last I checked it could not be done from the GUI but required
powershell commands. (I don't have a URL handy, sorry, but this information
wasn't very hard to find when I needed it.)


Thanks. I will investigate. This has to work with iPads as well. Yuk!


You could try to pin-point the problem a bit more, starting with diagnostics
at the IPsec layer. Check debug logs from isakmpd, check ipsectl -sa, etc.


OK.


I suspect getting IPsec SAs going with both peers behind NAT is tricky.


I agree.

See my subsequent post where I replaced 'egress' above with the external 
IP (of the subsequently NAT'd npppd server). Closer. But not quite there.


Thanks - Damian

Re: NPPPD Server behind a firewall

[Damian McGuckin]

I changed /etc/ipsec.conf to have 'ike' reflect the external IP

ike passive esp transport \
proto udp from $L2TPX to any port 1701 \
main auth "hmac-sha1" enc "aes" group modp2048 \
quick auth "hmac-sha1" enc "aes" group modp2048 \
psk "MYSECRET"

and restarted isakmpd and reloaded ipsec.conf.

On the inside of the NPPPD server, the only errors I get are

isakmpd[46608]: attribute_unacceptable: GROUP_DESCRIPTION: got ECP_384, 
expected MODP_2048
isakmpd[46608]: attribute_unacceptable: GROUP_DESCRIPTION: got ECP_256, 
expected MODP_2048

and I believe it should negotiate the groups. It should also negotiate "3des"
and my earlier "modp1024" but I wanted to minimize lines of errors.

While this is happening

ipsecctl -s flow (shows)

flow esp in proto udp from REMOTE-FW port l2tp to $L2TPI port l2tp peer
REMOTE-FW srcid $L2TPI/32 dstid 192.168.0.146/32 type use
flow esp out proto udp from $L2TPI port l2tp to REMOTE-FW port l2tp peer
REMOTE-FW srcid $L2TPI/32 dstid 192.168.0.146/32 type require

Note that there are only 2 lines above. I

Which reflects the network

[laptop-192.168.0.146]<->REMOTE-FW --internet-- FIRE<->SERVER-IP=$L2TPI)

and the firewall FIRE nats $L2TPX->$L2TPI

But, the VPN is never established, eventually

ipsecctl -s flow (shows)



Still at a loss.  Any suggestions?

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: NPPPD Server behind a firewall

[Stefan Sperling]

On Mon, Oct 14, 2019 at 05:55:58PM +1100, Damian McGuckin wrote:
> Because I had a working L2TP server setup on $L2TP, I was not going to
> go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf
> 
> ike passive esp transport \
> proto udp from egress to any port 1701 \
> main auth "hmac-sha1" enc "3des" group modp1024 \
> quick auth "hmac-sha1" enc "3des" group modp1024 \
> psk "MYSECRET"

As an aside, you should avoid use of 3des because it is effecively plaintext.
There are ways to make even Windows clients use actual crypto with IPsec if
needed, though last I checked it could not be done from the GUI but required
powershell commands. (I don't have a URL handy, sorry, but this information
wasn't very hard to find when I needed it.)
 
> Now I want to move the machine to a new site behind a new OpenBSD firewall,
> say FIRE. The difference is that now, $L2TP will have an unroutable address,
> say 10.200.100.200, or $L2TPI, as the IP on its external interface.  It will
> obviously have an external address, $L2TPX, but that will be exposed through
> FIRE, the external firewall. I want to binat from L2TPX->L2TPI.

> Any suggestions on what I have done wrong or what I need to do right.

You could try to pin-point the problem a bit more, starting with diagnostics
at the IPsec layer. Check debug logs from isakmpd, check ipsectl -sa, etc.
I suspect getting IPsec SAs going with both peers behind NAT is tricky.
I believe it should be possile in theory but I cannot confirm whether our
implementation can do this easily. It will certainly involve UDP traffic
since AH/ESP cannot pass through NAT.

If your IPsec SAs already work for other traffic, but npppd won't work,
that would imply that npppd has a limitation related to NAT; perhaps it
encodes the end-point IPs it is seeing in the L2TP protocol, which would
not match the actual layer 3 addresses used by IPsec?

NPPPD Server behind a firewall

[Damian McGuckin]

I have a L2TP NPPPD server machine with IP $L2TP sitting behind an OpenBSD 
firewall, say FIRET. 'T' for temporary because it will move. $L2TP is an 
externally routable IP. $Ext, the external interface of FIRET, allows

traffic into $L2TP. A snippet of pf.conf is

begin snippet-0
ipsecIN = "{ iskmpd, ipsec-nat-t, l2tp }"

pass in quick on $Ext inet proto udp from any to $L2TP port $ipsecIN keep state
pass in quick on $Ext inet proto esp from any to $L2TP
pass in quick on $Ext inet proto ah from any to $L2TP
end snippet-0

It all went wonderfully. It worked. I have done it before.

Because I had a working L2TP server setup on $L2TP, I was not going to
go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf

ike passive esp transport \
proto udp from egress to any port 1701 \
main auth "hmac-sha1" enc "3des" group modp1024 \
quick auth "hmac-sha1" enc "3des" group modp1024 \
psk "MYSECRET"

Now I want to move the machine to a new site behind a new OpenBSD firewall,
say FIRE. The difference is that now, $L2TP will have an unroutable address,
say 10.200.100.200, or $L2TPI, as the IP on its external interface.  It will
obviously have an external address, $L2TPX, but that will be exposed through
FIRE, the external firewall. I want to binat from L2TPX->L2TPI.

So on FIRE, where we will call the external interface, $Ext, again. I 
first binat things on FIRE.


match on $Ext from $L2TPI to any binat to $L2TPX

Because BINAT'ing is done before 'pass' rules are processed, the rules must
refer to the external interface.  Just to be sure, I will ensure that I can
SSH to $L2TPI, on FIRE I have a pf.conf with

pass in quick on $Ext inet proto tcp from any to $L2TPI port ssh\
flags S/SA modulate state

Yes, that works. I can SSH to $L2TPX and get all the way through FIRE and
get in through the interface $L2TPI of the NPPPD server.

OK, now I need to let the other protocols through. I think I want all 
traffic, once it gets onto $Ext, to be allowed through to the internal 
network on which $L2TPI sits with its IP 10.200.100.200.


begin snippet-1

ipsecIN = "{ iskmpd, ipsec-nat-t, l2tp }"

pass in quick on $Ext inet proto udp from any to $L2TPI port $ipsecIN keep state
pass in quick on $Ext inet proto esp from any to $L2TPI
pass in quick on $Ext inet proto ah from any to $L2TPI

end snippet-1

I can see traffic destined to 10.200.100.200 coming in through the external
interface of FIRE and going out to 10.200.100.200 and then, from within this
machine, i.e. the NPPPD Server, I see traffic coming in, admittedly on port
ipsec-nat-t, i.e. 4500. But it fails.

Any suggestions on what I have done wrong or what I need to do right.

Thanks - Damian

Re: npppd and vpn connections on the same network

[Biggins18]

This is quite informative and didn’t knew all this. Keep sharing such useful
information. I used free VPN but it’s quite slow and have made decision to
buy a good service. Have read  expressvpn review
<https://www.reviewsdir.com/expressvpn-review/>   at many sites and going to
sign up with them soon.



--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/npppd-and-vpn-connections-on-the-same-network-tp260921p321119.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: npppd troubles

[Stefan Sperling]

On Thu, Nov 03, 2016 at 06:48:56PM -0400, Marina Brown wrote:
> On 11/03/2016 03:36 PM, Stefan Sperling wrote:
> > On Thu, Nov 03, 2016 at 03:17:40PM -0400, Marina Brown wrote:
> >> Hi All:
> >>
> >> I have been trying to create an nppp connection across my property -
> >> about 100M for one of my friends who lives here. He wants less security
> >> than i like behind my firewall. I have not been able to get OpenBSD to
> >> route his connection out of the network. Here are my settings.
> > 
> >> # NAT Rule to translate from internal to External NET
> >> pass out on em0 inet from em1:network to any nat-to (em0)
> > 
> > You're using NAT when passing out on em0 here, and...
> >  
> >> external = em0
> > 
> >> pass out quick on $external from 10.0.0.103/32 to any
> > 
> > ... my guess is that you're missing 'nat-to ($external)' here ^
> > 
> 
> Thanks - is there a way to exclude the npppd users from the nat
> altogether. That is the reason for the excersize. If i put him
> behind the nat we are right where we started. He runs games that
> don't play well with strict NAT settings and i don't want the rest of my
> network exposed to reduced security.
> 
> I thought he would be on pppx0. Is there a way to do this.

Well, one way or another he will need to have his private 10.0.0.103
IP address translated to an IP that is actually valid on the internet.
There is no way around that.

pppx0 is where his packets arrive on your firewall. Your firewall has to
forward those packets to the internet and that requires using a public IP
as source address, else the internet won't be able to reply.

One option would be for him to get a VPN tunnel with some provider that
assigns public IPs to their VPN clients. That would solve this issue as long
as you still provide NAT so that his VPN client can reach the provider's
server across the internet. He would get his own public IP to use for the game.

Another option is to try adding 'static-port' to his NAT rule:

pass out quick on $external from 10.0.0.103/32 to any nat-to ($external) 
static-port

Perhaps that's enough to make the game he's playing work through NAT.

You could further restrict the above to certain ports used by the game.
For example, if the game was using the port range 5000:5100 then you could
do something like this:

pass out quick on $external from 10.0.0.103/32 to any port 5000:5100 nat-to 
($external) static-port

In this case all his other connections would still use randomized NAT ports.

Re: npppd troubles

[Marina Brown]

On 11/03/2016 03:36 PM, Stefan Sperling wrote:
> On Thu, Nov 03, 2016 at 03:17:40PM -0400, Marina Brown wrote:
>> Hi All:
>>
>> I have been trying to create an nppp connection across my property -
>> about 100M for one of my friends who lives here. He wants less security
>> than i like behind my firewall. I have not been able to get OpenBSD to
>> route his connection out of the network. Here are my settings.
> 
>> # NAT Rule to translate from internal to External NET
>> pass out on em0 inet from em1:network to any nat-to (em0)
> 
> You're using NAT when passing out on em0 here, and...
>  
>> external = em0
> 
>> pass out quick on $external from 10.0.0.103/32 to any
> 
> ... my guess is that you're missing 'nat-to ($external)' here ^
> 

Thanks - is there a way to exclude the npppd users from the nat
altogether. That is the reason for the excersize. If i put him
behind the nat we are right where we started. He runs games that
don't play well with strict NAT settings and i don't want the rest of my
network exposed to reduced security.

I thought he would be on pppx0. Is there a way to do this.


--- Marina Brown




signature.asc
Description: OpenPGP digital signature

Re: npppd troubles

[Stefan Sperling]

On Thu, Nov 03, 2016 at 03:17:40PM -0400, Marina Brown wrote:
> Hi All:
> 
> I have been trying to create an nppp connection across my property -
> about 100M for one of my friends who lives here. He wants less security
> than i like behind my firewall. I have not been able to get OpenBSD to
> route his connection out of the network. Here are my settings.

> # NAT Rule to translate from internal to External NET
> pass out on em0 inet from em1:network to any nat-to (em0)

You're using NAT when passing out on em0 here, and...
 
> external = em0

> pass out quick on $external from 10.0.0.103/32 to any

... my guess is that you're missing 'nat-to ($external)' here ^

npppd troubles

[Marina Brown]

Hi All:

I have been trying to create an nppp connection across my property -
about 100M for one of my friends who lives here. He wants less security
than i like behind my firewall. I have not been able to get OpenBSD to
route his connection out of the network. Here are my settings.


# uname -a
OpenBSD bernie.mesh.local 6.0 GENERIC.MP#2319 amd64


-

# $OpenBSD: npppd.conf,v 1.2 2014/03/22 04:32:39 yasuoka Exp $
# sample npppd configuration file.  see npppd.conf(5)

tunnel L2TP protocol l2tp
tunnel PPTP protocol pptp
tunnel PPPOE protocol pppoe {
listen on interface em1
}

ipcp IPCP {
pool-address 10.0.0.2-10.0.0.254
dns-servers 208.67.222.222 8.8.8.8
}
interface tun0 address 10.0.0.1 ipcp IPCP
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
bind tunnel from L2TP authenticated by LOCAL to tun0
bind tunnel from PPTP authenticated by LOCAL to tun0
bind tunnel from PPPOE authenticated by LOCAL to tun0

---

---
# more /etc/npppd/npppd

npppd-users  npppd.conf   npppd.conf.OLD
# more /etc/npppd/npppd-users

# $OpenBSD: npppd-users,v 1.1 2012/09/20 12:51:43 yasuoka Exp $
# sample npppd-users file.  see npppd-users(5)

#taro:\
#   :password=taro's password:\
#   :framed-ip-address=10.0.0.101:
#hana:\
#   :password=hana's password:\
#   :framed-ip-address=10.0.0.102:
kevin:\
:password=XX:\
:framed-ip-address=10.0.0.103:
laura:\
:password=testvpn:\
:framed-ip-address=10.0.0.104:
#
---

# npppctl session all

Ppp Id = 33
  Ppp Id  : 33
  Username: kevin
  Realm Name  : LOCAL
  Concentrated Interface  : tun0
  Assigned IPv4 Address   : 10.0.0.103
  Tunnel Protocol : PPPoE
  Tunnel From : 74:44:01:7a:13:e7
  Start Time  : 2016/11/03 12:53:59
  Elapsed Time: 3149 sec (52 minutes)
  Input Bytes : 69314 (67.7 KB)
  Input Packets   : 1986
  Input Errors: 1056 (34.7%)
  Output Bytes: 13021 (12.7 KB)
  Output Packets  : 1100
  Output Errors   : 0 (0.0%)
#
--
# route show
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
defaultc-73-114-67-1.hsd1 UGS  432 27284883 - 8
em0
BASE-ADDRESS.MCAST localhost  URS0  205 32768 8
lo0
10.0.0.128/26  localhost  UGB00 3276856
lo0
10.0.0.64/26   localhost  UGB00 3276856
lo0
10.0.0.192/27  localhost  UGB00 3276856
lo0
10.0.0.32/27   localhost  UGB0   14 3276856
lo0
10.0.0.8/29localhost  UGB01 3276856
lo0
10.0.0.4/30localhost  UGB0   20 3276856
lo0
10.0.0.2/31localhost  UGB00 3276856
lo0
10.0.0.1   tun0   UHl1   45 - 1
tun0
10.0.0.1/3210.0.0.1   UC 00 - 4
tun0
10.0.0.1   localhost  UGH00 3276856
lo0
10.0.0.16/28   localhost  UGB00 3276856
lo0
10.0.0.103 10.0.0.1   UGH0   55  149256
tun0
10.0.0.224/28  localhost  UGB00 3276856
lo0
10.0.0.240/29  localhost  UGB00 3276856
lo0
10.0.0.248/30  localhost  UGB00 3276856
lo0
10.0.0.252/31  localhost  UGB00 3276856
lo0
10.0.0.254/32  localhost  UGB00 3276856
lo0
73.114.67/24   c-73-114-67-57.hsd UC 10 - 4
em0
c-73-114-67-1.hsd1 00:5f:86:93:c4:22  UHLc   1  225 - 4
em0
c-73-114-67-57.hsd 00:00:24:d2:16:e0  UHLl   0   396542 - 1
em0
73.114.67.255  c-73-114-67-57.hsd UHb00 - 1
em0
loopback   localhost  UGRS   00 32768 8
lo0
localhost  localhost  UHl   15   15 32768 1
lo0
192.168.1/24   apache UC 6  749 - 4
em1
apache 00:00:24:d2:16:e1  UHLl   0   137387 - 1
em1
192.168.1.15   40:8d:5c:18:94:22  UHLc   0  2505472 - 4
em1
192.168.1.22   40:8d:5c:83:01:16  UHLc   1  4272213 - 4
em1
192.168.1.29   d0:50:99:7c:c7:95  UHLc   3  4213308 - 4
em1
192.168.1.51   90:6e:bb:03:3e:ff  UHLc   0   466079 - 4
em1
192.168.1.56   10:1f:74:5e:8b:67  UHLc   0 1173 - 4
em1
192.168.1.126  4c:cc:6a:09:fd:14  UHLc   0  4434626 - 4
em1
192.168.1.255  apache UH

npppd dies, posiibly due to lost route to radius server

[Marko Cupać]

Hi,

I have two active/passive CARPed boxes of 5.9 with latest errata patches
which serve as NAT firewalls, but also as pptp servers, which
authenticate users from Microsoft's implementation of radius server
(NPS).

In last two weeks, I had three occurrences of npppd going down. Last
32650 (!) lines of npppd log are the following two lines:

---cut-here---
Sep 14 15:32:50 nat1 npppd[11097]: sendto() failed in radius_request0:
No route to host
Sep 14 15:32:50 nat1 npppd[11097]: ppp id=956 radius accounting request
failed: No route to host
---cut-here---

Interestingly enough, last two lines have timestamp of only one second
later from the first two (of 32650):

---cut-here---
Sep 14 15:32:51 nat1 npppd[11097]: ppp id=956 radius accounting request
failed: No route to host
Sep 14 15:32:51 nat1 npppd[11097]: sendto() failed in radius_request0:
No route to host
---cut-here---

I am redirecting all the npppd logging to separate file by the
following configuration in syslog.conf:

---cut-here---
!!npppd
*.* /var/log/npppd
!*
---cut-here---

So, I would say the system logged 32650 lines of inaccessible radius
server in just one second, and finally crashed.

I noticed also following message in daemon log from a few minutes
before the crash:

---cut-here---
Sep 14 15:29:22 nat1 ospfd[2087]: send_packet: error sending packet on
interface bnx0: No buffer space available
---cut-here---

bnx0 is the interface over which radius server is accessed. I am aware
of errata 008_bnx.patch, and it is applied on this box as I said
earlier.

Is there anything I can do to prevent this?

Thank you in advance,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: L2TP/IPSec via npppd won't work with Android 5.x

[johnw]

Hi Renaud and the lists,

Did you tried to use iked/ikev2 for android (+5.x) client?
I checked my note3 is support ikev2 psk/rsa,
I want to setup my home OpenBSD router act as vpn/nat router for my note3,
Thanks.

Renaud Allard  allard.it> writes:

>
>
> I can't get android to connect with modp > 1024, but settings like this
> work:
> ike passive esp transport \
> proto udp from A.B.C.D to any port l2tp \
> main auth "hmac-sha2-256" enc "aes-256" group modp1024 \
> quick auth "hmac-sha2-256" enc "aes-256" \
> psk "mysharedsecret"

Re: L2TP/IPSec via npppd won't work with Android 5.x

[Renaud Allard]

On 03/25/2016 04:27 PM, Sly Midnight wrote:
> Hello,
>
> I don't mean to bring up an old thread, but I was wondering if anyone
> else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
> (preferably the version on the Nexus line of devices) connecting to
> ipsec/l2tp.
>
> I had this working late last year some time and hadn't used it in a few
> months.  When I went to use it again a few days ago it didn't work at
> all.  After rebooting my phone and even trying it on my tablet that
> coincidentally runs the exact same version of stock Android 6.0.1, it
> too didn't work there.
>
> I have confirmed some interesting behavior.
>
> First if I tweak the ipsec.conf stanza to something like:
>
>> ike passive esp transport \
>> proto udp from X.X.X.X to any port 1701 \
>> main auth "hmac-sha2-256" enc "aes-256" group "modp1024" \
>> quick auth "hmac-sha2-s256" enc "aes-256" group "modp1024" \
>> psk "redacted"
> It creates an IPSEC SA and flow as shown by ipsecctl -s all, but npppd
> never sees a connection attempt and tcpdumping enc0 shows no traffic and
> ultimately the connection fails.
>
> If I modify it to hmac-md5, aes, modp2048 I can get my Chromebook with
> latest updates to connect successfully.
> If I modify it to hmac-sha2-256, aes-256, modp2048 I can get an iPhone
> with iOS 9.3 to connect successfully.
> If I modify it to hmac-sha, aes, modp2048 I can get a Windows 10 box to
> connect successfully.
>
> If I restore it to hmac-sha1, aes, modp1024 I can get an older Android
> tablet (one of my kid's) to connect successfully.
>
> What else can I do to troubleshoot this?  Because I signed up to a free
> 1 day trial of some Internet based VPN provider and successfully was
> able to connect to their IPSEC/L2TP VPN using my Android phone so I know
> it works.  It must just be a recent change in Android (or during the
> OpenBSD 5.7->5.8) update that is causing this incompatibility that makes
> it almost work.  Any help would be greatly appreciated.
>

I can't get android to connect with modp > 1024, but settings like this
work:
ike passive esp transport \
proto udp from A.B.C.D to any port l2tp \
main auth "hmac-sha2-256" enc "aes-256" group modp1024 \
quick auth "hmac-sha2-256" enc "aes-256" \
psk "mysharedsecret"

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: L2TP/IPSec via npppd won't work with Android 6.0.1

[Sly Midnight]

Thank you!

I will try this.

I have confirmed it wasn't due to last year's OpenBSD 5.7 to 5.8 upgrade
as I built a VM with 5.7 using same settings and get exactly the same
behavior.  This was triple confirmed by being able to connect with iOS
on an iPhone, Windows 10, Chromebook (with md5 hmacs only) and even a
tablet running an older version of Android.  Here is the link to the bug
if anyone is interested.  But I will try the workaround offered by Yasuoka.

In the mean time, I have confirmed there is a Google Android bug
reported (by many people) confirming this is actually an issue with
Android not OpenBSD (or the myriad other VPN routers listed in the bug
report).  Though I very much appreciate understanding the underlying
reason as like Mattieu said, tweaking ipsec.conf for 3 days yielded no
solution.

https://code.google.com/p/android/issues/detail?id=196939

Thanks again!

Sly


On 03/30/2016 02:18 AM, YASUOKA Masahiko wrote:
> On Tue, 29 Mar 2016 11:37:14 +0200
> Mattieu Baptiste  wrote:
>> On Tue, Mar 29, 2016 at 5:43 AM, Sly Midnight  wrote:
>>> I don't mean to bring up an old thread, but I was wondering if anyone
>>> else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
>>> (preferably the version on the Nexus line of devices) connecting to
>>> ipsec/l2tp.
>>>
>>> I had this working late last year some time and hadn't used it in a few
>>> months.  When I went to use it again a few days ago it didn't work at
>>> all.  After rebooting my phone and even trying it on my tablet that
>>> coincidentally runs the exact same version of stock Android 6.0.1, it
>>> too didn't work there.
>> I have the very same problem.
>> To me, It's caused by some Android updates. I saw this since 6.0, but
>> some security updates near 5.1.1 seems to trigger the same behavior.
>> I've tried to tweak ipsec.conf like you without luck. Unfortunately, I
>> did not have the time to dig further...
> My colleague and I also hit this issue.
>
> This issue is caused by Android, it sends ESP packets with wrong
> padding size when SHA2-256 is selected for HMAC.  It seems that
> Android is using an old ietf draft for SHA2-256, but OpenBSD is using
> RFC 4868.
>
> When the issue occurs,
>
>   XXX packets with bad payload size or padding received
>
> counter in "netstat -sp esp" will be incremented.
>
> We can force using MD5 or SHA for HMAC to workaround this issue.  To
> do this, put the text below to /etc/isakmpd/isakmpd.policy and remove
> "-K" from isakmpd_flags.
>
>   Authorizer: "POLICY"
>   Comment: This is test
>   Licensees: "passphrase:PASSPHRASE"
>   conditions: app_domain == "IPsec policy" && doi == "ipsec" && esp_present 
> == "yes" && (esp_auth_alg == "hmac-md5" || esp_auth_alg == "hmac-sha") -> 
> "true";
>
> --yasuoka

Re: L2TP/IPSec via npppd won't work with Android 6.0.1

[Mattieu Baptiste]

On Wed, Mar 30, 2016 at 8:18 AM, YASUOKA Masahiko  wrote:
> On Tue, 29 Mar 2016 11:37:14 +0200
> Mattieu Baptiste  wrote:
>> On Tue, Mar 29, 2016 at 5:43 AM, Sly Midnight  wrote:
>>> I don't mean to bring up an old thread, but I was wondering if anyone
>>> else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
>>> (preferably the version on the Nexus line of devices) connecting to
>>> ipsec/l2tp.
>>>
>>> I had this working late last year some time and hadn't used it in a few
>>> months.  When I went to use it again a few days ago it didn't work at
>>> all.  After rebooting my phone and even trying it on my tablet that
>>> coincidentally runs the exact same version of stock Android 6.0.1, it
>>> too didn't work there.
>>
>> I have the very same problem.
>> To me, It's caused by some Android updates. I saw this since 6.0, but
>> some security updates near 5.1.1 seems to trigger the same behavior.
>> I've tried to tweak ipsec.conf like you without luck. Unfortunately, I
>> did not have the time to dig further...
>
> My colleague and I also hit this issue.

[...]

> We can force using MD5 or SHA for HMAC to workaround this issue.  To
> do this, put the text below to /etc/isakmpd/isakmpd.policy and remove
> "-K" from isakmpd_flags.
>
>   Authorizer: "POLICY"
>   Comment: This is test
>   Licensees: "passphrase:PASSPHRASE"
>   conditions: app_domain == "IPsec policy" && doi == "ipsec" && esp_present 
> == "yes" && (esp_auth_alg == "hmac-md5" || esp_auth_alg == "hmac-sha") -> 
> "true";

Thank you, it works flawlessly with that change.

-- 
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."

Re: L2TP/IPSec via npppd won't work with Android 6.0.1

[YASUOKA Masahiko]

On Tue, 29 Mar 2016 11:37:14 +0200
Mattieu Baptiste  wrote:
> On Tue, Mar 29, 2016 at 5:43 AM, Sly Midnight  wrote:
>> I don't mean to bring up an old thread, but I was wondering if anyone
>> else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
>> (preferably the version on the Nexus line of devices) connecting to
>> ipsec/l2tp.
>>
>> I had this working late last year some time and hadn't used it in a few
>> months.  When I went to use it again a few days ago it didn't work at
>> all.  After rebooting my phone and even trying it on my tablet that
>> coincidentally runs the exact same version of stock Android 6.0.1, it
>> too didn't work there.
> 
> I have the very same problem.
> To me, It's caused by some Android updates. I saw this since 6.0, but
> some security updates near 5.1.1 seems to trigger the same behavior.
> I've tried to tweak ipsec.conf like you without luck. Unfortunately, I
> did not have the time to dig further...

My colleague and I also hit this issue.

This issue is caused by Android, it sends ESP packets with wrong
padding size when SHA2-256 is selected for HMAC.  It seems that
Android is using an old ietf draft for SHA2-256, but OpenBSD is using
RFC 4868.

When the issue occurs,

  XXX packets with bad payload size or padding received

counter in "netstat -sp esp" will be incremented.

We can force using MD5 or SHA for HMAC to workaround this issue.  To
do this, put the text below to /etc/isakmpd/isakmpd.policy and remove
"-K" from isakmpd_flags.

  Authorizer: "POLICY"
  Comment: This is test
  Licensees: "passphrase:PASSPHRASE"
  conditions: app_domain == "IPsec policy" && doi == "ipsec" && esp_present == 
"yes" && (esp_auth_alg == "hmac-md5" || esp_auth_alg == "hmac-sha") -> "true";

--yasuoka

Re: L2TP/IPSec via npppd won't work with Android 6.0.1

[Mattieu Baptiste]

On Tue, Mar 29, 2016 at 5:43 AM, Sly Midnight  wrote:
> Hello,
>
> I don't mean to bring up an old thread, but I was wondering if anyone
> else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
> (preferably the version on the Nexus line of devices) connecting to
> ipsec/l2tp.
>
> I had this working late last year some time and hadn't used it in a few
> months.  When I went to use it again a few days ago it didn't work at
> all.  After rebooting my phone and even trying it on my tablet that
> coincidentally runs the exact same version of stock Android 6.0.1, it
> too didn't work there.

Hi,

I have the very same problem.
To me, It's caused by some Android updates. I saw this since 6.0, but
some security updates near 5.1.1 seems to trigger the same behavior.
I've tried to tweak ipsec.conf like you without luck. Unfortunately, I
did not have the time to dig further...

Regards.
-- 
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."

L2TP/IPSec via npppd won't work with Android 6.0.1

[Sly Midnight]

Hello,

I don't mean to bring up an old thread, but I was wondering if anyone
else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
(preferably the version on the Nexus line of devices) connecting to
ipsec/l2tp.

I had this working late last year some time and hadn't used it in a few
months.  When I went to use it again a few days ago it didn't work at
all.  After rebooting my phone and even trying it on my tablet that
coincidentally runs the exact same version of stock Android 6.0.1, it
too didn't work there.

I have confirmed some interesting behavior.

First if I tweak the ipsec.conf stanza to something like:

> ike passive esp transport \
> proto udp from X.X.X.X to any port 1701 \
> main auth "hmac-sha2-256" enc "aes-256" group "modp1024" \
> quick auth "hmac-sha2-s256" enc "aes-256" group "modp1024" \
> psk "redacted"

It creates an IPSEC SA and flow as shown by ipsecctl -s all, but npppd
never sees a connection attempt and tcpdumping enc0 shows no traffic and
ultimately the connection fails.

If I modify it to hmac-md5, aes, modp2048 I can get my Chromebook with
latest updates to connect successfully.
If I modify it to hmac-sha2-256, aes-256, modp2048 I can get an iPhone
with iOS 9.3 to connect successfully.
If I modify it to hmac-sha, aes, modp2048 I can get a Windows 10 box to
connect successfully.

If I restore it to hmac-sha1, aes, modp1024 I can get an older Android
tablet (one of my kid's) to connect successfully.

What else can I do to troubleshoot this?  Because I signed up to a free
1 day trial of some Internet based VPN provider and successfully was
able to connect to their IPSEC/L2TP VPN using my Android phone so I know
it works.  It must just be a recent change in Android (or during the
OpenBSD 5.7->5.8) update that is causing this incompatibility that makes
it almost work.  Any help would be greatly appreciated.

Sly

Re: L2TP/IPSec via npppd won't work with Android 5.x

[Sly Midnight]

Hello,

I don't mean to bring up an old thread, but I was wondering if anyone
else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
(preferably the version on the Nexus line of devices) connecting to
ipsec/l2tp.

I had this working late last year some time and hadn't used it in a few
months.  When I went to use it again a few days ago it didn't work at
all.  After rebooting my phone and even trying it on my tablet that
coincidentally runs the exact same version of stock Android 6.0.1, it
too didn't work there.

I have confirmed some interesting behavior.

First if I tweak the ipsec.conf stanza to something like:

> ike passive esp transport \
> proto udp from X.X.X.X to any port 1701 \
> main auth "hmac-sha2-256" enc "aes-256" group "modp1024" \
> quick auth "hmac-sha2-s256" enc "aes-256" group "modp1024" \
> psk "redacted"
It creates an IPSEC SA and flow as shown by ipsecctl -s all, but npppd
never sees a connection attempt and tcpdumping enc0 shows no traffic and
ultimately the connection fails.

If I modify it to hmac-md5, aes, modp2048 I can get my Chromebook with
latest updates to connect successfully.
If I modify it to hmac-sha2-256, aes-256, modp2048 I can get an iPhone
with iOS 9.3 to connect successfully.
If I modify it to hmac-sha, aes, modp2048 I can get a Windows 10 box to
connect successfully.

If I restore it to hmac-sha1, aes, modp1024 I can get an older Android
tablet (one of my kid's) to connect successfully.

What else can I do to troubleshoot this?  Because I signed up to a free
1 day trial of some Internet based VPN provider and successfully was
able to connect to their IPSEC/L2TP VPN using my Android phone so I know
it works.  It must just be a recent change in Android (or during the
OpenBSD 5.7->5.8) update that is causing this incompatibility that makes
it almost work.  Any help would be greatly appreciated.

Sly

On 02/22/2016 07:48 AM, Stefan Krueger wrote:
> In mailing.openbsd.misc, you wrote:
>> Hi, everyone:
>>
>> [...]
>>
>> But the android devices I had won't work by all means. I found out that
>> Android 5.x
>> L2TP/IPSec VPN client works in:
>> hash algorithm: hmac-sha2-256
>> encrypt method: aes_cbc
>> life time: 28800
>>
>> The ipsec.conf with:
>> ``
>> ike passive esp tunnel \
>>  from "IP_ADDRESS" to any \
>>  main auth "hmac-sha2-256" enc "aes" group "modp1024" lifetime 2880\
>>  quick group "modp1024" \
>>  psk "SECRET_KEY"
>> '' didn't make a chage.(after `ipsecctl -f /etc/ipsec.conf`)
> Hi,
>
> the following config worked for me when I was using it (with npppd)
> last year (dumped it since I couldn't find a way to use it with iOS
> and Android at the same time):
>
> /etc/ipsec.conf
> public_ip = "x.y.z.a"
>
> ike passive esp transport \
> proto udp from $public_ip to any port l2tp \
> aggressive auth "hmac-sha1" enc "aes" group modp1024 \
> psk "XXX"
>
> IIRC Android required the use of "aggressive auth" where iOS only worked
> with the default "main auth"...

Re: L2TP/IPSec via npppd won't work with Android 5.x

[Stefan Krueger]

In mailing.openbsd.misc, you wrote:
> Hi, everyone:
>
> [...]
>
> But the android devices I had won't work by all means. I found out that
> Android 5.x
> L2TP/IPSec VPN client works in:
> hash algorithm: hmac-sha2-256
> encrypt method: aes_cbc
> life time: 28800
>
> The ipsec.conf with:
> ``
> ike passive esp tunnel \
>  from "IP_ADDRESS" to any \
>  main auth "hmac-sha2-256" enc "aes" group "modp1024" lifetime 2880\
>  quick group "modp1024" \
>  psk "SECRET_KEY"
> '' didn't make a chage.(after `ipsecctl -f /etc/ipsec.conf`)

Hi,

the following config worked for me when I was using it (with npppd)
last year (dumped it since I couldn't find a way to use it with iOS
and Android at the same time):

/etc/ipsec.conf
public_ip = "x.y.z.a"

ike passive esp transport \
proto udp from $public_ip to any port l2tp \
aggressive auth "hmac-sha1" enc "aes" group modp1024 \
psk "XXX"

IIRC Android required the use of "aggressive auth" where iOS only worked
with the default "main auth"...

Re: L2TP/IPSec via npppd won't work with Android 5.x

[YASUOKA Masahiko]

Hi,

On Mon, 22 Feb 2016 00:26:11 +0800
Jiahao Dai  wrote:
> I am a new openBSD user and I found it's extramly difficult to setup a
> L2TP/IPSec(IKEv1) Road Warrior server to getting work with Android devices.
> 
> I followed the tutorial here Configuring L2TP Over IPSec on OpenBSD for Mac
> OS X
> Clients [1], deployed on fresh openBSD 5.8 and found out that iOS9.x ipad
> works like a
> charm.
> 
> But the android devices I had won't work by all means. I found out that
> Android 5.x
> L2TP/IPSec VPN client works in:
> hash algorithm: hmac-sha2-256
> encrypt method: aes_cbc
> life time: 28800
> 
> The ipsec.conf with:
> ``
> ike passive esp tunnel \
>  from "IP_ADDRESS" to any \
>  main auth "hmac-sha2-256" enc "aes" group "modp1024" lifetime 2880\
>  quick group "modp1024" \
>  psk "SECRET_KEY"
> '' didn't make a chage.(after `ipsecctl -f /etc/ipsec.conf`)
> 
> The /var/log/messages didn't report anything as the VPN connection failed
> on
> Android device.
> 
> When debugging at the foreground with `isakmpd -v -K -d`

In this case, you should do "ipsecctl -f /etc/ipsec.conf" again after
start the isakmpd.

> It still reported that:
> ``
> 002212.657833 Default isakmpd: starting [priv]
> 002219.561051 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561236 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561386 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561546 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561664 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561746 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561832 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
> PRE_SHARED, expected RSA_SIG
> 002219.561916 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
> PRE_SHARED, expected RSA_SIG
> 002219.562003 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
> PRE_SHARED, expected RSA_SIG
> 002219.562085 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> DES_CBC, expected 3DES_CBC
> 002219.562189 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> DES_CBC, expected 3DES_CBC
> 002219.562308 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> DES_CBC, expected 3DES_CBC
> 002219.562385 Default message_negotiate_sa: no compatible proposal found
> 002219.562459 Default dropped message from 139.227.237.86 port 500 due to
> notification type NO_PROPOSAL_CHOSEN
> ^C002221.748476 Default isakmpd: shutting down...
> 002221.748562 Default isakmpd: exit
> 
> ""
> 
> I am trying to use aes and encryption algorithm but it seems that it keep
> using 3des, what can I do?

This seems that the "ike" line in ipsec.conf wasn't appied to the
received packets.

I think you should:

  - make sure to do "ipsectl" after iksampd starts
(ipsec=YES in rc.conf.local does this)
  - check the "ike" line (especially the IP address of "from")

> Please help. I have spent all my weekends on it, still no idea. Other idea
> on VPN
> type with setup (except OpenVPN which needs additional software implement)
> are
> welcome.
> Jiahao Dai

L2TP/IPSec via npppd won't work with Android 5.x

[Jiahao Dai]

Hi, everyone:

I am a new openBSD user and I found it's extramly difficult to setup a
L2TP/IPSec(IKEv1) Road Warrior server to getting work with Android devices.

I followed the tutorial here Configuring L2TP Over IPSec on OpenBSD for Mac
OS X
Clients [1], deployed on fresh openBSD 5.8 and found out that iOS9.x ipad
works like a
charm.

But the android devices I had won't work by all means. I found out that
Android 5.x
L2TP/IPSec VPN client works in:
hash algorithm: hmac-sha2-256
encrypt method: aes_cbc
life time: 28800

The ipsec.conf with:
``
ike passive esp tunnel \
 from "IP_ADDRESS" to any \
 main auth "hmac-sha2-256" enc "aes" group "modp1024" lifetime 2880\
 quick group "modp1024" \
 psk "SECRET_KEY"
'' didn't make a chage.(after `ipsecctl -f /etc/ipsec.conf`)

The /var/log/messages didn't report anything as the VPN connection failed
on
Android device.

When debugging at the foreground with `isakmpd -v -K -d`
It still reported that:
``
002212.657833 Default isakmpd: starting [priv]
002219.561051 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
AES_CBC, expected 3DES_CBC
002219.561236 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
AES_CBC, expected 3DES_CBC
002219.561386 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
AES_CBC, expected 3DES_CBC
002219.561546 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
AES_CBC, expected 3DES_CBC
002219.561664 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
AES_CBC, expected 3DES_CBC
002219.561746 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
AES_CBC, expected 3DES_CBC
002219.561832 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
PRE_SHARED, expected RSA_SIG
002219.561916 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
PRE_SHARED, expected RSA_SIG
002219.562003 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
PRE_SHARED, expected RSA_SIG
002219.562085 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
DES_CBC, expected 3DES_CBC
002219.562189 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
DES_CBC, expected 3DES_CBC
002219.562308 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
DES_CBC, expected 3DES_CBC
002219.562385 Default message_negotiate_sa: no compatible proposal found
002219.562459 Default dropped message from 139.227.237.86 port 500 due to
notification type NO_PROPOSAL_CHOSEN
^C002221.748476 Default isakmpd: shutting down...
002221.748562 Default isakmpd: exit

""

I am trying to use aes and encryption algorithm but it seems that it keep
using 3des, what can I do?


Please help. I have spent all my weekends on it, still no idea. Other idea
on VPN
type with setup (except OpenVPN which needs additional software implement)
are
welcome.
Jiahao Dai

Re: npppd pppx0 VPN Client can access wan but cannot access lan

[torsten]

> I'm, running OpenBSD 5.8, npppd, mpath and have tried the same on 5.7 and
5.3.
> npppd is works fine and clients can connect using windows pptp client.
> The Client has the pptp connection set as default gateway and can 
> access the internet through the vpn gateway but cannot access the LAN
network.
> Traffic arrives on the pppx0 interface but never get forwarded to the 
> LAN ip address.

Can you see the traffic for the LAN on $int_if or the other physical
interfaces?

>   ## vpn
> pass quick log on pppx
> match out log on $ext1_if from $vpn_net nat-to ($ext1_if)
> match out log on $ext2_if from $vpn_net nat-to ($ext2_if)
> match out log on $int_if from $vpn_net nat-to ($int_if)

Fist line, "pass quick", becomes the last rule for traffic in/out on the
pppx interface since it is "quick".  So subsequent rules (including nat) are
not applied.

--yasuoka

I'm used to pf on FreeBSD, the problem was not the quick rule.
It looks like that pf or kernel on OpenBSD sets a "block all" on any
interface not defined in the pf.conf using skip or pass rules, which is a
good thing because this closes unintended security holes.

Thanks for your help.

The  below pf.conf does the trick
### NAT
  ## int_net
match out log on $ext1_if from $int_net nat-to ($ext1_if)
match out log on $ext2_if from $int_net nat-to ($ext2_if)

  ## vpn
match out log on $ext1_if from $vpn_net nat-to ($ext1_if)
match out log on $ext2_if from $vpn_net nat-to ($ext2_if)
match out log on $int_if from $vpn_net nat-to ($int_if)

### FILTER RULES
block drop quick inet6
block log all
pass out log

  ## allow ping, traceroute and echo
pass in log inet proto icmp all icmp-type $icmp_types

  ## internal network
pass in log on $int_if

  ## pass connections to vpn server
pass in log on pppx
pass log proto { gre } from any to any keep state
pass in log on $ext1_if proto tcp from any to $ext1_if port 1723
pass in log on $ext2_if proto tcp from any to $ext2_if port 1723

Re: npppd pppx0 VPN Client can access wan but cannot access lan

[YASUOKA Masahiko]

Hi,

On Sat, 19 Dec 2015 01:11:40 -
"torsten" <tors...@cnc-london.net> wrote:
> I'm, running OpenBSD 5.8, npppd, mpath and have tried the same on 5.7 and 5.3.
> npppd is works fine and clients can connect using windows pptp client.
> The Client has the pptp connection set as default gateway and can access the
> internet through the vpn gateway but cannot access the LAN network.
> Traffic arrives on the pppx0 interface but never get forwarded to the LAN ip
> address.

Can you see the traffic for the LAN on $int_if or the other physical
interfaces?

>   ## vpn
> pass quick log on pppx
> match out log on $ext1_if from $vpn_net nat-to ($ext1_if)
> match out log on $ext2_if from $vpn_net nat-to ($ext2_if)
> match out log on $int_if from $vpn_net nat-to ($int_if)

Fist line, "pass quick", becomes the last rule for traffic in/out on
the pppx interface since it is "quick".  So subsequent rules
(including nat) are not applied.

--yasuoka

Re: npppd pppx0 VPN Client can access wan but cannot access lan

[torsten]

Hi
Is there anyone who can help to resolve the problem i have with pppx, tun and
tap using npppd and openVPN not forwarding traffic to ingress but egress works
fine.
It was my first post to the list and if there is any info or further details
required just ask, I would appreciate any help or hints.
I know I'm missing something in my config but can't find it.
Thanks
torsten


-Original Message-
From: torsten [mailto:tors...@cnc-london.net]
Sent: 16 December 2015 23:21
To: 'misc@openbsd.org'
Subject: npppd pppx0 VPN Client can access wan but cannot access lan

Hi

I'm, running OpenBSD 5.8, npppd, mpath and have tried the same on 5.7 and 5.3.
npppd is works fine and clients can connect using windows pptp client.
The Client has the pptp connection set as default gateway and can access the
internet through the vpn gateway but cannot access the LAN network.
Traffic arrives on the pppx0 interface but never get forwarded to the LAN ip
address.
I have been looking and trying for over 2 weeks now and can't figure that one
out.
Setting everything to pass in pf.conf and only enabling nat - still no
result.

Setup: OpenBSD 5.8 with npppd using pppx0 or tun0 and pf 2 WAN interfaces
equal cost routing (net.inet.ip.multipath=1), 1 LAN interface

sysctl.conf

net.inet.ip.forwarding=1
net.inet.ip.multipath=1
net.inet.gre.allow=1
net.pipex.enable=1

npptp.conf:

set max-session 20
set user-max-session 5
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel VPN protocol pptp {
listen on 0.0.0.0
}
ipcp IPCP {
pool-address 10.219.219.2-10.219.219.100
dns-servers 192.168.0.189 192.168.0.19
nbns-servers 192.168.0.189 192.168.0.19 } interface pppx0 address
10.219.219.1 ipcp IPCP bind tunnel from VPN authenticated by LOCAL to pppx0

pf.conf

### NAT
match out log on $ext1_if from $int_net nat-to ($ext1_if)
match out log on $ext2_if from $int_net nat-to ($ext2_if)

  ## vpn
pass quick log on pppx
match out log on $ext1_if from $vpn_net nat-to ($ext1_if)
match out log on $ext2_if from $vpn_net nat-to ($ext2_if)
match out log on $int_if from $vpn_net nat-to ($int_if)

### FILTER RULES
block log quick inet6
block in log on $ext1_if
block in log on $ext2_if

  ## allow ping, traceroute and echo
pass in log inet proto icmp all icmp-type $icmp_types

  ## pass connections to vpn server
pass log proto { gre } from any to any keep state
pass in log on $ext1_if proto tcp from any to $ext1_if port 1723
pass in log on $ext2_if proto tcp from any to $ext2_if port 1723
pass in  on enc0 from $vpn_net to $int_net keep state (if-bound)
pass out on enc0 from $int_net to $vpn_net keep state (if-bound)
pass in  on pppx from $vpn_net to $int_net keep state (if-bound)
pass out on pppx from $int_net to $vpn_net keep state (if-bound)

netstat -rn Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
defaulta.a.a.113  UGSP   0  1073494 - 8 em0
defaultb.b.b.97   UGSP   410294 - 8 em1
10.219.219.1   10.219.219.1   UHl00 - 1 lo0
10.219.219.14  10.219.219.1   UH 0  679 - 8 pppx0
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UHl14 32768 1 lo0
b.b.b.96/28b.b.b.110  UC 10 - 8 em1
b.b.b.97   bc:16:65:34:33:81  UHLc   10 - 8 em1
b.b.b.110  00:15:17:48:7b:23  HLl00 - 1 lo0
b.b.b.111  b.b.b.110  UHb00 - 1 em1
192.168.0/22   192.168.0.238  UC 90 - 8 em3
192.168.0.400:25:90:7c:40:cf  UHLc   04 - 8 em3
192.168.0.500:30:48:7d:7c:64  UHLc   01 - 8 em3
192.168.0.600:25:90:3c:30:67  UHLc   02 - 8 em3
192.168.0.10   f4:6d:04:29:ea:f7  UHLc   04 - 8 em3
192.168.0.19   00:25:90:72:89:1a  UHLc   0 8388 - 8 em3
192.168.0.189  00:30:48:d8:f0:0b  UHLc   0 9661 - 8 em3
192.168.0.238  00:25:90:d0:17:10  HLl00 - 1 lo0
192.168.0.253  00:25:90:af:5d:0a  UHLc   0  154 - 8 em3
192.168.2.167  50:e5:49:e6:c3:3c  UHLc   0 2048 - 8 em3
192.168.3.202  00:25:90:af:5d:0a  UHLc   1 9329 - L   8 em3
192.168.3.255  192.168.0.238  UHb00 - 1 em3
a.a.a.112/28   a.a.a.126  UC 20 - 8 em0
a.a.a.113  00:00:5e:00:01:0c  UHLc   10 - 8 em0
a.a.a.116  00:25:90:af:5d:0b  UHLc   234417 - L   8 em0
a.a.a.126  00:15:17:48:7b:22  HLl00 - 1 lo0
a.a.a.127  a.a.a.126  UH

Re: npppd pppx0 VPN Client can access wan but cannot access lan

[torsten]

On Sat, 19 Dec 2015 01:11:40 -
"torsten" <tors...@cnc-london.net> wrote:
> I'm, running OpenBSD 5.8, npppd, mpath and have tried the same on 5.7 and
5.3.
> npppd is works fine and clients can connect using windows pptp client.
> The Client has the pptp connection set as default gateway and can 
> access the internet through the vpn gateway but cannot access the LAN
network.
> Traffic arrives on the pppx0 interface but never get forwarded to the 
> LAN ip address.

Can you see the traffic for the LAN on $int_if or the other physical
interfaces?

>   ## vpn
> pass quick log on pppx
> match out log on $ext1_if from $vpn_net nat-to ($ext1_if)
> match out log on $ext2_if from $vpn_net nat-to ($ext2_if)
> match out log on $int_if from $vpn_net nat-to ($int_if)

Fist line, "pass quick", becomes the last rule for traffic in/out on the
pppx interface since it is "quick".  So subsequent rules (including nat) are
not applied.

--yasuoka

I will trace it in the morning, looks promising trough
Thank you for your reply

npppd pppx0 VPN Client can access wan but cannot access lan

[torsten]

Hi

I'm, running OpenBSD 5.8, npppd, mpath and have tried the same on 5.7 and 5.3.
npppd is works fine and clients can connect using windows pptp client.
The Client has the pptp connection set as default gateway and can access the
internet through the vpn gateway
but cannot access the LAN network.
Traffic arrives on the pppx0 interface but never get forwarded to the LAN ip
address.
I have been looking and trying for over 2 weeks now and can't figure that one
out.
Setting everything to pass in pf.conf and only enabling nat - still no
result.

Setup: OpenBSD 5.8 with npppd using pppx0 or tun0 and pf 2 WAN interfaces
equal cost routing (net.inet.ip.multipath=1), 1 LAN interface

sysctl.conf

net.inet.ip.forwarding=1
net.inet.ip.multipath=1
net.inet.gre.allow=1
net.pipex.enable=1

npptp.conf:

set max-session 20
set user-max-session 5
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel VPN protocol pptp {
listen on 0.0.0.0
}
ipcp IPCP {
pool-address 10.219.219.2-10.219.219.100
dns-servers 192.168.0.189 192.168.0.19
nbns-servers 192.168.0.189 192.168.0.19
}
interface pppx0 address 10.219.219.1 ipcp IPCP
bind tunnel from VPN authenticated by LOCAL to pppx0

pf.conf

### NAT
match out log on $ext1_if from $int_net nat-to ($ext1_if)
match out log on $ext2_if from $int_net nat-to ($ext2_if)

  ## vpn
pass quick log on pppx
match out log on $ext1_if from $vpn_net nat-to ($ext1_if)
match out log on $ext2_if from $vpn_net nat-to ($ext2_if)
match out log on $int_if from $vpn_net nat-to ($int_if)

### FILTER RULES
block log quick inet6
block in log on $ext1_if
block in log on $ext2_if

  ## allow ping, traceroute and echo
pass in log inet proto icmp all icmp-type $icmp_types

  ## pass connections to vpn server
pass log proto { gre } from any to any keep state
pass in log on $ext1_if proto tcp from any to $ext1_if port 1723
pass in log on $ext2_if proto tcp from any to $ext2_if port 1723
pass in  on enc0 from $vpn_net to $int_net keep state (if-bound)
pass out on enc0 from $int_net to $vpn_net keep state (if-bound)
pass in  on pppx from $vpn_net to $int_net keep state (if-bound)
pass out on pppx from $int_net to $vpn_net keep state (if-bound)

netstat -rn Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
defaulta.a.a.113  UGSP   0  1073494 - 8 em0
defaultb.b.b.97   UGSP   410294 - 8 em1
10.219.219.1   10.219.219.1   UHl00 - 1 lo0
10.219.219.14  10.219.219.1   UH 0  679 - 8 pppx0
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UHl14 32768 1 lo0
b.b.b.96/28b.b.b.110  UC 10 - 8 em1
b.b.b.97   bc:16:65:34:33:81  UHLc   10 - 8 em1
b.b.b.110  00:15:17:48:7b:23  HLl00 - 1 lo0
b.b.b.111  b.b.b.110  UHb00 - 1 em1
192.168.0/22   192.168.0.238  UC 90 - 8 em3
192.168.0.400:25:90:7c:40:cf  UHLc   04 - 8 em3
192.168.0.500:30:48:7d:7c:64  UHLc   01 - 8 em3
192.168.0.600:25:90:3c:30:67  UHLc   02 - 8 em3
192.168.0.10   f4:6d:04:29:ea:f7  UHLc   04 - 8 em3
192.168.0.19   00:25:90:72:89:1a  UHLc   0 8388 - 8 em3
192.168.0.189  00:30:48:d8:f0:0b  UHLc   0 9661 - 8 em3
192.168.0.238  00:25:90:d0:17:10  HLl00 - 1 lo0
192.168.0.253  00:25:90:af:5d:0a  UHLc   0  154 - 8 em3
192.168.2.167  50:e5:49:e6:c3:3c  UHLc   0 2048 - 8 em3
192.168.3.202  00:25:90:af:5d:0a  UHLc   1 9329 - L   8 em3
192.168.3.255  192.168.0.238  UHb00 - 1 em3
a.a.a.112/28   a.a.a.126  UC 20 - 8 em0
a.a.a.113  00:00:5e:00:01:0c  UHLc   10 - 8 em0
a.a.a.116  00:25:90:af:5d:0b  UHLc   234417 - L   8 em0
a.a.a.126  00:15:17:48:7b:22  HLl00 - 1 lo0
a.a.a.127  a.a.a.126  UHb00 - 1 em0
224/4  127.0.0.1  URS00 32768 8 lo0

Re: npppd and pf

[Jeremy]

Hi Imre

Thanks for your reply. I successfully translated your wiki. Your notes
were very helpful. Manually adding an entry for proxy arp does seem to
make the VPN work.

Is this really the best solution for this issue though ? I would have to
add an arp entry for every IP assigned by npppd.

Would this "just work" if I put my VPN on a different subnet ?

J

On Fri, 13 Nov 2015 01:29:34 +0200
Imre Oolberg <i...@auul.pri.ee> wrote:

> Hi!
> 
> I must apologize i didt read thru your text attentiatively but i 
> believe it is because of arp. Although i am just an user of npppd i
> run it already for some time and i think it works very well. Here are
> my notes, see if there are some use for them, hope Google translates
> it,
> http://www.auul.pri.ee/wiki/L2TP/IPSec_serveri_kasutamine_operatsioonis%C3%BCsteemiga_OpenBSD#ARP_proxy
> 
> 
> Imre
> 
> 
> On 2015-11-13 01:18, Jeremy wrote:
> > I'm adding more functionality to my firewall (OpenBSD 5.7) and have 
> > been
> > trying to configure PPTP VPN access for my Windows users. I have
> > got npppd
> > running using the config below and can successfully authenticate and
> > establish a connection.
> >
> > I am able to connect to the VPN from a windows PC but I can't reach 
> > the
> > internal hosts on the network.
> > I suspect I have some conflicts over my internal subnet and various
> > pf rules.
> > If I remove the antispoof rule, I am able to ping the firewall on
> > its IP and
> > that of the pppx0 interface (192.168.7.128)
> > My internal em0 is on 192.168.7.0/24 which will overlap the pppx0
> > interface but I
> > am expecting my VPN users to appear on the same subnet. Is this
> > valid ?
> >
> > I can ping the connected client on its IP 192.168.7.118 from the 
> > firewall.
> > I can occasionally ping some other hosts on the internal network
> > but this
> > seems somewhat random and most of the time I can't reach any hosts.
> > (I'm running dhcpd on this box too if that makes a difference.)
> >
> > I've scanned the man pages for npppd and pf but I think I'm missing 
> > something
> > more fundamental. Could someone please take a quick look and see if 
> > there is
> > anything obvious.
> >
> > Thanks in advance.
> >
> > =
> > #cat /etc/npppd/npppd.conf
> > tunnel PPTP protocol pptp
> > ipcp IPCP {
> > pool-address 192.168.7.95-192.168.7.127
> > dns-servers 192.168.7.1 8.8.8.8
> > }
> > interface pppx0 address 192.168.7.128 ipcp IPCP
> > authentication LOCAL type local {
> > users-file "/etc/npppd/npppd-users"
> > }
> > bind tunnel from PPTP authenticated by LOCAL to pppx0
> >
> >
> > =
> > # ifconfig pppx0
> > pppx0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1400
> > description: jeremy
> > priority: 0
> > groups: pppx
> > inet 192.168.7.128 --> 192.168.7.118 netmask 0x
> >
> >
> > 
> > # cat /etc/pf.conf
> > #   $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
> > #
> > # See pf.conf(5) and /etc/examples/pf.conf
> >
> > # macros
> > int_if="em0"
> > ext_if="em1"
> >
> > tcp_services="{ 22, 113 }"
> > udp_services="{ 161 }"
> > mail_services="{ 25, 587, 993, 995 }"
> > web_services="{ 80, 443 }"
> > vpn_pptp="{ 1723 }"
> >
> > icmp_types="echoreq"
> >
> > web_server = "192.168.7.77"
> > mail_server = "192.168.7.77"
> >
> > # options
> > set block-policy return
> > set loginterface egress
> > set skip on lo
> >
> > # FTP Proxy rules
> > anchor "ftp-proxy/*"
> > pass in quick on $int_if inet proto tcp to any port ftp divert-to
> > 127.0.0.1 port 8021
> >
> > # match rules
> > match in all scrub (no-df random-id max-mss 1440)
> > match out on egress inet from $int_if:network to any nat-to 
> > (egress:0)
> >
> > # filter rules
> > block in log
> >
> > pass out quick
> > antispoof quick for { lo $int_if }
> >
> > # Allow access to services running on the firewall
> > pass in on egress inet proto tcp from any to (egress) port
> > $tcp_services flags S/SA keep state
> > pass in on egress inet proto udp from any to (egress) port 
> > $udp_services
> >
> > # VPN Rules
> > pass in quick inet proto gre all
> > pass in log on pppx
> > pass in quick on egress inet proto tcp from any to (egress) port 
> > $vpn_pptp
> >
> > # Redirect traffic to the interior servers
> > pass in on egress inet proto tcp to (egress) port $web_services
> > rdr-to $web_server synproxy state
> > pass in on egress inet proto tcp to (egress) port $mail_services
> > rdr-to $mail_server
> >
> > pass in inet proto icmp all icmp-type $icmp_types
> >
> > pass in on $int_if
> > ===  

npppd and pf

[Jeremy]

I'm adding more functionality to my firewall (OpenBSD 5.7) and have been 
trying to configure PPTP VPN access for my Windows users. I have got npppd 
running using the config below and can successfully authenticate and 
establish a connection.

I am able to connect to the VPN from a windows PC but I can't reach the 
internal hosts on the network.
I suspect I have some conflicts over my internal subnet and various pf rules. 
If I remove the antispoof rule, I am able to ping the firewall on its IP and
that of the pppx0 interface (192.168.7.128)
My internal em0 is on 192.168.7.0/24 which will overlap the pppx0 interface but 
I 
am expecting my VPN users to appear on the same subnet. Is this valid ?

I can ping the connected client on its IP 192.168.7.118 from the firewall.
I can occasionally ping some other hosts on the internal network but this
seems somewhat random and most of the time I can't reach any hosts. 
(I'm running dhcpd on this box too if that makes a difference.)

I've scanned the man pages for npppd and pf but I think I'm missing something
more fundamental. Could someone please take a quick look and see if there is 
anything obvious.

Thanks in advance.

=
#cat /etc/npppd/npppd.conf 
tunnel PPTP protocol pptp 
ipcp IPCP { 
pool-address 192.168.7.95-192.168.7.127 
dns-servers 192.168.7.1 8.8.8.8 
} 
interface pppx0 address 192.168.7.128 ipcp IPCP 
authentication LOCAL type local { 
users-file "/etc/npppd/npppd-users" 
}
bind tunnel from PPTP authenticated by LOCAL to pppx0


=
# ifconfig pppx0
pppx0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1400
description: jeremy
priority: 0
groups: pppx
inet 192.168.7.128 --> 192.168.7.118 netmask 0x



# cat /etc/pf.conf
#   $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

# macros
int_if="em0"
ext_if="em1"

tcp_services="{ 22, 113 }"
udp_services="{ 161 }"
mail_services="{ 25, 587, 993, 995 }"
web_services="{ 80, 443 }"
vpn_pptp="{ 1723 }"

icmp_types="echoreq"

web_server = "192.168.7.77"
mail_server = "192.168.7.77"

# options
set block-policy return
set loginterface egress
set skip on lo

# FTP Proxy rules
anchor "ftp-proxy/*"
pass in quick on $int_if inet proto tcp to any port ftp divert-to 127.0.0.1 
port 8021

# match rules
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from $int_if:network to any nat-to (egress:0)

# filter rules
block in log

pass out quick
antispoof quick for { lo $int_if }

# Allow access to services running on the firewall
pass in on egress inet proto tcp from any to (egress) port $tcp_services flags 
S/SA keep state
pass in on egress inet proto udp from any to (egress) port $udp_services

# VPN Rules
pass in quick inet proto gre all
pass in log on pppx
pass in quick on egress inet proto tcp from any to (egress) port $vpn_pptp

# Redirect traffic to the interior servers
pass in on egress inet proto tcp to (egress) port $web_services  rdr-to 
$web_server synproxy state
pass in on egress inet proto tcp to (egress) port $mail_services rdr-to 
$mail_server

pass in inet proto icmp all icmp-type $icmp_types

pass in on $int_if
===

Re: npppd and pf

[Imre Oolberg]

Hi!

I must apologize i didt read thru your text attentiatively but i 
believe it is because of arp. Although i am just an user of npppd i run 
it already for some time and i think it works very well. Here are my 
notes, see if there are some use for them, hope Google translates it, 
http://www.auul.pri.ee/wiki/L2TP/IPSec_serveri_kasutamine_operatsioonis%C3%BCsteemiga_OpenBSD#ARP_proxy



Imre


On 2015-11-13 01:18, Jeremy wrote:
I'm adding more functionality to my firewall (OpenBSD 5.7) and have 
been
trying to configure PPTP VPN access for my Windows users. I have got 
npppd

running using the config below and can successfully authenticate and
establish a connection.

I am able to connect to the VPN from a windows PC but I can't reach 
the

internal hosts on the network.
I suspect I have some conflicts over my internal subnet and various
pf rules.
If I remove the antispoof rule, I am able to ping the firewall on its 
IP and

that of the pppx0 interface (192.168.7.128)
My internal em0 is on 192.168.7.0/24 which will overlap the pppx0
interface but I
am expecting my VPN users to appear on the same subnet. Is this valid 
?


I can ping the connected client on its IP 192.168.7.118 from the 
firewall.
I can occasionally ping some other hosts on the internal network but 
this

seems somewhat random and most of the time I can't reach any hosts.
(I'm running dhcpd on this box too if that makes a difference.)

I've scanned the man pages for npppd and pf but I think I'm missing 
something
more fundamental. Could someone please take a quick look and see if 
there is

anything obvious.

Thanks in advance.

=
#cat /etc/npppd/npppd.conf
tunnel PPTP protocol pptp
ipcp IPCP {
pool-address 192.168.7.95-192.168.7.127
dns-servers 192.168.7.1 8.8.8.8
}
interface pppx0 address 192.168.7.128 ipcp IPCP
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
bind tunnel from PPTP authenticated by LOCAL to pppx0


=
# ifconfig pppx0
pppx0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1400
description: jeremy
priority: 0
groups: pppx
inet 192.168.7.128 --> 192.168.7.118 netmask 0x



# cat /etc/pf.conf
#   $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

# macros
int_if="em0"
ext_if="em1"

tcp_services="{ 22, 113 }"
udp_services="{ 161 }"
mail_services="{ 25, 587, 993, 995 }"
web_services="{ 80, 443 }"
vpn_pptp="{ 1723 }"

icmp_types="echoreq"

web_server = "192.168.7.77"
mail_server = "192.168.7.77"

# options
set block-policy return
set loginterface egress
set skip on lo

# FTP Proxy rules
anchor "ftp-proxy/*"
pass in quick on $int_if inet proto tcp to any port ftp divert-to
127.0.0.1 port 8021

# match rules
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from $int_if:network to any nat-to 
(egress:0)


# filter rules
block in log

pass out quick
antispoof quick for { lo $int_if }

# Allow access to services running on the firewall
pass in on egress inet proto tcp from any to (egress) port
$tcp_services flags S/SA keep state
pass in on egress inet proto udp from any to (egress) port 
$udp_services


# VPN Rules
pass in quick inet proto gre all
pass in log on pppx
pass in quick on egress inet proto tcp from any to (egress) port 
$vpn_pptp


# Redirect traffic to the interior servers
pass in on egress inet proto tcp to (egress) port $web_services
rdr-to $web_server synproxy state
pass in on egress inet proto tcp to (egress) port $mail_services
rdr-to $mail_server

pass in inet proto icmp all icmp-type $icmp_types

pass in on $int_if
===

Questions about l2tp/IPsec with npppd on OpenBSD

[Sevan / Venture37]

Hi,
I have a l2tp/IPsec VPN working on OpenBSD 5.6 with npppd. I have a
couple of questions about npppd
1) How come it's not possible to the address assigned to a CARP
interface on the OpenBSD host

Here's what's logged when I try to connect using the IP address
assigned to the CARP interface (if I switch to using the IP address
assigned to the physical interface, everything works ok)
isakmpd[27680]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got
AES_CBC, expected 3DES_CBC
last message repeated 3 times
npppd[1250]: l2tpd ctrl=15 logtype=Started RecvSCCRQ
from=$AnIPaddr:51863/udp tunnel_id=15/102 protocol=1.0 winsize=4
hostname=mycomputer vendor=(no vendorname) firm=
npppd[1250]: l2tpd ctrl=15 SendSCCRP
npppd[1250]: l2tpd ctrl=16 logtype=Started RecvSCCRQ
from=$AnIPaddr:51863/udp tunnel_id=16/102 protocol=1.0 winsize=4
hostname=mycomputer vendor=(no vendorname) firm=
npppd[1250]: l2tpd ctrl=16 SendSCCRP
npppd[1250]: l2tpd ctrl=17 logtype=Started RecvSCCRQ
from=$AnIPaddr:51863/udp tunnel_id=17/102 protocol=1.0 winsize=4
hostname=mycomputer vendor=(no vendorname) firm=
npppd[1250]: l2tpd ctrl=17 SendSCCRP
npppd[1250]: l2tpd ctrl=18 logtype=Started RecvSCCRQ
from=$AnIPaddr:51863/udp tunnel_id=18/102 protocol=1.0 winsize=4
hostname=mycomputer vendor=(no vendorname) firm=
npppd[1250]: l2tpd ctrl=18 SendSCCRP
npppd[1250]: l2tpd ctrl=19 logtype=Started RecvSCCRQ
from=$AnIPaddr:51863/udp tunnel_id=19/102 protocol=1.0 winsize=4
hostname=mycomputer vendor=(no vendorname) firm=
npppd[1250]: l2tpd ctrl=19 SendSCCRP
npppd[1250]: l2tpd ctrl=15 timeout waiting ack for ctrl packets.
npppd[1250]: l2tpd ctrl=15 logtype=Finished
npppd[1250]: l2tpd ctrl=16 timeout waiting ack for ctrl packets.
npppd[1250]: l2tpd ctrl=16 logtype=Finished
npppd[1250]: l2tpd ctrl=20 logtype=Started RecvSCCRQ
from=$AnIPaddr:51863/udp tunnel_id=20/102 protocol=1.0 winsize=4
hostname=mycomputer vendor=(no vendorname) firm=
npppd[1250]: l2tpd ctrl=20 SendSCCRP
npppd[1250]: l2tpd ctrl=17 timeout waiting ack for ctrl packets.
npppd[1250]: l2tpd ctrl=17 logtype=Finished
npppd[1250]: l2tpd ctrl=21 logtype=Started RecvSCCRQ
from=$AnIPaddr:51863/udp tunnel_id=21/102 protocol=1.0 winsize=4
hostname=mycomputer vendor=(no vendorname) firm=
npppd[1250]: l2tpd ctrl=21 SendSCCRP
npppd[1250]: l2tpd ctrl=18 timeout waiting ack for ctrl packets.
npppd[1250]: l2tpd ctrl=18 logtype=Finished
npppd[1250]: l2tpd ctrl=19 timeout waiting ack for ctrl packets.
npppd[1250]: l2tpd ctrl=19 logtype=Finished
npppd[1250]: l2tpd ctrl=20 timeout waiting ack for ctrl packets.
npppd[1250]: l2tpd ctrl=20 logtype=Finished
npppd[1250]: l2tpd ctrl=21 timeout waiting ack for ctrl packets.
npppd[1250]: l2tpd ctrl=21 logtype=Finished


2) Is it any way possible to push routes to client automatically upon
connecting successfully to the VPN?

I'm enquiring about these to remove as much burden from user / client
as possible. For reaching the VPN via the CARP  IP address so that
should one of the firewalls fail, the clients won't need to
reconfigure their clients (not because I was thinking of sasyncd like
behaviour somehow)


Sevan / Venture37

Re: L2TP using Npppd and IPsec

[Marko Cupać]

On Thu, 26 Mar 2015 13:21:10 -0400
Predrag Punosevac punoseva...@gmail.com wrote:

 Hi Misc,
 
 I need to provide secure access to a web application running on my
 servers to handful typical desktop users. I am thinking of requiring
 them to have L2TP/IPSec VPN tunnel before they can browse my
 application. HTTPS is not good enough due to the nature of the
 application. 
 
 Why L2TP? I am not a Windows uses but it seems that it should be
 trivial to setup client side
 
 https://www.hideipvpn.com/2010/03/howto-windows-7-ipsecl2tp-vpn-setup-tutorial/
 and avoid customer service requests, on another hand I am reading man
 pages for npppd and ipsec on 5.7 and Giovanni's slides from two years
 ago
 
 http://www.slideshare.net/GiovanniBechis/npppd-easy-vpn-with-openbsd
 
 for the talk he gave at BSDCan IIRC. I don't need to use RADIUS just a
 local authentication database. It is in the base and it seems very
 easy to configure. 
 
 Is anybody running similar setup in production? Any caveats? Any other
 advises before I take a plunge.
 
 Predrag
 
 P.S. I have quite a bit experience with OpenVPN server on OpenBSD
 but in my experience getting credentials to a Windows client is pain
 because a typical user knows only to double click and I don't know
 now to properly make Windows packages. 

This setup works for 2 years like charm:
https://www.mimar.rs/sysadmin/2013/npppd-novi-openbsd-pptp-server

PPTP though, not L2TP.
-- 
Marko Cupać
https://www.mimar.rs

Re: L2TP using Npppd and IPsec

[Brian S. Vangsgaard]

Hi,


for the talk he gave at BSDCan IIRC. I don't need to use RADIUS just a
local authentication database. It is in the base and it seems very 
easy

to configure.


It is.


Is anybody running similar setup in production? Any caveats? Any other
advises before I take a plunge.


Yes I am, with Windows, Mac, Linux and OpenBSD clients connecting.

Very easy to configure (linux being the exception :p).

You only need to change npppd.conf, npppd-users and ipsec.conf and you 
are in business.


I wrote an up-to-date guide on how to do it, let me know if you want a 
copy.


Caveats... yes.
I'm currently seeing issues with some clients (might be a client 
software issue) sending multiple connect requests.
The ip-address reserved for the client is being assigned to the first 
request, but it seems like the last request wins, but alas! no 
ip-address available (since it was assigned to the first request).


But then again, I have some Windows clients connected for more than 2 
weeks non-stop, before they disconnect (prob. a Windows update wanting 
to reboot ;) ).



--
bsv

Re: L2TP using Npppd and IPsec

[Predrag Punosevac]

Dain Bentley wrote:

 I'd love a copy!  Thanks
 

+1

 On Friday, March 27, 2015, Brian S. Vangsgaard b...@avalanic.dk wrote:
 
  Hi,
 
   for the talk he gave at BSDCan IIRC. I don't need to use RADIUS just
 a
  local authentication database. It is in the base and it seems very
 easy
  to configure.
 
 
  It is.
 
   Is anybody running similar setup in production? Any caveats? Any
 other
  advises before I take a plunge.
 
 
  Yes I am, with Windows, Mac, Linux and OpenBSD clients connecting.
 
  Very easy to configure (linux being the exception :p).
 
  You only need to change npppd.conf, npppd-users and ipsec.conf and you
 are
  in business.
 
  I wrote an up-to-date guide on how to do it, let me know if you want a
  copy.
 
  Caveats... yes.
  I'm currently seeing issues with some clients (might be a client
 software
  issue) sending multiple connect requests.

I also got a very useful answer off the list. I am just going to quote a
snipet 

[quote]
You???ll have problems with NAT-T and clients coming from the same
NAT-address. This problem is worked out currently.
[/quote]

I will post my configuration once when I am done but this topic seems to
beg for an updated undeadly article.

Thanks to everyone who responded to this thread!

PredraG

  The ip-address reserved for the client is being assigned to the first
  request, but it seems like the last request wins, but alas! no
 ip-address
  available (since it was assigned to the first request).
 
  But then again, I have some Windows clients connected for more than 2
  weeks non-stop, before they disconnect (prob. a Windows update wanting
 to
  reboot ;) ).
 
 
  --
  bsv

Re: L2TP using Npppd and IPsec

[Dain Bentley]

I'd love a copy!  Thanks

On Friday, March 27, 2015, Brian S. Vangsgaard b...@avalanic.dk wrote:

 Hi,

  for the talk he gave at BSDCan IIRC. I don't need to use RADIUS just a
 local authentication database. It is in the base and it seems very easy
 to configure.


 It is.

  Is anybody running similar setup in production? Any caveats? Any other
 advises before I take a plunge.


 Yes I am, with Windows, Mac, Linux and OpenBSD clients connecting.

 Very easy to configure (linux being the exception :p).

 You only need to change npppd.conf, npppd-users and ipsec.conf and you are
 in business.

 I wrote an up-to-date guide on how to do it, let me know if you want a
 copy.

 Caveats... yes.
 I'm currently seeing issues with some clients (might be a client software
 issue) sending multiple connect requests.
 The ip-address reserved for the client is being assigned to the first
 request, but it seems like the last request wins, but alas! no ip-address
 available (since it was assigned to the first request).

 But then again, I have some Windows clients connected for more than 2
 weeks non-stop, before they disconnect (prob. a Windows update wanting to
 reboot ;) ).


 --
 bsv

L2TP using Npppd and IPsec

[Predrag Punosevac]

Hi Misc,

I need to provide secure access to a web application running on my
servers to handful typical desktop users. I am thinking of requiring
them to have L2TP/IPSec VPN tunnel before they can browse my
application. HTTPS is not good enough due to the nature of the
application. 

Why L2TP? I am not a Windows uses but it seems that it should be trivial
to setup client side

https://www.hideipvpn.com/2010/03/howto-windows-7-ipsecl2tp-vpn-setup-tutorial/
and avoid customer service requests, on another hand I am reading man
pages for npppd and ipsec on 5.7 and Giovanni's slides from two years
ago

http://www.slideshare.net/GiovanniBechis/npppd-easy-vpn-with-openbsd

for the talk he gave at BSDCan IIRC. I don't need to use RADIUS just a
local authentication database. It is in the base and it seems very easy
to configure. 

Is anybody running similar setup in production? Any caveats? Any other
advises before I take a plunge.

Predrag

P.S. I have quite a bit experience with OpenVPN server on OpenBSD but  
in my experience getting credentials to a Windows client is pain because
a typical user knows only to double click and I don't know now to
properly make Windows packages. 

problem with configuration npppd/ipsec for road warrior

[Mika]

Hi,

i looking for a simple setup for npppd/ipsec for road warriors.
We have some clients (road warriors) with dynamic ip-adresses
connecting to a gateway by L2TP (macosx/ios/windows).

Client (road warriors) -- GATEWAY -- Internet

I just looking for a simple configuration for our openbsd5.4
gateway.

I read different howtos (like
http://de.slideshare.net/GiovanniBechis/npppd-easy-vpn-with-openbsd)
and the man page but i do not have a clue where is the problem
in my setting.

 cat /etc/npppd/npppd.conf
tunnel L2TP protocol l2tp
tunnel PPTP protocol pptp
ipcp IPCP {
pool-address 10.0.0.2-10.0.0.254
dns-servers 8.8.8.8
}
interface pppx0 address 10.0.0.1 ipcp IPCP
authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}
bind tunnel from L2TP authenticated by LOCAL to pppx0
bind tunnel from PPTP authenticated by LOCAL to pppx0



 cat /etc/npppd-users
mika:\
:password=.huuhstetst$oN:\
:framed-ip-address=10.0.0.101:



 cat /etc/ipsec.conf
public_ip = 1.7.15.1 #public ip of gateway
ike passive esp transport \
proto udp from $public_ip to any port 1701 \
main auth hmac-sha1 enc aes group modp2048 \
quick auth hmac-sha1 enc 3des \
psk 2h*GL]U?{i2KdneThezZnhezpbm46^kEUyjCoYvVpttM#jMkM(i



 sysctl | grep net.pipex.enable
net.pipex.enable=1



 cat /etc/pf.conf
pass quick proto { esp, ah } from any to any
pass in quick on egress proto  udp from any to any port {500, 4500,
1701} keep state
pass on enc0 from any to any keep state (if-bound)


Can you give me some hints.

best regards, Mika

two npppd users access different subnets behind openbsd firewall from their win7 workstations

[Imre Oolberg]

Hi!

I have used very basic npppd setup for some years and it works for me 
alright, thanks! (From Windows 7 workstations.)


It seems now i need to set up more complicated configuration. Say that 
firewall has three network interfaces


re0 - public internet
re1 - internal network one 192.168.2.0/24
re2 - internal network two 192.168.7.0/24

and one npppd user needs to access some hosts on 192.168.2.0/24 network 
and the ohter npppd user needs to access some hosts on 192.168.7.0/24 
network.


I tried out/thougth of several configuration options, it seems there is 
couple of ways to set it up, for example these two


1. since i can use several public ip addresses i could set up isakmpd 
listen on two and associate them with npppd.conf using something like 
this (about this i only thought, no real trial)


authentication LOCAL_1 type local {
users-file /etc/npppd/npppd-users-1
}

authentication LOCAL_2 type local {
users-file /etc/npppd/npppd-users-2
}

tunnel L2TP_1 protocol l2tp {
listen on x.x.x.x
mppe no
}

tunnel L2TP_2 protocol l2tp {
listen on x.x.x.y
mppe no
}

ipcp IPCP_1 {
pool-address 192.168.2.140-192.168.2.148 for dynamic
}

ipcp IPCP_2 {
pool-address 192.168.7.140-192.168.7.148 for dynamic
}

interface tun0 address 192.168.2.252 ipcp IPCP_1
interface tun1 address 192.168.7.252 ipcp IPCP_2

bind tunnel from L2TP_1 authenticated by LOCAL_1 to tun0
bind tunnel from L2TP_2 authenticated by LOCAL_2 to tun1

But i am not fan of this because i uses two public addresses and i'd 
rather use only one if possible.


2. using this configuration playing with pool-aadresses ja specifying 
specific addresses for two users (tried it and seems to work, but but 
edited my real configuration for better reading.)


authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}

tunnel L2TP_112 protocol l2tp {
listen on x.x.x.x
mppe no
}

ipcp IPCP {
pool-address 192.168.2.140-192.168.2.148 for dynamic
pool-address 192.168.7.140-192.168.7.148 for dynamic
}

interface pppx0 address 192.168.113.252 ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to pppx0

and /etc/npppd/npppd-users has

user-one:\
:password=password-one:\
:framed-ip-address=192.168.2.140:\
:framed-ip-network=255.255.255.0:

user-two:\
:password=password-two:\
:framed-ip-address=192.168.7.140:\
:framed-ip-network=255.255.255.0:


Which one do you suggest, should i go with the first or second 
configuration? Or maybe rather something else? And also i have these 
questions


1. for Windows 7 client it seems framed-ip-network parameter doesnt 
matter much, if framed-ip-address i C-class address it creates routing 
for /24, if it is A-class, it creates routing for /8; and there probably 
isnt much to do about it from npppd?


2. the 'interface' statement address (192.168.113.252) at least seems 
to accept anything (i believe it is not wise to use there openbsd's 
gateway address, still :) but what is recommended choice, should it be 
something from inside pool or from the same subnet as pool but outside 
pool and not used on network?


3. On what to base choice between pppx0 and tun0 interfaces? (is tun 
less efficent in some situations but being more mature is it less likely 
have crashes while trying out stupid configurations?)


4. Is it usually wise to put npppd user into the same network as the 
hosts she intends to access? (At least it seems to be good choice 
because on windows 7 side it just works this way; and still i can 
control which hosts she could access with pf). Also thought of putting 
npppd users into separate subnet (like something virtual build around 
vether0) but then it needs more work on windows 7 side to route users to 
what they really need access or have same rdr-to rules in packet filter.



Best regards,

Imre

npppd and vpn connections on the same network

[Christer Solskogen]

Hi!

Is it possible to setup  npppd so that the clients are on the same
network as the local network behind the router/firewall?

The only setups I've seen have the clients on a seperate network.

-- 
chs

Re: npppd and vpn connections on the same network

[YASUOKA Masahiko]

Yes.  But there is a bug with Windows clients.  See

  http://marc.info/?l=openbsd-miscm=141627574522930w=2

On Mon, 1 Dec 2014 12:42:41 +0100
Christer Solskogen christer.solsko...@gmail.com wrote:
 Hi!
 
 Is it possible to setup  npppd so that the clients are on the same
 network as the local network behind the router/firewall?
 
 The only setups I've seen have the clients on a seperate network.
 
 -- 
 chs

Re: npppd and vpn connections on the same network

[trondd]

I had this set up for an Android and an OSX client.  Ignore the networks
part and configure the connections for the end points.  I took the npppd
assigned IPs out of my DHCP range.

My problems, though:
Needed a specific npppd config for each client.  Username, assigned IP,
whatever else goes along with it.
I could only get one device talking at a time.  I think this was because
npppd had the pppx0 interface hard coded in the config and the second
device tried to create pppx1.

At that point, I abandoned the setup and planned to rework what I was doing
so I never got it 100% functional.

Tim.

Re: npppd and vpn connections on the same network

[YASUOKA Masahiko]

On Mon, 1 Dec 2014 11:38:31 -0500
trondd tro...@gmail.com wrote:
 I had this set up for an Android and an OSX client.  Ignore the networks
 part and configure the connections for the end points.  I took the npppd
 assigned IPs out of my DHCP range.

I think I misunderstood your question.  You want to make two clients
be connected in the same network by PPP links.  right?

 My problems, though:
 Needed a specific npppd config for each client.  Username, assigned IP,
 whatever else goes along with it.
 I could only get one device talking at a time.  I think this was because
 npppd had the pppx0 interface hard coded in the config and the second
 device tried to create pppx1.

Though it's not related with your question, npppd can use tun0,
instead of pppx, which handles multiple PPP sessions at the same
time.

--yasuoka

Re: npppd ipsec port 500 INVALID_MESSAGE_ID

[Швецов Михаил]

Thanks for your guide.
But my truble is:
1. isp lan - i get IP by dhclient(ip + default route + dns)
2. I have global ip, but this is not working. In ifconfig i cant see my 
global ip.(((


How setup /etc/ipsec.conf with dhclient with global IP???

04.10.2014 18:54, Zhi-Qiang Lei пишет:

On Oct 4, 2014, at 5:51 PM, mishve...@rambler.ru wrote:


I have OpenBSD 5.4 amd64. I install npppd and configure IPSec(l2tp +
password).

LAN 192.168.1.1/255.255.255.0

WAN(ISP NET; Connect by MAC ddress) 10.0.0.1/255.0.0.0

ISP GET ME GLOBAL IP SERVER1-Openbsd - 1.2.3.4

WIN 2003 SERVER2 IP - 9.8.7.6

WIN 2003 SERVER3 IP - 192.168.1.100

When server boot

# cat /etc/hostname.em0

inet 192.168.1.1 255.255.255.0

# ifconfig em0

em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500

priority: 0

media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)

status: active

inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255

# cat /etc/hostname.re0

dhcp

# ifconfig re0

re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500

priority: 0

groups: egress

media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)

status: active

inet 10.200.81.220 netmask 0xf000 broadcast 10.200.95.255

# route show

Routing tables

Internet:

Destination Gateway Flags Refs Use Mtu Prio Iface

default 10.200.80.1 UGS 6 1439 - 8 re0

10.200.80/20 link#2 UC 1 0 - 4 re0

10.200.80.1 28:6e:d4:6e:0a:e1 UHLc 1 0 - 4 re0

10.200.81.220 localhost UGS 0 0 33144 8 lo0

loopback localhost UGRS 0 0 33144 8 lo0

localhost localhost UH 2 35 33144 4 lo0

192.168.1/24 link#1 UC 2 0 - 4 em0

192.168.1.67 00:1a:13:18:b3:7c UHLc 0 0 - 4 em0

192.168.1.255 link#1 UHLc 3 43 - 4 em0

BASE-ADDRESS.MCAST localhost URS 0 0 33144 8 lo0

# cat /etc/resolv.conf

# Generated by re0 dhclient

search smilenet.ru

nameserver 10.0.1.24

nameserver 10.0.1.13

 From LAN i connect win server 192.168.1.100 to 192.168.1.1.

 From internet i can't connect win server 9.8.7.6 to 1.2.3.4

# cat /etc/ipsec.conf

ike passive esp transport proto udp from 192.168.1.1 to 192.168.1.100 port
1701
main auth hmac-sha1 enc 3des group modp2048 quick auth hmac-sha1 enc
3des
psk pass

ike passive esp transport proto udp from 10.200.81.220 to 9.8.7.6 port 1701
main
auth hmac-sha1 enc 3des group modp2048 quick auth hmac-sha1 enc 3des
psk
pass

ike passive esp transport proto udp from 1.2.3.4 to 9.8.7.6 port 1701 main
auth
hmac-sha1 enc 3des group modp2048 quick auth hmac-sha1 enc 3des psk
pass

# tail /var/log/daemon

isakmpd: message_recv: invalid message id

isakmpd: dropped message from 9.8.7.6 port 500 due to notification type
INVALID_MESSAGE_ID

Please help me connect server2 9.8.7.6 to 1.2.3.4


L2TP over IPsec on OpenBSD 5.5 is very easy for me, you may read my guide.

http://siegfried.github.io/unix/openbsd/vpn/ipsec/l2tp/2014/09/29/l2tp-over-ipsec-vpn-on-openbsd-5-5/

Re: npppd ipsec port 500 INVALID_MESSAGE_ID

[Zhi-Qiang Lei]

On Oct 4, 2014, at 5:51 PM, mishve...@rambler.ru wrote:

 I have OpenBSD 5.4 amd64. I install npppd and configure IPSec(l2tp +
 password).
 
 LAN 192.168.1.1/255.255.255.0
 
 WAN(ISP NET; Connect by MAC ddress) 10.0.0.1/255.0.0.0
 
 ISP GET ME GLOBAL IP SERVER1-Openbsd - 1.2.3.4
 
 WIN 2003 SERVER2 IP - 9.8.7.6
 
 WIN 2003 SERVER3 IP - 192.168.1.100
 
 When server boot
 
 # cat /etc/hostname.em0
 
 inet 192.168.1.1 255.255.255.0
 
 # ifconfig em0
 
 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 
 priority: 0
 
 media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
 
 status: active
 
 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
 
 # cat /etc/hostname.re0
 
 dhcp
 
 # ifconfig re0
 
 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 
 priority: 0
 
 groups: egress
 
 media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
 
 status: active
 
 inet 10.200.81.220 netmask 0xf000 broadcast 10.200.95.255
 
 # route show
 
 Routing tables
 
 Internet:
 
 Destination Gateway Flags Refs Use Mtu Prio Iface
 
 default 10.200.80.1 UGS 6 1439 - 8 re0
 
 10.200.80/20 link#2 UC 1 0 - 4 re0
 
 10.200.80.1 28:6e:d4:6e:0a:e1 UHLc 1 0 - 4 re0
 
 10.200.81.220 localhost UGS 0 0 33144 8 lo0
 
 loopback localhost UGRS 0 0 33144 8 lo0
 
 localhost localhost UH 2 35 33144 4 lo0
 
 192.168.1/24 link#1 UC 2 0 - 4 em0
 
 192.168.1.67 00:1a:13:18:b3:7c UHLc 0 0 - 4 em0
 
 192.168.1.255 link#1 UHLc 3 43 - 4 em0
 
 BASE-ADDRESS.MCAST localhost URS 0 0 33144 8 lo0
 
 # cat /etc/resolv.conf
 
 # Generated by re0 dhclient
 
 search smilenet.ru
 
 nameserver 10.0.1.24
 
 nameserver 10.0.1.13
 
 From LAN i connect win server 192.168.1.100 to 192.168.1.1.
 
 From internet i can't connect win server 9.8.7.6 to 1.2.3.4
 
 # cat /etc/ipsec.conf
 
 ike passive esp transport proto udp from 192.168.1.1 to 192.168.1.100 port
 1701
 main auth hmac-sha1 enc 3des group modp2048 quick auth hmac-sha1 enc
 3des
 psk pass
 
 ike passive esp transport proto udp from 10.200.81.220 to 9.8.7.6 port 1701
 main
 auth hmac-sha1 enc 3des group modp2048 quick auth hmac-sha1 enc 3des
 psk
 pass
 
 ike passive esp transport proto udp from 1.2.3.4 to 9.8.7.6 port 1701 main
 auth
 hmac-sha1 enc 3des group modp2048 quick auth hmac-sha1 enc 3des psk
 pass
 
 # tail /var/log/daemon
 
 isakmpd: message_recv: invalid message id
 
 isakmpd: dropped message from 9.8.7.6 port 500 due to notification type
 INVALID_MESSAGE_ID
 
 Please help me connect server2 9.8.7.6 to 1.2.3.4
 

L2TP over IPsec on OpenBSD 5.5 is very easy for me, you may read my guide.

http://siegfried.github.io/unix/openbsd/vpn/ipsec/l2tp/2014/09/29/l2tp-over-ipsec-vpn-on-openbsd-5-5/

Both PPTP and L2TP on npppd?

[Zhi-Qiang Lei]

I’m running a L2TP server using npppd on OpenBSD 5.5. Is it possible to run 
both PPTP and L2TP using npppd?
I tried to append a tunnel for pptp in default configuration then my L2TP could 
not work.

Best regards

Re: npppd Ipsec L2TP mtu issues.

[YASUOKA Masahiko]

On Mon, 15 Sep 2014 20:22:25 +0200
Jens Hansen jensh...@gmail.com wrote:
 Thank you for your response. I've investegated a little further, I see the
 following in /var/log/messages on the l2tp npppd server:
 l2tpd ctrl=1 timeout waiting ack for hello packets.
 l2tpd ctrl=1 call=28732 logtype=PPPUnbind
 
 The client reports that the tunnel went down.. does this indidacte an
 mss/mtu issue? I've tried scrub on pppx and to set mru i npppd.conf ...no
 luck...

That log message indicates L2TP keepalive is failed.  The client
didn't respond for long time.

--yasuoka

Re: npppd Ipsec L2TP mtu issues.

[Jens Hansen]

Thank you for your response. I've investegated a little further, I see the
following in /var/log/messages on the l2tp npppd server:
l2tpd ctrl=1 timeout waiting ack for hello packets.
l2tpd ctrl=1 call=28732 logtype=PPPUnbind

The client reports that the tunnel went down.. does this indidacte an
mss/mtu issue? I've tried scrub on pppx and to set mru i npppd.conf ...no
luck...


2014-09-14 5:06 GMT+02:00 YASUOKA Masahiko yasu...@yasuoka.net:

 Hi,

 On Sun, 7 Sep 2014 21:00:31 +0200
 Jens Hansen jensh...@gmail.com wrote:
  I can successfully connect to my opensbsd 5.5. isakmpd / npppd IPSEC L2TP
  vpn setup.
  But (not knowing too much about netwoking) i think i'm having a mtu
  problem. I can do low volume traffic fine, but transmitting larger files
  stalls. I've tried as per suggested by others around the  web the
  following.
  Added scrub on enc0 with an max mss of the pppx0 mtu.

 scrub should be used for the VPN tunnel internal packets.  They pass
 through on pppx0, pppx1,...pppxN.  (pppx creates a new clone for each
 VPN session.)  pppx interface group should be used.

   match on pppx scrub ( max-mss 1410 )

  Tried with and without tcp-mss-adjust set to yes in npppd.conf.

 At first, I think you should set mru not to fragment L2TP/IPsec
 packets on your network and it also is used to fragment properly for
 the packets inside the VPN links.  Also tcp-mss-adjust yes may be
 useful if you want to avoid the PMTU-D blackhole problem.

 --yasuoka

Re: npppd Ipsec L2TP mtu issues.

[YASUOKA Masahiko]

Hi,

On Sun, 7 Sep 2014 21:00:31 +0200
Jens Hansen jensh...@gmail.com wrote:
 I can successfully connect to my opensbsd 5.5. isakmpd / npppd IPSEC L2TP
 vpn setup.
 But (not knowing too much about netwoking) i think i'm having a mtu
 problem. I can do low volume traffic fine, but transmitting larger files
 stalls. I've tried as per suggested by others around the  web the
 following.
 Added scrub on enc0 with an max mss of the pppx0 mtu.

scrub should be used for the VPN tunnel internal packets.  They pass
through on pppx0, pppx1,...pppxN.  (pppx creates a new clone for each
VPN session.)  pppx interface group should be used.

  match on pppx scrub ( max-mss 1410 )

 Tried with and without tcp-mss-adjust set to yes in npppd.conf.

At first, I think you should set mru not to fragment L2TP/IPsec
packets on your network and it also is used to fragment properly for
the packets inside the VPN links.  Also tcp-mss-adjust yes may be
useful if you want to avoid the PMTU-D blackhole problem.

--yasuoka

npppd Ipsec L2TP mtu issues.

[Jens Hansen]

Hello list.

I can successfully connect to my opensbsd 5.5. isakmpd / npppd IPSEC L2TP
vpn setup.
But (not knowing too much about netwoking) i think i'm having a mtu
problem. I can do low volume traffic fine, but transmitting larger files
stalls. I've tried as per suggested by others around the  web the
following.
Added scrub on enc0 with an max mss of the pppx0 mtu.
Tried with and without tcp-mss-adjust set to yes in npppd.conf.

Does anyone have a working configuration of this setup, my client is
strongswan/xl2tpd on GNU/Linux debian 7.

npppd advice

[Scott McEachern]

Hi folks!  I'm wondering if any of you can save me some time before I 
really dive into this.


My current firewall is an old 486 running 5.3-stable/i386.  (dmesg 
below.)  It runs great, and I have no complaints.


I use userland ppp for the connection to my ISP (TekSavvy) for some 
features not available in kernel-mode ppp, such as MLPPP (to get around 
Bell's throttling of torrents).  My DSL modem is a Thompson Speedtouch 
516 running in bridge mode, so it does nothing, while my firewall 
handles all duties, from establishing the connection, to routing, to 
providing internal and external DNS.


I'd really like to upgrade to 5.6/-current, but for my connection to 
work, I either have to abandon some features (MLPPP) with kernel-mode 
pppoe, or go with something completely new, like npppd.


I've briefly read the man pages, but before I go investing too much 
time, and possibly going down the wrong path, I wanted to ask those of 
you with experience to point me in the correct direction.


These are my ppp.conf and ppp.linkup files:

 ppp.conf 

default:
 set log Phase Chat LCP IPCP CCP tun command
 set reconnect 3 3
 enable mssfixup
 enable ipv6cp

mlppp:
 set log Phase Chat LCP IPCP CCP tun command
 set mtu 1486
 set mrru 1485
 set speed sync
 set cd 5
 set dial
 set hangup
 set login
 set timeout 0
 set authname myusername@the.connection
 set authkey mypassword
 set server /var/run/ppp=tun%d 0177
 set mode ddial
 clone 1,2
 link deflink remove
 link 1,2 set mode ddial
 link 1 set device !/usr/sbin/pppoe -i xl0
 link 2 set device !/usr/sbin/pppoe -i xl0
 add! default HISADDR

 ppp.linkup 

MYADDR:
 !bg sh -c /sbin/pfctl -ef /etc/pf.conf
 !bg sh -c /etc/rc.d/postfix start
 !bg sh -c /usr/sbin/nsd -c /etc/nsd.conf-ext
 !bg sh -c /usr/local/sbin/unbound
 !bg sh -c /etc/rc.d/squid start
 !bg sh -c /usr/sbin/ftp-proxy -R 192.168.1.10 -p 21 -b 75.119.251.119

-

Basically, I need npppd to handle these duties.  I could be wrong, but 
from my brief reading, it seems to me that npppd cannot do those things, 
so I'm here asking those with more experience and knowledge, am I wrong 
and just haven't done enough homework, or am I looking at the wrong tool 
for the job.


Any advice would be appreciated.  I'm subscribed to the list, but please 
feel free to contact me privately.


Thank-you in advance,

Before I forget, here's the dmesg for the firewall, in case it may help:


OpenBSD 5.3-stable (GENERIC) #0: Sat May  3 04:21:01 EDT 2014
sc...@blackstaff.blackstaff.ca:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 2.80 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,CNXT-ID,xTPR,PERF

real mem  = 534769664 (509MB)
avail mem = 515043328 (491MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 01/18/05, BIOS32 rev. 0 @ 0xfd71c, 
SMBIOS rev. 2.31 @ 0xef7d0 (57 entries)

bios0: vendor IBM version 2AKT48AUS date 01/18/2005
bios0: IBM 818332F
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP TCPA APIC BOOT
acpi0: wakeup devices USB1(S3) USB2(S3) USB3(S3) USB4(S3) USBE(S3) 
SLOT(S5) KBC_(S3) COMA(S5) COMB(S5)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 132MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (SLOT)
acpiprt2 at acpi0: bus -1 (AGP_)
acpicpu0 at acpi0
acpitz0 at acpi0: critical temperature is 90 degC
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xa600 0xca800/0x1000 0xcb800/0x1000 
0xe/0x1!

pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82865G Host rev 0x02
vga1 at pci0 dev 2 function 0 Intel 82865G Video rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xf000, size 0x800
inteldrm0 at vga1: apic 1 int 16
drm0 at inteldrm0
uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: apic 1 
int 16
uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: apic 1 
int 19
uhci2 at pci0 dev 29 function 2 Intel 82801EB/ER USB rev 0x02: apic 1 
int 18
uhci3 at pci0 dev 29 function 3 Intel 82801EB/ER USB rev 0x02: apic 1 
int 16
ehci0 at pci0 dev 29 function 7 Intel 82801EB/ER USB2 rev 0x02: apic 1 
int 23

usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb0 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xc2
pci1 at ppb0 bus 3
fxp0 at pci1 dev 8 function 0 Intel PRO/100 VE rev 0x02, i82562: apic 
1 int 20, address 00:0d:60:91:5d:a4

inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
skc0 at pci1 dev 9 function 0 D-Link DGE-530T B1 rev 0x11, Yukon Lite 
(0x9): apic 1 int 21

sk0 at skc0 port A: address 00

Re: npppd advice

[Stuart Henderson]

On 2014-08-03, Scott McEachern sc...@blackstaff.ca wrote:
 I'd really like to upgrade to 5.6/-current, but for my connection to 
 work, I either have to abandon some features (MLPPP) with kernel-mode 
 pppoe, or go with something completely new, like npppd.

Not currently possible, npppd is server-side only and doesn't do
MLPPP (or IPV6CP).

Re: npppd advice

[Scott McEachern]

On 08/03/14 14:42, Stuart Henderson wrote:

On 2014-08-03, Scott McEachern sc...@blackstaff.ca wrote:

I'd really like to upgrade to 5.6/-current, but for my connection to
work, I either have to abandon some features (MLPPP) with kernel-mode
pppoe, or go with something completely new, like npppd.

Not currently possible, npppd is server-side only and doesn't do
MLPPP (or IPV6CP).



That's what I was afraid of.

Theo, is there any chance of putting userland ppp back in?  I'm sure I'm 
not the only person out there that needs that specific functionality to 
stay online.


I know you've said before that the code is horrible, there are too many 
pppoe options, but there are some people -- like me -- that are stuck 
without it.  We just don't have a viable option.


Please consider putting it back in.  People like me still use and need 
it, and it's no hardship on your end.


Please?

--
Scott McEachern

http://www.blackstaff.ca

The reasonable man adapts himself to the world: the unreasonable one persists in 
trying to adapt the world to himself. Therefore all progress depends on the unreasonable 
man. -- George Bernard Shaw

Re: npppd advice

[Theo de Raadt]

 On 08/03/14 14:42, Stuart Henderson wrote:
  On 2014-08-03, Scott McEachern sc...@blackstaff.ca wrote:
  I'd really like to upgrade to 5.6/-current, but for my connection to
  work, I either have to abandon some features (MLPPP) with kernel-mode
  pppoe, or go with something completely new, like npppd.
  Not currently possible, npppd is server-side only and doesn't do
  MLPPP (or IPV6CP).
 
 
 That's what I was afraid of.
 
 Theo, is there any chance of putting userland ppp back in?  I'm sure I'm 
 not the only person out there that needs that specific functionality to 
 stay online.

No.

The nppp stack should be improved.

 I know you've said before that the code is horrible, there are too many 
 pppoe options, but there are some people -- like me -- that are stuck 
 without it.  We just don't have a viable option.

That is unfortunate.

 Please consider putting it back in.  People like me still use and need 
 it, and it's no hardship on your end.
 
 Please?

No.

This is 2014.  Buy a device which does plain pppoe (trivial), or
convince the maintainers of the other ppp code bases in the tree to
support the missing parts.  I recognize this second part is a
difficulty.

There is a certain point in time at which general purpose operating
system means we draw the line at insane stuff which is complete
unmaintained and not neccessary.


Finally, you did throw in a line about the code being horrible.
You misunderstand.  It isn't that it is horrible -- IT IS FULL OF
HOLES.

It would be deeply irresponsible to put it back into the tree.  It is
deeply irresponsible that it stayed in the tree as long as it did.

IPSec w/ and w/o npppd for road warriors

[Zé Loff]

I've managed to setup tunnels (X.509 auth) between the office network an
OpenBSD machine (both with dynamic IPs) by using:

/etc/ipsec.conf on the DMZ/LAN firewall:

ike passive esp from 10.17.18.0/24 to any \
srcid vpn.foobar.org dstid vpn-client.foobar.org


I also managed to use npppd for L2TP (iOS and OS X clients) by using:

  ike passive esp transport proto udp \
from pppoe0 (10.17.19.0/24) to any port 1701 \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc aes group none \
psk ...

on the office gateway's /etc/ipsec.conf (and the appropriate nppp.conf,
of course).

Again, I've managed to get both setups working perfectly, separately.


My question is: (how) can I setup both X.509 IPSec and L2TP/npppd
simultaneously? I can't have both entries on the same ipsec.conf file
since they both refer to the 'default peer', so I guess I should either
run two instances of isakmpd (different ports, different fifo), which
sounds messy, or use relayd, of which my current knowledge amounts to
the first paragraph of the man page.

Does anyone have such a setup?

TIA
Zé

Re: npppd security

[YASUOKA Masahiko]

On Wed, 28 May 2014 22:04:34 +0300
Mike Jackson m...@netauth.com wrote:
  If npppd tunnel listen address can't be changed and l2tp-ipsec-require
  isn't supported,

You can change the listen address by npppd.conf:

  tunnel L2TP protocol l2tp {
listen on xxx.xxx.xxx.xxx
  }

l2tp-ipsec-require isn't supported yet, but we can refuse L2TP without
IPsec packerts by pf.

  then how is one supposed to secure the npppd service from
  dictionary attacks from the entire world?

When RADIUS is used for authentication, the RADIUS authentication
server may provide something against the dictonary attacks.

Also if npppd supports EAP-RADIUS in the future, some authentication
methods including EAP-TLS (certificate authentication) will become
available.

  Ideal would be to do certificate authentication to isakmpd and then
  password authentication to npppd that is running on an internal
  IP. Is this ever going to be possible?

Sorry, I'm not sure.

--yasuoka

Re: npppd security

[Mike Jackson]

Quoting YASUOKA Masahiko yasu...@yasuoka.net:



You can change the listen address by npppd.conf:

  tunnel L2TP protocol l2tp {
listen on xxx.xxx.xxx.xxx
  }


So npppd.conf(5) is not accurate (states that changing listener  
address is not currently supported):


--
BUGS
 The current version of npppd(8) does not support adding or removing
 tunnel settings or changing listener settings (listen address, port and
 l2tp-ipsec-require).
--



l2tp-ipsec-require isn't supported yet, but we can refuse L2TP without
IPsec packerts by pf.


So, would this be the best way to do it, then, assuming a default block rule:

pass in quick on enc0 proto udp from any to any port 1701 keep state




Thanks,
Mike

Re: pipex and npppd syslog

[Stefan Sieg]

On 27.05.2014 23:13, Stefan Sieg wrote:
 On 27.05.2014 20:03, Marko Cupać wrote:
  Hi,
  
  I have relatively busy npppd pptp server, and it logs a lot of output
  into /var/log/messages.
  
  How can I move npppd and pipex log messages into separate file?
  
  Thank you in advance,
  -- 
  Marko Cupać
  
 
 Hi,
 
 add this to the top of your syslog.conf 
 
 !!npppd
 *.*   /var/log/npppd
 !*
 
 after touch /var/log/npppd and restarting syslogd you will get what you
 want.
 
 Greetings
 Stefan

I forgot misc@ and to mention to add an entry to /etc/newsyslog.conf

Greetings
Stefan

Re: pipex and npppd syslog

[YASUOKA Masahiko]

On Tue, 27 May 2014 20:03:54 +0200
Marko Cupać marko.cu...@mimar.rs wrote:
 I have relatively busy npppd pptp server, and it logs a lot of output
 into /var/log/messages.
 
 How can I move npppd and pipex log messages into separate file?

As far as syslog.conf(5), you can use !!npppd for that purpose.

Currently npppd or pipex itself doesn't have any configuration which
controls the log output.

npppd should be more silence?  I myself feel the pipex log in dmesg is
noisy.  But almost all logs of /var/log/daemon are useful for me to
debug the problem.

--yasuoka

npppd security

[Mike Jackson]

Hi,

I'm running 5.5 release, all patches applied.

I have a few questions about npppd running in combination with isakmpd.

 If npppd tunnel listen address can't be changed and  
l2tp-ipsec-require isn't supported, then how is one supposed to secure  
the npppd service from dictionary attacks from the entire world? Ideal  
would be to do certificate authentication to isakmpd and then password  
authentication to npppd that is running on an internal IP. Is this  
ever going to be possible?


Thanks,
Mike

pipex and npppd syslog

[Marko Cupać]

Hi,

I have relatively busy npppd pptp server, and it logs a lot of output
into /var/log/messages.

How can I move npppd and pipex log messages into separate file?

Thank you in advance,
-- 
Marko Cupać

Re: npppd with two pppx interfaces causes kernel panic

[Jonathan Gray]

On Thu, Mar 20, 2014 at 01:43:59PM +0900, YASUOKA Masahiko wrote:
 On Wed, 19 Mar 2014 21:05:35 -0700
 Paul B. Henson hen...@acm.org wrote:
  On Thu, Mar 20, 2014 at 10:22:51AM +0900, YASUOKA Masahiko wrote:
  pppx will be fixed.
  
  Great :). This is a known bug then?
 
 It's new for me.  I had not even try MAKEDEV pppx1 yet.

The following diff prevents the panic here:

Index: if_pppx.c
===
RCS file: /cvs/src/sys/net/if_pppx.c,v
retrieving revision 1.26
diff -u -p -r1.26 if_pppx.c
--- if_pppx.c   19 Oct 2013 14:46:30 -  1.26
+++ if_pppx.c   20 Mar 2014 10:21:04 -
@@ -590,7 +590,8 @@ pppxclose(dev_t dev, int flags, int mode
 
rw_enter_write(pppx_devs_lk);
 
-   pxd = pppx_dev_lookup(dev);
+   if ((pxd = pppx_dev_lookup(dev)) == NULL)
+   return (ENXIO);
 
/* XXX */
while ((pxi = LIST_FIRST(pxd-pxd_pxis)))

Re: npppd with two pppx interfaces causes kernel panic

[Paul B. Henson]

 From: YASUOKA Masahiko
 Sent: Wednesday, March 19, 2014 9:44 PM

  Should I just keep an eye on the changelog for mention of pppx
  changes to tell when it's safe to try again?
 
 Sorry I cannot understand the point of this question.

Sorry to be confusing; I switched to tun because of this bug, but I would
prefer to use pppx once it has been fixed. The question was regarding how to
know when the bug has been fixed. As I am unaware of any publicly accessible
bug tracking system for openbsd, I was thinking of just watching the change
log (http://www.openbsd.org/plus.html) for any mention of pppx.

Thanks.

Re: npppd with two pppx interfaces causes kernel panic

[Paul B. Henson]

 From: Jonathan Gray
 Sent: Thursday, March 20, 2014 3:36 AM

 The following diff prevents the panic here:

Interesting, given the XXX, it seems somebody was already a little
suspicious of this section :).

From a cursory glance, it seems pppx_dev_lookup is supposed to return data
about a particular instance if it is in use, or NULL otherwise. So it seems
for some reason pppxclose is being called for device that isn't open? While
avoiding a panic is a plus :), it seems there is perhaps a logic error
somewhere else resulting in an attempt to close a device that isn't open?
 
 Index: if_pppx.c
 ==
 =
 RCS file: /cvs/src/sys/net/if_pppx.c,v
 retrieving revision 1.26
 diff -u -p -r1.26 if_pppx.c
 --- if_pppx.c 19 Oct 2013 14:46:30 -  1.26
 +++ if_pppx.c 20 Mar 2014 10:21:04 -
 @@ -590,7 +590,8 @@ pppxclose(dev_t dev, int flags, int mode
 
   rw_enter_write(pppx_devs_lk);
 
 - pxd = pppx_dev_lookup(dev);
 + if ((pxd = pppx_dev_lookup(dev)) == NULL)
 + return (ENXIO);
 
   /* XXX */
   while ((pxi = LIST_FIRST(pxd-pxd_pxis)))

npppd can't open /dev/pppx1

[Paul B. Henson]

I set up an L2TP VPN with npppd recently using pppx, and other than some
routing issues with ospfd it works great. I'm trying to add a second VPN
connection, but that doesn't seem to work using pppx.

With this config:

interface pppx0 address 10.128.120.1 ipcp IPCP_admin
interface pppx1 address 10.128.120.129 ipcp IPCP

bind tunnel from L2TP_ipv4 authenticated by LOCAL_admin to pppx0
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx1

npppd won't start:

# npppd -d
2014-03-19 14:08:27:NOTICE: Starting npppd pid=28792 version=5.0.0
2014-03-19 14:08:27:WARNING: pptpd GRE protocol not allowed
2014-03-19 14:08:27:NOTICE: Load configuration
from='/etc/npppd/npppd.conf' successfully.
2014-03-19 14:08:27:INFO: pppx0 Started pppx
2014-03-19 14:08:27:ERR: pppx1 open(/dev/pppx1) failed: No such file or 
directory

If I switch to tun instead of pppx:

interface tun0 address 10.128.120.1 ipcp IPCP_admin
interface tun1 address 10.128.120.129 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL_admin to tun0
bind tunnel from L2TP_ipv4 authenticated by LOCAL to tun1

it works fine:

# npppd -d
2014-03-19 14:14:28:NOTICE: Starting npppd pid=3355 version=5.0.0
2014-03-19 14:14:28:WARNING: pptpd GRE protocol not allowed
2014-03-19 14:14:28:NOTICE: Load configuration
from='/etc/npppd/npppd.conf' successfully.
2014-03-19 14:14:28:INFO: tun0 Started ip4addr=10.128.120.1
2014-03-19 14:14:28:INFO: tun1 Started ip4addr=10.128.120.129

Is there any way to make two VPN connections work with pppx, or are you
stuck with tun for that scenario?

Thanks...

Re: npppd can't open /dev/pppx1

[Paul B. Henson]

D'oh, I finally realized I needed to go to /dev and MAKEDEV pppx1 8-/.

Now it's working fine. I had thought pppx was one of those magic
clonable devices that you didn't need to explicitly create, I guess I
was mistaken. When I was testing the vpn, there were pppx1 and pppx2
interfaces that showed up in ifconfig for the clients, which I guess led
me to believe I didn't have to do anything special to use pppx1 in the
npppd config.

Thanks, and sorry for the noise.


On Wed, Mar 19, 2014 at 02:29:35PM -0700, Paul B. Henson wrote:
 I set up an L2TP VPN with npppd recently using pppx, and other than some
 routing issues with ospfd it works great. I'm trying to add a second VPN
 connection, but that doesn't seem to work using pppx.
 
 With this config:
 
 interface pppx0 address 10.128.120.1 ipcp IPCP_admin
 interface pppx1 address 10.128.120.129 ipcp IPCP
 
 bind tunnel from L2TP_ipv4 authenticated by LOCAL_admin to pppx0
 bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx1
 
 npppd won't start:
 
 # npppd -d
 2014-03-19 14:08:27:NOTICE: Starting npppd pid=28792 version=5.0.0
 2014-03-19 14:08:27:WARNING: pptpd GRE protocol not allowed
 2014-03-19 14:08:27:NOTICE: Load configuration
 from='/etc/npppd/npppd.conf' successfully.
 2014-03-19 14:08:27:INFO: pppx0 Started pppx
 2014-03-19 14:08:27:ERR: pppx1 open(/dev/pppx1) failed: No such file or 
 directory
 
 If I switch to tun instead of pppx:
 
 interface tun0 address 10.128.120.1 ipcp IPCP_admin
 interface tun1 address 10.128.120.129 ipcp IPCP
 bind tunnel from L2TP_ipv4 authenticated by LOCAL_admin to tun0
 bind tunnel from L2TP_ipv4 authenticated by LOCAL to tun1
 
 it works fine:
 
 # npppd -d
 2014-03-19 14:14:28:NOTICE: Starting npppd pid=3355 version=5.0.0
 2014-03-19 14:14:28:WARNING: pptpd GRE protocol not allowed
 2014-03-19 14:14:28:NOTICE: Load configuration
 from='/etc/npppd/npppd.conf' successfully.
 2014-03-19 14:14:28:INFO: tun0 Started ip4addr=10.128.120.1
 2014-03-19 14:14:28:INFO: tun1 Started ip4addr=10.128.120.129
 
 Is there any way to make two VPN connections work with pppx, or are you
 stuck with tun for that scenario?
 
 Thanks...

npppd with two pppx interfaces causes kernel panic

[Paul B. Henson]

After successfully setting up an L2TP VPN with npppd and pppx, I tried
to add a second VPN subnet with a different authentication base. I was
working remotely, and after starting npppd in debug mode:

bash-4.2# npppd -d
2014-03-19 14:41:50:NOTICE: Starting npppd pid=32407 version=5.0.0
2014-03-19 14:41:50:WARNING: pptpd GRE protocol not allowed
2014-03-19 14:41:51:NOTICE: Load configuration
from='/etc/npppd/npppd.conf' successfully.
2014-03-19 14:41:51:INFO: pppx0 Started pppx
2014-03-19 14:41:51:INFO: pppx1 Started pppx
2014-03-19 14:41:51:INFO: Listening /var/run/npppd_ctl (npppd_ctl)
2014-03-19 14:41:51:INFO: ipcp=IPCP_admin pool
dyn_pool=[10.128.120.0/25] pool=[10.128.120.0/25]
2014-03-19 14:41:51:INFO: ipcp=IPCP pool dyn_pool=[10.128.120.128/25]
pool=[10.128.120.128/25]
2014-03-19 14:41:51:INFO: Loading pool config successfully.

the box stopped responding :(. When I got on site, it was frozen and
nonresponsive. I rebooted, and on the way back up it panic'd when
starting npppd:

starting early daemons: syslogd pflogd named ntpd isakmpd npppd.
uvm_fault(0xfe812f620e00, 0x30, 0, 1) - e
fatal page fault in supervisor mode
trap type 6 code 0 rip 81385b40 cs 8 rflags 10257 cr2  30 cpl 0
rsp 8000221fdd38
panic: trap type 6, code=0, pc=81385b40
Starting stack trace...
panic() at panic+0xf5
trap() at trap+0x7f1
--- trap (number 6) ---
mtx_enter() at mtx_enter
VOP_KQFILTER() at VOP_KQFILTER+0x2b
kqueue_register() at kqueue_register+0x332
sys_kevent() at sys_kevent+0x115
syscall() at syscall+0x249
--- syscall (number 270) ---
end of kernel
end trace frame: 0x11be0a5e, count: 250
0x11be006eca6a:

It then said Syncing disks and sat there for 30 minutes, at which
point I gave up, booted in single user, and disabled npppd.
Unfortunately I don't have a serial console logger at the moment, so
while I assume it did the same panic when I was working remotely I don't
have logs for it. This is a 5.4 box with a generic kernel, other than
using config -e to enable ipmi and change the irq for com2.

Any thoughts on this? Here is the npppd config that causes it to blow
up:

authentication LOCAL_admin type local {
users-file /etc/npppd/npppd-users
username-suffix @admin
}
authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}

tunnel L2TP_ipv4 protocol l2tp {
listen on 96.251.22.154
# l2tp-require-ipsec yes # buggy, doesn't work currently
}

ipcp IPCP_admin {
pool-address 10.128.120.0/25
dns-servers 10.128.0.4
allow-user-selected-address no
}
ipcp IPCP {
pool-address 10.128.120.128/25
dns-servers 10.128.0.4
allow-user-selected-address no
}

interface pppx0 address 10.128.120.1 ipcp IPCP_admin
interface pppx1 address 10.128.120.129 ipcp IPCP

bind tunnel from L2TP_ipv4 authenticated by LOCAL_admin to pppx0
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx1