monitoring-plugins-2.2p8: check_dhcp broadcast requests not working
Hello ports@, I am unable to get broadcast DHCP requests to be generated on openbsd 6.6 and 6.7 using the packaged versions of monitoring-plugins, which are monitoring-plugins-2.2p8 and monitoring-plugins-2.2p9, respectively. I have tested the package on a few different environments and it boils down to this: - unicast DHCP is working fine with something like: -i vio1 -v -t 3 -m "52:54:00:f3:e9:cb" -r 10.10.0.10 -s 10.10.0.2 -u - if the server runs something like '/usr/local/libexec/nagios/check_dhcp -i vio1', which should be a broadcast request: - packets will always exit through the first phsical ethernet interface (e.g. vio0) - no reply received - if the server runs something like '/usr/local/libexec/nagios/check_dhcp -i vio0' - if the interface has no address, a packet will not be sent at all. No local unicast addess needed with IPv4 broadcast DHCP client - if the interface has an address, no DHCP replies are ever received Unicast-based DHCP monitoring works fine, but this type of monitoring does not meet the criteria for rogue DHCP server detection. Can anyone confirm/deny this before I get an opportunity to look at the code? Thanks, -- Marcos Madeira
Re: perl hex possible bug
On Tue, Jul 21, 2020 at 3:12 PM Edgar Pettijohn
wrote:
> I was playing around with the hex function in perl. So naturally I
> started with:
>
> perldoc -f hex
>
> Which showed me a few examples namely the following:
>
> print hex '0xAf'; # prints '175'
> print hex 'aF'; # same
> $valid_input =~ /\A(?:0?[xX])?(?:_?[0-9a-fA-F])*\z/
>
> However, I get the following output: (newlines added for clarity)
>
> laptop$ perl -e 'print hex '0xAf';'
> 373
>
You used the same quotes on the inside and out, so the "inner"
quotes actually never get to the perl! The shell parses the argument to
perl to
print hex 0xAf
0xAf is a numeric literal whose value is 175. The hex() function then
takes its argument (175) converts it to a string ("175") and interpretats
that string per its rules...as if you passed it "0x175" which equals 373.
If you use distinct quotes, you get the value you expect:
$ perl -le 'print hex "0xAf";'
175
$
> laptop$ perl -e 'print hex 'aF';'
> 175
>
That relies on the so-called poetry extension, where a bare word like aF is
treated as a string. Turn on strict...
$ perl -Mstrict -le 'print hex Af;'
Bareword "Af" not allowed while "strict subs" in use at -e line 1.
Execution of -e aborted due to compilation errors.
$
> I'm guessing there is a bug here but not sure if its software or
> documentation.
>
No bug, just shell quoting traps.
Philip Guenther
Re: perl hex possible bug
I realized after the fact, that looking at some of the different ways you can write numbers in perl. $n = 1234; # decimal integer $n = 0b1110011; # binary integer $n = 01234; # octal integer $n = 0x1234;# hexadecimal integer $n = 12.34e-56; # exponential notation $n = "-12.34e56"; # number specified as a string $n = "1234";# number specified as a string http://man.openbsd.org/perlnumber On Tue, Jul 21, 2020 at 05:24:34PM -0700, Andrew Hewus Fresh wrote: > On Tue, Jul 21, 2020 at 07:10:34PM -0500, Edgar Pettijohn wrote: > > I was playing around with the hex function in perl. So naturally I > > started with: > > > > perldoc -f hex > > > > Which showed me a few examples namely the following: > > > > print hex '0xAf'; # prints '175' > > print hex 'aF'; # same > > $valid_input =~ /\A(?:0?[xX])?(?:_?[0-9a-fA-F])*\z/ > > > > However, I get the following output: (newlines added for clarity) > > > > laptop$ perl -e 'print hex '0xAf';' > > 373 > > so, you're double-use of single quotes here causes some fun shell > processing. This is the same as: > > perl -e 'print hex 0xAf' > > (although let me re-do that with -E and say) > > $ perl -E 'say hex 0xAf' > 373 > > Well, as you say, that's not what you expect. > > But, perhaps there is an explanation. Lets try without hex. > > $ perl -E 'say 0xAf' > 175 > > interesting, but where's the hex? > > $ perl -E 'say hex 175' > 373 > > ahh, there it is. > > Just to get back on the original page though and avoid the shell > confusion, lets try one last thing. > > $ perl -E 'say hex "0xAf"' > 175 > > And that work. Although I guess we can also > > $ perl -e 'print hex "0xAf"' > 175 > > if you'd like. > > > > laptop$ perl -e 'print hex 'aF';' > > 175 > > > > I'm guessing there is a bug here but not sure if its software or > > documentation. > > > > Thanks, > > > > Edgar > > > > -- > andrew - http://afresh1.com > > Hey! It compiles! Ship it! > -- andrew - http://afresh1.com Hey, I think I see a barn up ahead. -- The American Astronaut
Re: perl hex possible bug
On Tue, Jul 21, 2020 at 07:10:34PM -0500, Edgar Pettijohn wrote: > I was playing around with the hex function in perl. So naturally I > started with: > > perldoc -f hex > > Which showed me a few examples namely the following: > > print hex '0xAf'; # prints '175' > print hex 'aF'; # same > $valid_input =~ /\A(?:0?[xX])?(?:_?[0-9a-fA-F])*\z/ > > However, I get the following output: (newlines added for clarity) > > laptop$ perl -e 'print hex '0xAf';' > 373 so, you're double-use of single quotes here causes some fun shell processing. This is the same as: perl -e 'print hex 0xAf' (although let me re-do that with -E and say) $ perl -E 'say hex 0xAf' 373 Well, as you say, that's not what you expect. But, perhaps there is an explanation. Lets try without hex. $ perl -E 'say 0xAf' 175 interesting, but where's the hex? $ perl -E 'say hex 175' 373 ahh, there it is. Just to get back on the original page though and avoid the shell confusion, lets try one last thing. $ perl -E 'say hex "0xAf"' 175 And that work. Although I guess we can also $ perl -e 'print hex "0xAf"' 175 if you'd like. > laptop$ perl -e 'print hex 'aF';' > 175 > > I'm guessing there is a bug here but not sure if its software or > documentation. > > Thanks, > > Edgar > -- andrew - http://afresh1.com Hey! It compiles! Ship it!
perl hex possible bug
I was playing around with the hex function in perl. So naturally I started with: perldoc -f hex Which showed me a few examples namely the following: print hex '0xAf'; # prints '175' print hex 'aF'; # same $valid_input =~ /\A(?:0?[xX])?(?:_?[0-9a-fA-F])*\z/ However, I get the following output: (newlines added for clarity) laptop$ perl -e 'print hex '0xAf';' 373 laptop$ perl -e 'print hex 'aF';' 175 I'm guessing there is a bug here but not sure if its software or documentation. Thanks, Edgar
Re: Shell account service providers
Adrian Grigore @ 2020-07-19 13:33 IST: > https://tilde.institute/ There's also tilde.black, both are part of [tildeverse]. But it doesn't meet the poster's requirements. >> > Minimally, SSH login, 100GB disk space, and build tools I think the admins would be okay with installing build tools if it's in ports but I doubt you'll get 100GB disk space, no tilde server will allow that. [tildeverse] https://tildeverse.org signature.asc Description: PGP signature
pf.conf set state-defaults pflow seemingly not exporting traffic
pf.conf set state-defaults pflow seemingly not exporting traffic My money is on state-defaults working and I just am doing something wrong, but I can't figure out what it is. The sensor's information: OpenBSD 6.7 (GENERIC.MP) #4: Wed Jul 15 11:16:20 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64 /compile/GENERIC.MP bios0: PC Engines APU2 On the sensor in /etc/pf.conf each pass rule has modulate state. I add (pflow) to each of these rules, flows export correctly. If I don't explicitly add (pflow), I don't see netflow traffic. Note about the collector: Everything else in this message only involves the sensor. If I add (pflow) to each "modulate state" pass rule /etc/pf.conf in the sensor, the collector works fine. If I take it away, the collector only generates files with no flow data, e.g. ls -l gives root _netflow 100 Jul 20 23:50 ft-v05.2020-07-20.234501-0500 instead of lengths that reflected the explicit (pflow) rules on the sensor the day before: root _netflow 5546 Jul 19 04:35 ft-v05.2020-07-19.043001-0500 Please note that the size was 100 for every file for Jul 20, not just for 23:50. These dates are just one example. Going back and forth from explicit (pflow) on the sensor generates the same sort of results. End of note about the collector. Both /etc/pf.conf and /etc/pf.conf.onlystatedefaultspflow contain set state-defaults pflow pass log quick proto udp from flowgroup to collector port $flowport modulate state \ label "flow $if $nr $srcaddr $dstaddr" The only difference between the files is that pf.conf.onlystatedefaultspflow lacks explicit (pflow). i.e. if pf.conf has pass log inet proto tcp to https modulate state (pflow) then pf.conf.onlystatedefaultspflow has pass log inet proto tcp to https modulate state I've cleaned up the output of a typescript that shows the problem: If I understand the output correctly, I have to explicitly add (pflow) to the pass rules to get traffic on the pflow0 interface, and to see traffic from my labeled rule that exports the flows. First with only the set state-defaults: step0# /sbin/pfctl -f /etc/pf.conf.onlystatedefaultspflow step1# /usr/bin/netstat -b -I pflow0 NameMtu Network AddressIbytes Obytes pflow01492 0 53359944 step2# /sbin/pfctl -s label | /usr/bin/grep flow flow any 0 10.0.1.1 10.0.1.3 99 1 1300 0 0 1 1300 1 step3# /bin/echo "generating traffic on some other host" step4# /usr/bin/netstat -b -I pflow0 NameMtu Network AddressIbytes Obytes pflow01492 0 53359944 step5# /sbin/pfctl -s label | /usr/bin/grep flow flow any 0 10.0.1.1 10.0.1.3 172 1 1300 0 0 1 1300 1 now loading ruleset with (pflow) on each rule with modulate state step0# /sbin/pfctl -f /etc/pf.conf step1# /usr/bin/netstat -b -I pflow0 NameMtu Network AddressIbytes Obytes pflow01492 0 53360160 step2# /sbin/pfctl -s label|/usr/bin/grep flow flow any 0 10.0.1.1 10.0.1.3 69 0 0 0 0 0 0 0 step3# /bin/echo "generating traffic on another host" step4# /usr/bin/netstat -b -I pflow0 NameMtu Network AddressIbytes Obytes pflow01492 0 53364552 step5# /sbin/pfctl -s label|/usr/bin/grep flow flow any 0 10.0.1.1 10.0.1.3 95 3 4476 0 0 3 4476 1
Re: gdb in uninterruptible wait
On Mon, 20 Jul 2020 17:18:19 +0100 Julian Smith wrote: > On Mon, 20 Jul 2020 15:26:11 + > Visa Hankala wrote: > > > On Mon, Jul 20, 2020 at 04:35:12AM +, Visa Hankala wrote: > > > On Sun, Jul 19, 2020 at 09:47:54PM +0100, Julian Smith wrote: > > > > I've been finding egdb and gdb rather easily get stuck in an > > > > uninterruptible wait, e.g. when running the 'next' command after > > > > hitting a breakpoint. > > [...] > > > > The single-thread check done by wait4() is non-interruptible. > > > When the debugger gets stuck, is it blocked in "suspend" state? > > ps reports it to be in state 'D'. > > > > > > > However, I think there is a bug in the single-thread switch code. > > > It looks that ps_singlecount can be decremented too much. This > > > probably is a regression of making ps_singlecount unsigned and > > > letting single_thread_check() run without the kernel lock. > > > > > > The bug might go away if single_thread_check() made sure that > > > P_SUSPSINGLE is set before the thread suspends. > > > > Below is an updated patch for testing. It extends the scope of > > SCHED_LOCK() so that there are fewer chances of interleaving of > > single_thread_set() and single_thread_check(). > > Many thanks for these patches. I'll try to test in the next couple of > days. Though the last time i built an OpenBSD kernel was well over a > decade ago, so it might take me a little longer. I managed to build a patched kernel, and it seems to fix the problem - i haven't been able to get egdb into an uninterruptable wait state. Also, i've been running the patched kernel all day now and it doesn't seem to be causing any problems elsewhere. Thanks, - Jules -- http://op59.net
ksh very slow compared to bash when running ghostscript's ./configure script
It looks like ksh runs much slower than bash with current Ghostscript's ./configure script - for me it takes 20m, compared with 45s under bash. This is on OpenBSD 6.7 GENERIC.MP#1 amd64. [This kernel has visa@'s wait4() patch (see recent 'gdb in uninterruptible wait' thread), but the same problem also occurred last week with the release kernel, GENERIC.MP#182).] To reproduce: git clone https://git.ghostscript.com/ghostpdl.git cd ghostpdl AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.16 CONFIGURE_STYLE=gnu ./autogen.sh This runs things like autoreconf, then does ./configure. It takes 20m on my machine, seemingly getting stuck for a a long time after outputting 'checking compiler/linker address santizer build warnings support...' and consuming 80% cpu. Modifying autogen.sh to use /usr/local/bin/bash instead of ksh when running ./configure, like this: diff --git a/autogen.sh b/autogen.sh index 7a0783623..2f6624b10 100755 --- a/autogen.sh +++ b/autogen.sh @@ -50,4 +50,4 @@ else echo "running ./configure $@" fi -$srcdir/configure "$@" && echo +/usr/local/bin/bash $srcdir/configure "$@" && echo - results in the above ./autogen.sh command completing in about 45s for me. (this is with a clean tree again.) I don't know what's causing this. Is there some algorithm inside ksh that could be running into complexity issues somehow? [A colleague reports that ksh on Linux doesn't run slowly. But i guess ksh has diverged a lot on OpenBSD/Linux, so that's perhaps not too surprising.] Thanks, - Jules -- http://op59.net
Re: pf.conf set state-defaults pflow seemingly not exporting traffic
On Tue, 21 Jul 2020 19:35:17 +0200, Peter Nicolai Mathias Hansteen wrote: > pfctl -vnf pf.conf oh indeed it says pass out log on vlan10 proto tcp all flags S/SA modulate state (if-bound) but I understood why my pflow setup still works: it takes the flow from the internal interfaces :)
Re: pf.conf set state-defaults pflow seemingly not exporting traffic
> 21. jul. 2020 kl. 19:06 skrev Daniel Jakots :
>> Your ‘modulate state’ overrides the default. As you have seen, on
>> non-default rules you need to add any options explicitly.
>
> Are you sure?
> I have a working (AFAIK) pflow setup and I also have
> pass out log on $ext_if proto { tcp, udp } all modulate state
>
> (I checked the rule is used because if I comment it the outgoing
> traffic doesn't go anymore)
The only way to be sure is to look at the actually loaded rule set (systat
rules or pfctl -vnf pf.conf), the boxes I have within easy reach do not use
these features at the moment, I’m afraid.
All the best,
—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
signature.asc
Description: Message signed with OpenPGP
Re: pf.conf set state-defaults pflow seemingly not exporting traffic
On Tue, 21 Jul 2020 18:52:40 +0200, Peter Nicolai Mathias Hansteen
wrote:
> > 21. jul. 2020 kl. 17:42 skrev marfabastewart
> > :
> >
> > pf.conf set state-defaults pflow seemingly not exporting traffic
> >
> > My money is on state-defaults working and I just am doing something
> > wrong, but I can't figure out what it is.
> >
> > The sensor's information:
> > OpenBSD 6.7 (GENERIC.MP) #4: Wed Jul 15 11:16:20 MDT 2020
> > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64
> > /compile/GENERIC.MP
> > bios0: PC Engines APU2
> >
> > On the sensor in /etc/pf.conf each pass rule has modulate state. I
> > add (pflow) to each of these rules, flows export correctly. If I
> > don't explicitly add (pflow), I don't see netflow traffic.
>
> That is indeed the expected behavior.
>
> set state-defaults only sets the default so any rule without
> explicitly set state options will evaluate as having ‘keep state
> (pflow)’.
>
> Your ‘modulate state’ overrides the default. As you have seen, on
> non-default rules you need to add any options explicitly.
Are you sure?
I have a working (AFAIK) pflow setup and I also have
pass out log on $ext_if proto { tcp, udp } all modulate state
(I checked the rule is used because if I comment it the outgoing
traffic doesn't go anymore)
Cheers,
Daniel
Re: pf.conf set state-defaults pflow seemingly not exporting traffic
> 21. jul. 2020 kl. 17:42 skrev marfabastewart : > > pf.conf set state-defaults pflow seemingly not exporting traffic > > My money is on state-defaults working and I just am doing something > wrong, but I can't figure out what it is. > > The sensor's information: > OpenBSD 6.7 (GENERIC.MP) #4: Wed Jul 15 11:16:20 MDT 2020 > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64 > /compile/GENERIC.MP > bios0: PC Engines APU2 > > On the sensor in /etc/pf.conf each pass rule has modulate state. I > add (pflow) to each of these rules, flows export correctly. If I > don't explicitly add (pflow), I don't see netflow traffic. That is indeed the expected behavior. set state-defaults only sets the default so any rule without explicitly set state options will evaluate as having ‘keep state (pflow)’. Your ‘modulate state’ overrides the default. As you have seen, on non-default rules you need to add any options explicitly. All the best, — Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. signature.asc Description: Message signed with OpenPGP
Re: how to pledge(2) for Yubikey
On 2020-07-14 12:58, Stuart Henderson wrote: > Known problem, there's no nice way around it though. The standard model > used on most OS of controlling many simpler USB devices from a low > privileged userland process does not work too well with the approach > in https://cvsweb.openbsd.org/src/etc/MAKEDEV.common#rev1.105 > > afaik the options for this are chmod, run as root, or write a driver that > works similar to fido(4) and modify the existing software that interfaces > with the device to use that instead (I guess for yk it will need a way to > hook into the keyboard driver too for the usual button-press keyboard > emulation otp mode). One approach is to grant access to the user logged in at the console. Another approach is to write a userspace daemon that has permission to interact with the device, and which can handle access control itself. I prefer this approach, as it reduces the kernel’s attack surface. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: Installation in a Xen guest (pvgrub)
Hey, > For boot I can only rely on a bunch of provided Linux kernels or the > pvgrub stuff to boot from the disks. There is no possibility to run HVM / PVHVM guests over there? PVGRUB will only boot PV guests, not even PVH. To run a PVH guest, the only method available today is Direct Kernel Boot *1. And I don't think OpenBSD supports PVH just yet anyhow. Besides, I've read somewhere you might need some exotic cpu flags to run a PVH domain, such as `ept`, not just `vmx`. > Would there be a chance to hack on the Linux-bootcode to boot the > BSD-kernel? Makes it sense to look into how this boot works or doesn't > it make sense at all?! GRUB2 should be able to boot an OpenBSD kernel natively *2. Thing is, PVGRUB works for PV, not PVH nor PVHVM. However you might get NetBSD XEN/PV up and running at your XEN ISP *3, by leveraging PVGRUB indeed *3. And in case UFS is not built-into their PVGRUB binary (that would be weird, as one usually builds pvgrub with all possible modules within), you would still be able to boot it on EXT2 with poor disk performance *4. *1 http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#Direct-Kernel-Boot *2 https://www.gnu.org/software/grub/manual/grub/html_node/Supported-kernels.html *3 https://pub.nethence.com/booting/grub *4 https://pub.nethence.com/bsd/malabar -- Pierre-Philipp
ipcomp does not work with IPv6 trafic
Adding ipcomp to earlier mentioned policy blocks IPv6 packets on the receiving side. tcpdump shows that packet is received on enc0 interface but not forwarded to the endpoint. Adding ipv4 traffic selector allows to send IPv4 packets over ipcomp but not IPv6. ipcomp is enabled on both sides. $ sysctl net.inet.ipcomp.enable net.inet.ipcomp.enable=1 пн, 20 июл. 2020 г. в 12:03, Антон Касимов : > I am using OpenBSD 6.7 > iked does not respect mixing ports in the source and the destination of > traffic selectors. > > Such policy in iked.conf > ikev2 "epsilon" active \ > proto tcp \ > from ::::30 to :::10::2 port 8000 \ > from ::::30 port postgresql to ::::/48 \ > from ::::30 port postgresql to ::::/48 \ > peer d.d.d > > Produces wrong flows (specifying only destination port from first > selector): > > flow esp in proto tcp from ::::/48 port 8000 to > ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require > flow esp in proto tcp from ::::/48 *port 8000* to > ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require > flow esp in proto tcp from ::::2 *port 8000* to > ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require > flow esp out proto tcp from ::::30 to ::::/48 port > 8000 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require > flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d::/48 *port > 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require > flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d:10::2 *port > 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require > > -- > Антон Касимов / Anton Kasimov > -- Антон Касимов / Anton Kasimov
Re: l2ip + ipsec question
21.07.2020 11:43, Stuart Henderson пишет: most endpoints cope wigh slightly less terrible crypto, you can try something like ike passive esp transport \ proto udp from my.external.ip to any port 1701 \ main auth "hmac-sha1" enc "aes-256" group modp2048 \ quick auth "hmac-sha2-256" enc "aes-256" \ psk "0s5jTDcMziOVw3DXZqaGOVlEZyoe8I9c" (psk generated randomly from "openssl rand -base64 (length)", use something complex if you can copy-and-paste to the other devices) Yep, mod2048 works, thanks! 2) ipsec.conf man, says that "esp" is default. But if I omit this option, it stops working with error like: PAYLOAD_MALFORMED. 3) and the most difficult for me to understand: Why does all howto's use this fragment: proto udp from my.ga.te.ip to any port 1701 ?? the ipsec.conf man says: from src [port sport] [(srcnat)] to dst [port dport] so, this line declare a tunnel, where our gate use any port, and our expected remote client use port 1701?? why does this even work? Thank you in advance for help! It relies on the fact that l2tp uses a fixed source port, iirc you can use "from my.gate.ip port 1701 to any port 1701" if you want. btw I strongly recommend avoiding l2tp+ipsec if you have another choice. Plain ipsec (ikev1 or ikev2) or other protocols like wireguard/openvpn cope better if you end up on a natted network. i'm sorry but i still do not understand. I have fired up tcpdump on enc0 and what's that I see there: 12:20:01.791795 (authentic,confidential): SPI 0x0e3e51b6: 212.233.112.12.l2tp > mx.kasakoff.net.59516: l2tp:[LS](14/9936)Ns=13,Nr=65535[hdlc|][|l2tp] 12:20:01.894911 (authentic,confidential): SPI 0x0e3e51b6: 212.233.112.12.l2tp > mx.kasakoff.net.59516: l2tp:[LS](14/9936)Ns=14,Nr=65535[hdlc|][|l2tp] 12:20:05.066256 (authentic,confidential): SPI 0xd5815d86: mx.kasakoff.net.59516 > 212.233.112.12.l2tp: l2tp:[L](83/7415)[hdlc|][|l2tp] 12:20:06.073233 (authentic,confidential): SPI 0xd5815d86: mx.kasakoff.net.59516 > 212.233.112.12.l2tp: l2tp:[L](83/7415)[hdlc|][|l2tp] Here, 212.233.112.12 is my gateway ip, and mx.kasakoff.net is the client. As I can see, the client side does not use 1701 port. But either "from 212.233.112.12 port l2tp to any" or "from 212.233.112.12 to any port l2tp" works! I can't fully understand why.
Re: iked wrongly processes traffic selectors
Hi Tobias,
the patch works for me. Thanks.
пн, 20 июл. 2020 г. в 23:51, Tobias Heider :
> On Mon, Jul 20, 2020 at 12:03:57PM +0300, Антон Касимов wrote:
> > I am using OpenBSD 6.7
> > iked does not respect mixing ports in the source and the destination of
> > traffic selectors.
> >
> > Such policy in iked.conf
> > ikev2 "epsilon" active \
> > proto tcp \
> > from ::::30 to :::10::2 port 8000 \
> > from ::::30 port postgresql to ::::/48 \
> > from ::::30 port postgresql to ::::/48 \
> > peer d.d.d
> >
> > Produces wrong flows (specifying only destination port from first
> selector):
> >
> > flow esp in proto tcp from ::::/48 port 8000 to
> > ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type
> require
> > flow esp in proto tcp from ::::/48 *port 8000* to
> > ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type
> require
> > flow esp in proto tcp from ::::2 *port 8000* to
> > ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type
> require
> > flow esp out proto tcp from ::::30 to ::::/48
> port
> > 8000 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> > flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d::/48
> *port
> > 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> > flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d:10::2
> *port
> > 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> >
> > --
> > Антон Касимов / Anton Kasimov
>
> Hi Anton,
>
> thanks for the report.
> Below is a diff that should fix your problem.
>
> Index: parse.y
> ===
> RCS file: /mount/openbsd/cvs/src/sbin/iked/parse.y,v
> retrieving revision 1.102
> diff -u -p -r1.102 parse.y
> --- parse.y 25 Jun 2020 13:05:58 - 1.102
> +++ parse.y 20 Jul 2020 20:06:53 -
> @@ -344,6 +344,7 @@ struct ipsec_addr_wrap {
> sa_family_t af;
> unsigned int type;
> unsigned int action;
> + uint16_t port;
> char*name;
> struct ipsec_addr_wrap *next;
> struct ipsec_addr_wrap *tail;
> @@ -353,8 +354,6 @@ struct ipsec_addr_wrap {
> struct ipsec_hosts {
> struct ipsec_addr_wrap *src;
> struct ipsec_addr_wrap *dst;
> - uint16_t sport;
> - uint16_t dport;
> };
>
> struct ipsec_filters {
> @@ -649,9 +648,9 @@ hosts : FROM host port TO host port
> {
> err(1, "hosts: calloc");
>
> $$->src = $2;
> - $$->sport = $3;
> + $$->src->port = $3;
> $$->dst = $5;
> - $$->dport = $6;
> + $$->dst->port = $6;
> }
> | TO host port FROM host port {
> struct ipsec_addr_wrap *ipa;
> @@ -667,9 +666,9 @@ hosts : FROM host port TO host port
> {
> err(1, "hosts: calloc");
>
> $$->src = $5;
> - $$->sport = $6;
> + $$->src->port = $6;
> $$->dst = $2;
> - $$->dport = $3;
> + $$->dst->port = $3;
> }
> ;
>
> @@ -2936,14 +2935,14 @@ create_ike(char *name, int af, uint8_t i
> flow->flow_src.addr_af = ipa->af;
> flow->flow_src.addr_mask = ipa->mask;
> flow->flow_src.addr_net = ipa->netaddress;
> - flow->flow_src.addr_port = hosts->sport;
> + flow->flow_src.addr_port = ipa->port;
>
> memcpy(>flow_dst.addr, >address,
> sizeof(ipb->address));
> flow->flow_dst.addr_af = ipb->af;
> flow->flow_dst.addr_mask = ipb->mask;
> flow->flow_dst.addr_net = ipb->netaddress;
> - flow->flow_dst.addr_port = hosts->dport;
> + flow->flow_dst.addr_port = ipb->port;
>
> ippn = ipa->srcnat;
> if (ippn) {
>
--
Антон Касимов / Anton Kasimov
Re: l2ip + ipsec question
On 2020-07-20, kasak wrote: > Hello misc. > Recently, i needed to setup l2tp-ipsec for some ip phones to reach my > network. > > so, the l2tp part is not trouble at all with npppd, but, the ipsec part > is harder to understand. > > after reading ipsec and ipsec.conf man, > > i tryed to add just one line: > > ike passive from my.ga.te.ip to any psk "mykey" > > but this didn't work. > > after some googling, i have found this line: > > ike passive esp transport \ > proto udp from 1.2.3.4 to any port 1701 \ > main auth "hmac-sha1" enc "3des" group modp1024 \ > quick auth "hmac-sha1" enc "aes" \ > psk "password" > > it was found on undeadly.org most endpoints cope wigh slightly less terrible crypto, you can try something like ike passive esp transport \ proto udp from my.external.ip to any port 1701 \ main auth "hmac-sha1" enc "aes-256" group modp2048 \ quick auth "hmac-sha2-256" enc "aes-256" \ psk "0s5jTDcMziOVw3DXZqaGOVlEZyoe8I9c" (psk generated randomly from "openssl rand -base64 (length)", use something complex if you can copy-and-paste to the other devices) > I need help to understand how it even works. > > 1) why does somebody use "transport" here and somebody use "tunnel"? I > myself tryed "transport" and it works. than, what is the difference for > l2tp? "tunnel" adds an extra header to the packet carrying src/dest addresses so ipsec can directly protect packets from other machines. "transport" doesn't have the extra header so ipsec can only carry packets from endpoint to endpoint - but this reduces overheads and increases max usable packet size. the "endpoint-endpoint" traffic can itself be a tunnel as is the case with l2tp. the usual setup for l2tp+ipsec has transport mode to reduce overheads. (both ends need to be set the same way). > 2) ipsec.conf man, says that "esp" is default. But if I omit this > option, it stops working with error like: PAYLOAD_MALFORMED. > > 3) and the most difficult for me to understand: Why does all howto's use > this fragment: > > proto udp from my.ga.te.ip to any port 1701 ?? > > the ipsec.conf man says: from src [port sport] [(srcnat)] to dst [port > dport] > > so, this line declare a tunnel, where our gate use any port, and our > expected remote client use port 1701?? why does this even work? > > Thank you in advance for help! > > > It relies on the fact that l2tp uses a fixed source port, iirc you can use "from my.gate.ip port 1701 to any port 1701" if you want. btw I strongly recommend avoiding l2tp+ipsec if you have another choice. Plain ipsec (ikev1 or ikev2) or other protocols like wireguard/openvpn cope better if you end up on a natted network.
Re: non-checksummed UDP packets
On 2020-07-21, David Gwynne wrote: > > >> On 20 Jul 2020, at 05:30, Stuart Henderson wrote: >> >> On 2020-07-19, obs...@loopw.com wrote: >>> Is this normal? >>> >>> Checksum is OPTIONAL in UDP, not required. This is covered in RFC 768. >> >> For IPv4, anyway. It's required for v6. > > Or is it? > > https://tools.ietf.org/html/rfc6935 oh, thanks IPv6!
