Re: ksh: expr 2147483648 / 2 = -1073741824 expected behavior or bug?
Not even when started with --posix, or with the env var POSIXLY_CORRECT. perhaps bash needs a --really-really-posix flag... 8-/ 2014-02-25 8:44 GMT+01:00 Dennis Davis dennisdavis+openbsd-m...@fastmail.fm : On Tue, 25 Feb 2014, Ingo Schwarze wrote: From: Ingo Schwarze schwa...@usta.de To: Fabian Raetz fabian.ra...@gmail.com Cc: misc@openbsd.org Date: Tue, 25 Feb 2014 01:00:49 Subject: Re: ksh: expr 2147483648 / 2 = -1073741824 expected behavior or bug? ... so i tried expr 2147483647 / 2 which returns 1073741824 while expr 2147483648 / 2 returns -1073741824 ksh(1) states that expr does Integer arithmetic. So is this the expected behaviour or a bug? How strange, six replies but nobody answered your question... The above behaviour is required by POSIX: ... Possibly worth muddying the waters slightly by noting the bash shell on my old i386 box gets the sum right: poulidor $ cat /tmp/t.sh #!/usr/local/bin/bash echo $((2147483647/2)) echo $((2147483648/2)) poulidor $ /tmp/t.sh 1073741823 1073741824 poulidor $ /usr/local/bin/bash --version GNU bash, version 4.2.42(1)-release (i386-unknown-openbsd5.3) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Seems like bash is not adhering to the POSIX standard :-) -- Dennis Davis dennisda...@fastmail.fm -- May the most significant bit of your life be positive.
Content filtering in smtpd(8)
Hi, looking at GSOC2014 OpenBSD Foundation's idea list, I found a reference to some Perl and Python bindings to smtpd's own content filtering framework. Is this content filtering api documented anywhere? I found no mention in smtpd.conf(5) or smtpd(8) man pages. I'd like to know whether this api or these perl bindings are intended to be usable by larger audience, because I have to rewrite outdated and horrible code written for sendmail (it uses sendmail's milter interface): it would be nice to start over with smtpd. I really appreciate any help you can provide. -- f. Non sono pigro...ma non ne ho voglia :D :D
Re: Content filtering in smtpd(8)
On Wed, Feb 26, 2014 at 11:16:40AM +0100, Francesco Toscan wrote: Hi, Hi, looking at GSOC2014 OpenBSD Foundation's idea list, I found a reference to some Perl and Python bindings to smtpd's own content filtering framework. yup, experimental but fonctional stuff, not usable by !developers yet ;-) Is this content filtering api documented anywhere? I found no mention in smtpd.conf(5) or smtpd(8) man pages. nope because we're still stabilizing the API, there are still a few shortcomings but we should be done by 5.6 I'd like to know whether this api or these perl bindings are intended to be usable by larger audience, because I have to rewrite outdated and horrible code written for sendmail (it uses sendmail's milter interface): it would be nice to start over with smtpd. the API is supposed to be usable by a larger audience very soon (we're talking in matter of weeks), the python/perl bindings are just regular filters, they are not part of smtpd itself, they rely on the C API so they are as usable as the API itself ;-) If you are interested in filters development, ping me off-list and I can tell you where to get started. -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: Content filtering in smtpd(8)
Hi Gilles, On Wed, Feb 26, 2014 at 11:37:47AM +0100, Gilles Chehade wrote: On Wed, Feb 26, 2014 at 11:16:40AM +0100, Francesco Toscan wrote: Is this content filtering api documented anywhere? I found no mention in smtpd.conf(5) or smtpd(8) man pages. nope because we're still stabilizing the API, there are still a few shortcomings but we should be done by 5.6 Ah ok, can't wait for 5.6 :-) the API is supposed to be usable by a larger audience very soon (we're talking in matter of weeks), the python/perl bindings are just regular filters, they are not part of smtpd itself, they rely on the C API so they are as usable as the API itself ;-) If you are interested in filters development, ping me off-list and I can tell you where to get started. Thank you very much Gilles, continuing off-list. -- f. Non sono pigro...ma non ne ho voglia :D :D
Local routing issue when iked running
Hi @misc, I am facing an issue between two boxes (box1 and box2) connected through an IPsec tunnel. They are both on the same subnet and both listen on port 22 (sshd running) When the ipsec tunnel is down and encap routes are flushed on both boxes (ipsecctl -F), performing a telnet ip_of_box1 22 on box1 works fine. Same on box2. However, when the ipsec tunnel is up, performing the same telnet command on box1 will just time out. Same timeout on box2. Reaching box1 from box2 and vice versa is not a problem. I am not sure to understand why I can't reach the local IP address when the tunnel is up. Any hint would be much appreciated, Below some config / output (both are running 5.5 current i386 GENERIC.MP but I did reproduce the problem with exactly the same config on 5.4 release GENERIC.MP i386 on both boxes) and the two last commands showing the time out when performing the telnet. Cheers, Josh box1:~# cat /etc/hostname.em0 dhcp box2:~# cat /etc/hostname.em0 dhcp box1:~# ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 08:00:27:db:76:6f priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::a00:27ff:fedb:766f%em0 prefixlen 64 scopeid 0x1 inet 192.168.150.16 netmask 0xff00 broadcast 192.168.150.255 box2:~# ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 08:00:27:a3:85:3a priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::a00:27ff:fea3:853a%em0 prefixlen 64 scopeid 0x1 inet 192.168.150.13 netmask 0xff00 broadcast 192.168.150.255 box1:~# pfctl -d pfctl: pf not enabled box2:~# pfctl -d pfctl: pf not enabled box1:~# netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default192.168.150.254UGS4 843047 - 8 em0 127/8 127.0.0.1 UGRS 00 33192 8 lo0 127.0.0.1 127.0.0.1 UH 1 33 33192 4 lo0 192.168.150/24 link#1 UC 30 - 4 em0 192.168.150.1 10:dd:b1:99:a0:d7 UHLc 142048 - 4 em0 192.168.150.13 08:00:27:a3:85:3a UHLc 0 14 - 4 em0 192.168.150.25400:00:24:ce:84:bc UHLc 1 393 - 4 em0 224/4 127.0.0.1 URS00 33192 8 lo0 box2:~# netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default192.168.150.254UGS4 909362 - 8 em0 127/8 127.0.0.1 UGRS 00 33192 8 lo0 127.0.0.1 127.0.0.1 UH 1 115 33192 4 lo0 192.168.150/24 link#1 UC 30 - 4 em0 192.168.150.13 08:00:27:a3:85:3a UHLc 0 18 - 4 lo0 192.168.150.16 08:00:27:db:76:6f UHLc 0 22 - 4 em0 192.168.150.25400:00:24:ce:84:bc UHLc 1 1005 - 4 em0 224/4 127.0.0.1 URS00 33192 8 lo0 box1:~# cat /etc/iked.conf ikev2 passive esp from 192.168.150.16 to 192.168.150.13 peer 192.168.150.13 psk tesT box2:~# cat /etc/iked.conf ikev2 active esp from 192.168.150.13 to 192.168.150.16 peer 192.168.150.16 psk tesT box1:~# ipsecctl -sa FLOWS: No flows SAD: No entries box2:~# ipsecctl -sa FLOWS: No flows SAD: No entries box1:~# telnet 192.168.150.16 22 Trying 192.168.150.16... Connected to 192.168.150.16. Escape character is '^]'. SSH-2.0-OpenSSH_6.5 ^C Connection closed by foreign host. box2:~# telnet 192.168.150.13 22 Trying 192.168.150.13... Connected to 192.168.150.13. Escape character is '^]'. SSH-2.0-OpenSSH_6.5 ^C Connection closed by foreign host. box1:~# iked -6dv ikev2 policy1 passive esp inet from 192.168.150.16 to 192.168.150.13 local any peer 192.168.150.13 ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1,hmac-md5 auth hmac-sha2-256,hmac-sha1,hmac-md5 group modp2048-256,modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 lifetime 10800 bytes 536870912 psk 0x74657354 ikev2_recv: IKE_SA_INIT from initiator 192.168.150.13:500 to 192.168.150.16:500 policy 'policy1' id 0, 520 bytes ikev2_msg_send: IKE_SA_INIT from 192.168.150.16:500 to 192.168.150.13:500, 432 bytes ikev2_recv: IKE_AUTH from initiator 192.168.150.13:500 to 192.168.150.16:500 policy 'policy1' id 1, 272 bytes ikev2_msg_send: IKE_AUTH from 192.168.150.16:500 to 192.168.150.13:500, 240 bytes sa_state: VALID - ESTABLISHED from 192.168.150.13:500 to 192.168.150.16:500 policy 'policy1' box2:~# iked -6dv ikev2 policy1 active esp inet from 192.168.150.13 to 192.168.150.16 local any peer 192.168.150.16 ikesa enc
Content Filtering in smtpd(8) with amavisd-new
I recently configured smptd to replace a postfix-based solution. smtpd(8) is a joy to work with. In ~four rules I had a working email server! My next goals was to get content filtering in place. I decided on amavisd-new with clamav and spamassassin. I couldn't find any tutorials for using amavisd with smtpd(8) so I worked out my own solution based on some postfix tutorials and the excellent smtpd.conf(5) doc. Following are the steps and missteps that got me to the working smtpd.conf included at the bottom. I have also have one question for the smtpd(8) developers at the end. The goal was to have smtpd deliver via lmtp to amavisd. Fortunately smtpd in 5.4 (shipping) supports lmtp via the deliver and relay keywords. That’s important as we’ll see in a minute. Installing amavisd is easy. Configuration is another story. For now I'm assuming the user can handle pkg_add -i amavisd-new and starting the relevant daemons. The first step is to create a rule to send inbound email to amavisd rather than procmail. accept tagged default from any for domain domains \ relay via lmtp://127.0.0.1:10024 The reason for relay via will make sense shortly. Once I had mail delivering to amavisd I had to arrange for smtpd to listen on another port to receive the content-filtered email. The default in the amavis world is to listen on port 10024 and re-inject on 10025. I initially tried writing to rules to “accept from if:port”. That failed miserably. Tagging is the solution. Each “listen on” command can tag client sessions that are later used via “accept tagged tag”. With that problem solved I was able to define 3 production listeners and one for testing: listen on lo0 port 10025 tag amavis hostname amavis # re-injection listen on lo0 port 1587 tag testhostname test # testing listen on msk0 port 25tag default # external listen on lo0 tag default # internal It was at this point I discovered the need for relay via rather than delivery to. Initially I sent mail to amavisd with this rule: accept tagged test from any for domain domains virtual vmap \ deliver to lmtp 127.0.0.1:10024 That failed. What would happen is virtual vmap was forwarding the emails to amavisd for delivery to the user’s system account. To: user-t...@example.com effectively became To: user. When amavisd re-injected the email it was rejected by smtpd because To: user is an invalid recipient. The solution, then, was to defer the virtual vmap lookup until re-injection. The way to do do that was to use relay via: accept tagged default from any for domain domains \ relay via lmtp://127.0.0.1:10024 With those change in place content filtering began working and has continued to do so. smtpd(8) + spamd(1) + content-filtering = very little spam. The question I have for Gilles et al.: Is there a better way to send the emails to amavisd? It would be more efficient if emails went through virtual vmap first so invalid recipients were rejected before content filtering. Regardless, I'm happy with the results I'm seeing. Cheers, --Aaron Aaron Poffenberger # $OpenBSD: smtpd.conf,v 1.6 2013/01/26 09:38:25 gilles Exp $ # This is the smtpd server system-wide configuration file. # See smtpd.conf(5) for more information. # To accept external mail, replace with: listen on all # listen on lo0 port 10025 tag amavis hostname amavis # re-injection listen on lo0 port 1587 tag testhostname test # testing listen on msk0 port 25tag default # external listen on lo0 tag default # internal table vmapdb:/etc/mail/virtusertable.db table domains db:/etc/mail/domains.db # public emails before content filtering accept tagged default from any for domain domains \ relay via lmtp://127.0.0.1:10024 # re-injection from amavis accept tagged amavis from any for domain domains virtual vmap \ deliver to mda /usr/local/bin/procmail -f - # local delivery accept tagged default from any for local virtual vmap \ deliver to mda /usr/local/bin/procmail -f - # outbound relay for local users accept tagged default for any\ relay # Easy way to test content-filtering accept tagged testfor domain domains\ relay via lmtp://127.0.0.1:10024
Re: Content Filtering in smtpd(8) with amavisd-new
On Wed, Feb 26, 2014 at 11:30, Aaron Poffenberger wrote: When amavisd re-injected the email it was rejected by smtpd because To: user is an invalid recipient. The solution, then, was to defer the virtual vmap lookup until re-injection. The way to do do that was to use relay via: # public emails before content filtering accept tagged default from any for domain domains \ relay via lmtp://127.0.0.1:10024 # re-injection from amavis accept tagged amavis from any for domain domains virtual vmap \ deliver to mda /usr/local/bin/procmail -f - Do you need the virtual vmap on this deliver line? What if you deliver to amavis with the vmap, and then deliver mail tagged amavis without the vmap?
Re: Content Filtering in smtpd(8) with amavisd-new
On Feb 26, 2014, at 11:51 AM, Ted Unangst t...@tedunangst.com wrote: On Wed, Feb 26, 2014 at 11:30, Aaron Poffenberger wrote: When amavisd re-injected the email it was rejected by smtpd because To: user is an invalid recipient. The solution, then, was to defer the virtual vmap lookup until re-injection. The way to do do that was to use relay via: # public emails before content filtering accept tagged default from any for domain domains \ relay via lmtp://127.0.0.1:10024 # re-injection from amavis accept tagged amavis from any for domain domains virtual vmap \ deliver to mda /usr/local/bin/procmail -f - Do you need the virtual vmap on this deliver line? What if you deliver to amavis with the vmap, and then deliver mail tagged amavis without the vmap? I tried that. If you telnet into smtpd to manually send an email and set rcpt to: user you will receive a 553 Recipient address syntax error reply. I'm looking to see whether I can make amavisd write the rcpt to: line back to normal form user@domain.suffix. So far no luck. When smptd relays the email to user amavisd just accepts it and loses the context. The only option I can think of would be for smtpd to allow sending to contextless addresses if they match system users. But that wouldn't work on systems where they use an MDA like Dovecot that supports virtual users. --Aaron
Re: SMTP syntax (was: Content Filtering in smtpd(8) with amavisd-new)
On Wed, Feb 26, 2014, Aaron Poffenberger wrote: I tried that. If you telnet into smtpd to manually send an email and set rcpt to: user you will receive a 553 Recipient address syntax That's invalid even if you gave a proper address. RFC 5321: RCPT TO:forward-path [ SP rcpt-parameters ] CRLF ... Since it has been a common source of errors, it is worth noting that spaces are not permitted on either side of the colon following FROM in the MAIL command or TO in the RCPT command. The syntax is exactly as given above.
Re: SMTP syntax (was: Content Filtering in smtpd(8) with amavisd-new)
On Feb 26, 2014, at 1:15 PM, Claus Assmann ca+openbsd_m...@esmtp.org wrote: On Wed, Feb 26, 2014, Aaron Poffenberger wrote: I tried that. If you telnet into smtpd to manually send an email and set rcpt to: user you will receive a 553 Recipient address syntax That's invalid even if you gave a proper address. RFC 5321: RCPT TO:forward-path [ SP rcpt-parameters ] CRLF ... Since it has been a common source of errors, it is worth noting that spaces are not permitted on either side of the colon following FROM in the MAIL command or TO in the RCPT command. The syntax is exactly as given above. I didn’t know that. Thanks.
Re: NAT reliability in light of recent checksum changes
On 24/02/2014, at 9:33 PM, Henning Brauer wrote: * Richard Procter richard.n.proc...@gmail.com [2014-01-25 20:41]: On 22/01/2014, at 7:19 PM, Henning Brauer wrote: * Richard Procter richard.n.proc...@gmail.com [2014-01-22 06:44]: This fundamentally weakens its usefulness, though: a correct checksum now implies only that the payload likely matches what the last NAT router happened to have in its memory huh? we receive a packet with correct cksum - NAT - packet goes out with correct cksum. we receive a packet with broken cksum - NAT - we leave the cksum alone, i. e. leave it broken. Christian said it better than me: routers may corrupt data and regenerating the checksum will hide it. if that happened we had much bigger problems than NAT. By bigger problems do you mean obvious router stability issues? Suppose someone argued that as we'd have obvious stability issues if unprotected memory was unreliable, ECC memory is unnecessary. That argument is logically equivalent to what seems to be yours, that as we'd see obvious issues if routers were corrupting data, end-to-end checksums are unnecessary, but I don't buy it. We know that routers corrupt data. Right now my home firewall shows 30 TCP segments dropped for bad checksums. As checks at least as strong are used by every sane link-layer this virtually implies the dropped packets suffered router or end-point faults. Again, it's not just me saying it: ...checksums are used by higher layers to ensure that data was not corrupted in intermediate routers or by the sending or receiving host. The fact that checksums are typically the secondary level of protection has often led to suggestions that checksums are superfluous. Hard won experience, however, has shown that checksums are necessary. Software errors (such as buffer mismanagement) and even hardware errors (such as network adapters with poor DMA hardware that sometimes fail to fully DMA data) are surprisingly common [let alone memory faults! RP] and checksums have been very useful in protecting against such errors.[0] best, Richard. [0] Craig Partridge, Jim Hughes, and Jonathan Stone. 1995. Performance of checksums and CRCs over real data. SIGCOMM Comput. Commun. Rev. 25, 4 (October 1995), 68-76. DOI=10.1145/217391.217413 http://doi.acm.org/10.1145/217391.217413 page 1
Re: NAT reliability in light of recent checksum changes
On 24/02/2014, at 9:33 PM, Henning Brauer wrote: * Richard Procter richard.n.proc...@gmail.com [2014-01-25 20:41]: On 22/01/2014, at 7:19 PM, Henning Brauer wrote: * Richard Procter richard.n.proc...@gmail.com [2014-01-22 06:44]: This fundamentally weakens its usefulness, though: a correct checksum now implies only that the payload likely matches what the last NAT router happened to have in its memory huh? we receive a packet with correct cksum - NAT - packet goes out with correct cksum. we receive a packet with broken cksum - NAT - we leave the cksum alone, i. e. leave it broken. Christian said it better than me: routers may corrupt data and regenerating the checksum will hide it. if that happened we had much bigger problems than NAT. By bigger problems do you mean obvious router stability issues? Suppose someone argued that as we'd have obvious stability issues if unprotected memory was unreliable, ECC memory is unnecessary. That argument is logically equivalent to what seems to be yours, that as we'd see obvious issues if routers were corrupting data, end-to-end checksums are unnecessary, but I don't buy it. What is your solution? We know that routers corrupt data. Right now my home firewall shows 30 TCP segments dropped for bad checksums. As checks at least as strong are used by every sane link-layer this virtually implies the dropped packets suffered router or end-point faults. Yes. And what is your solution? Again, it's not just me saying it: ...checksums are used by higher layers to ensure that data was not corrupted in intermediate routers or by the sending or receiving host. The fact that checksums are typically the secondary level of protection has often led to suggestions that checksums are superfluous. Hard won experience, however, has shown that checksums are necessary. Software errors (such as buffer mismanagement) and even hardware errors (such as network adapters with poor DMA hardware that sometimes fail to fully DMA data) are surprisingly common [let alone memory faults! RP] and checksums have been very useful in protecting against such errors.[0] I'll ask again, since you keep just trashing other people's code. I'm getting ready to declare you a kook, because I suspect you're going to suggest we change ethernet header and IP headers or prohibit NAT.
Re: NAT reliability in light of recent checksum changes
Again, it's not just me saying it: ...checksums are used by higher layers to ensure that data was not corrupted in intermediate routers or by the sending or receiving host. The fact that checksums are typically the secondary level of protection has often led to suggestions that checksums are superfluous. Hard won experience, however, has shown that checksums are necessary. Software errors (such as buffer mismanagement) and even hardware errors (such as network adapters with poor DMA hardware that sometimes fail to fully DMA data) are surprisingly common [let alone memory faults! RP] and checksums have been very useful in protecting against such errors.[0] Richard, your use of this quote is tantamount to declaring that Henning has disabled or otherwise gutted checksums. He has not disabled checksums. There was a method of converting an in-bound checksum, due to NAT conversion, into a new out-bound checksum. A process is required, it's how NAT works. A new method of version is being used. It is mathematically equivelant to the old method. The quote above is about disabling checksums. Checksums have not been disabled, in any way. New checksums are not being invented out of anyone's ass for old packets. I believe you are posting cast aspersions on the pf efforts. Your repeated attempts to false aspersion are only reflecting back on you.
L2TP VPN / pf
I'm trying to get a L2TP VPN working using npppd; I think I'm most of the
way there but packets just aren't quite flowing. I'm not sure why, but I
think I might be missing something or misunderstanding something with pf.
I've got ipsec=YES and isakmpd_flags=-K in rc.conf.local, and
/etc/ipsec.conf configured as:
-
ike passive esp transport \
proto udp from 96.251.22.154 to any port 1701 \
psk somesekretkeyhere
-
My /etc/npppd/npppd.conf is:
-
authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}
tunnel L2TP_ipv4 protocol l2tp {
listen on 96.251.22.154
}
ipcp IPCP {
pool-address 10.128.120.2-10.128.120.254
dns-servers 10.128.0.4
}
interface pppx0 address 10.128.120.1 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx0
-
I currently have the following in pf.conf:
-
pass quick proto { esp, ah } from any to any
pass in quick on em1 proto udp from any to 96.251.22.154 port {500, 4500,
1701} keep state
set skip on enc0
set skip on pppx0
-
I'm pretty sure I have the ipsec/npppd pieces correct, as I am successfully
able to connect to the VPN:
-
2014-02-26 15:35:01:NOTICE: l2tpd ctrl=2 logtype=Started RecvSCCRQ
from=134.71.203.230:644
68/udp tunnel_id=2/6 protocol=1.0 winsize=4 hostname=Dogbert vendor=(no
vendorname) firm=0
000
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 SendSCCRP
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 RecvSCCN
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 SendZLB
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 call=21438 RecvICRQ session_id=3388
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 call=21438 SendICRP session_id=21438
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 call=21438 RecvICCN session_id=3388
calling_number=
tx_conn_speed=100 framing=async
2014-02-26 15:35:01:NOTICE: l2tpd ctrl=2 call=21438 logtype=PPPBind ppp=1
2014-02-26 15:35:01:INFO: ppp id=1 layer=base logtype=Started
tunnel=L2TP_ipv4(134.71.203.
230:64468)
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 call=21438 SendZLB
2014-02-26 15:35:04:INFO: ppp id=1 layer=lcp logtype=Opened mru=1360/1360
auth=MS-CHAP-V2
magic=c638067d/52525adf
2014-02-26 15:35:04:INFO: ppp id=1 layer=chap proto=mschap_v2
logtype=Success username=he
nson realm=LOCAL
2014-02-26 15:35:04:INFO: ppp id=1 layer=ipcp IP Address peer=0.0.0.0
our=10.128.120.160.
2014-02-26 15:35:04:INFO: ppp id=1 layer=base unhandled protocol ipv6cp,
32855(8057)
2014-02-26 15:35:04:INFO: ppp id=1 layer=base unhandled protocol acsp,
3(8235)
2014-02-26 15:35:04:INFO: ppp id=1 layer=ccp CCP is stopped
2014-02-26 15:35:04:INFO: ppp id=1 layer=ipcp logtype=Opened
ip=10.128.120.160 assignType=
dynamic
2014-02-26 15:35:04:NOTICE: ppp id=1 layer=base logtype=TUNNELSTART
user=henson duration
=4sec layer2=L2TP_ipv4 layer2from=134.71.203.230:64468 auth=MS-CHAP-V2
ip=10.128.120.160
iface=pppx0
2014-02-26 15:35:04:NOTICE: ppp id=1 layer=base Using pipex=yes
-
However, from the VPN client I cannot ping 10.128.120.1, the server
endpoint, and from the server I cannot ping 10.128.120.160, the client
endpoint. When I try to ping the client, I can see traffic on the ethernet
interface:
16:07:56.431711 esp bart.pbhware.com
host-134-71-203-230.allocated.csupomona.edu spi 0x04e9efec seq 32 len 148
(DF)
16:07:57.441732 esp bart.pbhware.com
host-134-71-203-230.allocated.csupomona.edu spi 0x04e9efec seq 33 len 148
(DF)
16:07:58.451762 esp bart.pbhware.com
host-134-71-203-230.allocated.csupomona.edu spi 0x04e9efec seq 34 len 148
(DF)
And on the enc0 interface:
16:07:52.391543 (authentic,confidential): SPI 0x04e9efec:
bart.pbhware.com.l2tp host-134-71-203-230.allocated.csupomona.edu.51118:
l2tp:[LS](8/3432)Ns=21,Nr=65535[hdlc|][|l2tp]
16:07:53.401575 (authentic,confidential): SPI 0x04e9efec:
bart.pbhware.com.l2tp host-134-71-203-230.allocated.csupomona.edu.51118:
l2tp:[LS](8/3432)Ns=22,Nr=65535[hdlc|][|l2tp]
Conversely, when I try to ping the server from the client:
16:09:42.857872 esp host-134-71-203-230.allocated.csupomona.edu
bart.pbhware.com spi 0x506039f8 seq 96 len 148
16:09:42.857875 esp host-134-71-203-230.allocated.csupomona.edu
bart.pbhware.com spi 0x506039f8 seq 96 len 148
16:09:43.855422 esp host-134-71-203-230.allocated.csupomona.edu
bart.pbhware.com spi 0x506039f8 seq 97 len 148
16:09:43.855454 (authentic,confidential): SPI 0x506039f8:
host-134-71-203-230.allocated.csupomona.edu.51118 bart.pbhware.com.l2tp:
l2tp:[L](1/12490)[hdlc|][|l2tp]
16:09:44.855469 (authentic,confidential): SPI 0x506039f8:
host-134-71-203-230.allocated.csupomona.edu.51118 bart.pbhware.com.l2tp:
l2tp:[L](1/12490)[hdlc|][|l2tp]
16:09:45.855498 (authentic,confidential): SPI 0x506039f8:
host-134-71-203-230.allocated.csupomona.edu.51118 bart.pbhware.com.l2tp:
l2tp:[L](1/12490)[hdlc|][|l2tp]
Ideally, I would like to completely disable pf at this point to confirm that
is the problem, but unfortunately it is a production router and I can't
really do that 8-/.
Am I missing something in either the ipsec, npppd, or pf
Re: Local routing issue when iked running
On 2014-02-26, Josh mylis...@gmail.com wrote: Hi @misc, I am facing an issue between two boxes (box1 and box2) connected through an IPsec tunnel. They are both on the same subnet and both listen on port 22 (sshd running) When the ipsec tunnel is down and encap routes are flushed on both boxes (ipsecctl -F), performing a telnet ip_of_box1 22 on box1 works fine. Same on box2. However, when the ipsec tunnel is up, performing the same telnet command on box1 will just time out. Same timeout on box2. Reaching box1 from box2 and vice versa is not a problem. I am not sure to understand why I can't reach the local IP address when the tunnel is up. Try tcpdumping packets going over the ipsec tunnel, do you see those packets which should be local actually being sent over the tunnel? If so, I don't have an answer for this, but I've seen it myself, though only with manually configured ipsec rather than IKE (though I've only really tried IKEv1 with isakmpd, not IKEv2). I've mentioned it to a few people but haven't heard any possible explanations yet.
Re: NAT reliability in light of recent checksum changes
On 27/02/2014, at 11:04 AM, Theo de Raadt wrote: I believe you are posting cast aspersions on the pf efforts. Theo, I'll insist then that I think pf is a superior piece of code which I benefit from every day, and that Henning's efforts to simplify it are so very welcome in a world addicted to complexity. My beef is solely with the technique of regenerating checksums, not the people working on the code. Criticising a design choice with argument and evidence is not the same as attacking the designer's integrity or competence and if I seem to be playing the men and not the ball, it is not my intent and I apologise. As to your other points, I will hopefully address them in another email I have been drafting and should have finished over the next few days. best, Richard.
Re: Local routing issue when iked running
On Thu, Feb 27, 2014 at 11:00 AM, Stuart Henderson s...@spacehopper.org wrote: Try tcpdumping packets going over the ipsec tunnel, do you see those packets which should be local actually being sent over the tunnel? If so, I don't have an answer for this, but I've seen it myself, though only with manually configured ipsec rather than IKE (though I've only really tried IKEv1 with isakmpd, not IKEv2). I've mentioned it to a few people but haven't heard any possible explanations yet. Hi Stuart, It seems to be what I am facing: (tcpdump output on box1 when performing a telnet box1_ip (192.168.150.16) to port 22 on box1) box1:~# tcpdump -envps 1500 -i enc0 -l tcpdump: listening on enc0, link-type ENC 11:18:15.258255 (authentic,confidential): SPI 0xf704e810: 192.168.150.13 192.168.150.16: 192.168.150.16.33636 192.168.150.16.22: S [tcp sum ok] 724448283:724448283(0) win 16384 mss 33152,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2973607861 0 (DF) [tos 0x10] (ttl 64, id 47660, len 64) (DF) [tos 0x10] (ttl 64, id 59798, len 84, bad cksum 0!) 11:18:15.258422 (authentic,confidential): SPI 0xf704e810: 192.168.150.13 192.168.150.16: 192.168.150.16.33636 192.168.150.16.22: S [tcp sum ok] 724448283:724448283(0) win 16384 mss 33152,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2973607861 0 (DF) [tos 0x10] (ttl 64, id 47660, len 64) (DF) [tos 0x10] (ttl 64, id 59798, len 84) Is that a bug or just normal behavior and is there any way to get around it? Cheers, Josh
Re: L2TP VPN / pf
Hi,
On Wed, 26 Feb 2014 16:32:34 -0800
Paul B. Henson hen...@acm.org wrote:
I currently have the following in pf.conf:
-
pass quick proto { esp, ah } from any to any
pass in quick on em1 proto udp from any to 96.251.22.154 port {500, 4500,
1701} keep state
set skip on enc0
set skip on pppx0
-
set skip on pppx0 needs to be improved because npppd may use pppx1,
or pppx2 ...
I'm pretty sure I have the ipsec/npppd pieces correct, as I am successfully
able to connect to the VPN:
-
2014-02-26 15:35:01:NOTICE: l2tpd ctrl=2 logtype=Started RecvSCCRQ
from=134.71.203.230:644
(snip)
2014-02-26 15:35:04:NOTICE: ppp id=1 layer=base logtype=TUNNELSTART
user=henson duration
=4sec layer2=L2TP_ipv4 layer2from=134.71.203.230:64468 auth=MS-CHAP-V2
ip=10.128.120.160
iface=pppx0
L2TP/IPsec seems to be established successfully. This means your
ipsec.conf, npppd.conf and pf.conf are ok.
However, from the VPN client I cannot ping 10.128.120.1, the server
endpoint, and from the server I cannot ping 10.128.120.160, the client
endpoint. When I try to ping the client, I can see traffic on the ethernet
interface:
(snip)
Am I missing something in either the ipsec, npppd, or pf configuration?
Did you do
sysctl net.pipex.enable=1
? This is required to pass packets through the VPN tunnel.
For this rule pass quick proto { esp, ah } from any to any, does it really
need to be any to any with no interface defined?
I think it is required only from/to the listening address of L2TP.
Wouldn't all of the ipsec traffic be on the WAN interface to/from
the WAN IP? While I think this piece is working, I'd rather have the
rule exactly match what is needed than be extra generic.
Regarding this rule pass in quick on em1 proto udp from any to
96.251.22.154 port {500, 4500, 1701} keep state, it looks like the
connection to the l2tp port is over the ipsec tunnel and hence via enc0, not
em1? So it doesn't seem 1701 needs to be allowed in on this rule, I removed
it and it continued to work, at least as far as successfully connecting but
not passing traffic over the VPN link sigh.
In L2TP/IPsec, transport mode IPsec is used instead of tunnel mode.
This means enc(4) is not used. And de-capsulated L2TP packets are
received on the same interface which receives IPsec packet.
--yasuoka
