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 <yasu...@openbsd.org> 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 <r...@int.pl> 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 <yasu...@openbsd.org> wrote:
> >
> >> Hi,
> >>
> >> On Wed, 6 Jan 2021 21:33:49 +0100
> >> Radek <r...@int.pl> 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 <r...@int.pl> 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=100000000 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=Microsoft firm=0601
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 SendSCCRP
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 RecvSCCN
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 SendZLB
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 RecvZLB
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 call=11788
> >> RecvICRQ
> >> > session_id=1
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 call=11788
> >> SendICRP
> >> > session_id=11788
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 call=11788
> >> RecvICCN
> >> > session_id=1 calling_number= tx_conn_speed=100000000 framing=sync
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 call=11788
> >> > logtype=PPPBind ppp=1
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=base
> >> > logtype=Started tunnel=L2TP(A.B.C.D:1701)
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 call=11788
> >> SendZLB
> >> > Jan 6 20:53:44 fw-u npppd[82720]: l2tpd ctrl=2 RecvZLB
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=lcp
> >> > logtype=Opened mru=1360/1400 auth=MS-CHAP-V2
> >> magic=9699e1a6/244d01eb
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=lcp RecvId
> >> > magic=244d01eb text=MSRASV5.20
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=lcp RecvId
> >> > magic=244d01eb text=MSRAS-0-X
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=lcp RecvId
> >> > magic=244d01eb text=.*.(...N.....Z68
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=chap
> >> > proto=mschap_v2 logtype=Success username="rdk-test" realm=LOCAL
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=mppe mismatch
> >> > our=40bit,128bit,56bit,stateless peer=stateless
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=ipcp IP Address
> >> > peer=0.0.0.0 our=10.109.4.11.
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=ipcp
> >> > logtype=Opened ip=10.109.4.11 assignType=dynamic
> >> > 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
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=mppe
> >> > logtype=Opened our=128bit,stateless peer=128bit,stateless
> >> > Jan 6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=base Using
> >> > pipex=yes
> >> >
> >> > --
> >> > Radek
> >> >
> >>
> >
> >
> > --
> > Radek
> >
--
Radek
