Re: supermicro - A2SDV-8C-LN8F
On 11.7.2020. 11:13, mlopenb...@xiphosura.co.uk wrote: > On Sat, 11 Jul 2020 00:13:34 +0200 > Hrvoje Popovski wrote: > >> Hi all, >> >> does anyone have experience or dmesg of this motherboard >> https://www.supermicro.com/en/products/motherboard/A2SDV-8C-LN8F >> >> is it stable? i'm most interested in network performance and network >> cards. in motherboard manual i couldn't find what "Quad LAN with >> Intel® C3000 SoC" means ? is it i350 em(4)? >> >> >> Thank you .. >> > > Hello Hrvoje, > > I am using the smaller but similar Supermicro A2SDi-4C-HLN4F which also > uses thethe Intel C3000 SoC. (In the manual it is described as > "Intel® Atom SoC C3000 Series (FCBGA1310) Processor"). > > I have been using two systems since 6.7 was released (the first to > support the onboard NICs) and they have been perfectly stable. > > I did some testing with a 6.7 pre-release (in March) and using > tcpbench(1) and a direct cable connection I was getting about 940 Mbps > between two systems. > > The onboard NICs are detected as ix(4) "Intel X553 SGMII" > Thank you guys ... i totally forgot that it's ix although it's 1Gbps
Re: Issue with relayd and redirections
After some further troubleshooting, tonight I took some time to sit down and read again the man pages as everything on my config files was looking fine and no errors were showing up in any log. With Brian's help we were leading to the direction that something was wrong with the pf translation itself and so I tested a static rdr-to configuration with pf only in the same environment, and neither this test worked as expected. So I went back to read the pf.conf man page and here comes the rdr-to relevant section: "Redirections cannot reflect packets back through the interface they arrive on, they can only be redirected to hosts connected to different interfaces or to the firewall itself." Focusing on relayd, my oversight was to not going back and read again the pf.conf man page in order to make sure that my box's network configuration was ok, since apparently I got it to work with relays without problems. The next challenge now is to find if there is another way to make this setup working with just 1 network interface and implement relayd redirects for SSL passthrough, or give up. There seems to be few options here that I can think of: - Keep my current configuration with HAproxy - Add another network interface to the box and configure an additional network to it (it might be tricky when deploying a droplet with a direct public IP address) - Migrate to relayd relays and give up with SSL passthrough (with the benefit of SSL offloading if want to implement it) Thank you to the community and the devs for the great work on this OS! Especially on the man pages :) On 2020-07-11 12:58, Gabri Tofano wrote: It isn’t. rdr-to, and by extension redirects, are not natting the source address. Clients connecting through relayd and to the backend will have source addresses not that of the relayd machine but of the original client. Thank you for correcting me on this as it was a bad statement told before getting coffee in the morning :) I’m going to play around on my boxes and try and come up with some options for you. I’ll get back to you later. Thank you for dedicating time in looking to this issue! On 2020-07-11 12:08, Brian Brombacher wrote: On Jul 11, 2020, at 11:20 AM, Gabri Tofano wrote: On 2020-07-11 06:33, Brian Brombacher wrote: On Jul 10, 2020, at 11:42 PM, Gabri Tofano wrote: Does http work with redirects? It wasn’t clear if it did or not in your first post. It doesn't work with http and that is the redirect that I was testing. Indications from your pf anchor rules and the down status above, and the check http attribute on the https forward to directives tell me relayd isn’t liking your check http configuration for port 443. Start by switching to check icmp or check tcp or something else, see if it works, unless you can fix the check http based on logs or otherwise. I changed it to tcp and now the servers are showing as "up": LAB1-LB1# relayctl sh sum Id TypeNameAvlblty Status 1 redirecthttp active 1 table web_servers:80 active (1 hosts) 1 host172.16.101.31 100.00% up 2 table nc_servers:80 active (1 hosts) 2 host172.16.101.32 100.00% up 2 redirecthttps active 3 table web_servers:443 active (1 hosts) 3 host172.16.101.31 100.00% up 4 table nc_servers:443 active (1 hosts) 4 host172.16.101.32 100.00% up However I was hoping to fix the http redirect first and then move to https, but it looks like more of a "general issue" with redirects in my current configuration. Thanks If http redirection isn’t working, I’d be curious from where you’re trying to connect or what router you have configured on the backend hosts. I see you’re relayd box and back ends are on the same network. If you’re trying to connect from another address in 172.16.101.x to your relayd setup, it won’t work reliably. It might also not work reliably or at all, if you are not routing responses through the relayd host. If they are replying direct, any PF scrub normalization, tcp sequence handling, etc., all get lost, among other issues. I hope this is the cause of your issues, otherwise you’re going to need to include more information for your setup, or at a minimum some relayd logs. -Brian I have a layer3 switch doing routing between 2 vlans, relayd and the 2 backend web servers are on the same vlan and the client is on another vlan 172.16.100.x. The relayd VM is configured with only 1 network interface. When the client try to reach the web servers directly everything work fine. When the client is passing through relayd I see the
Re: sysupgrade failure due to boot.conf
> Figure out how to build and install. It is not hard to test.
I attempted over the weekend and I'm trying but my new code is not taking.
I am using 6.6 release source code and it looks like I'm doing the right
steps but when I reboot UEFI I still see the old boot not my new HelloBoot
that I installed.
Here are my steps:
# uname -a
OpenBSD upgrade.lan 6.6 GENERIC.MP#372 amd64
# fdisk sd0
Disk: sd0 Usable LBA: 64 to 976773104 [976773168 Sectors]
#: type [ start: size ]
1: EFI Sys [ 64: 960 ]
3: OpenBSD [1024:976772081 ]
# cd /usr/src/sys/arch/amd64/stand/boot/
# diff -u boot.c~ boot.c
--- boot.c~ Sun Jul 12 06:22:46 2020
+++ boot.c Sun Jul 12 06:23:04 2020
@@ -66,7 +66,7 @@
machdep();
snprintf(prog_ident, sizeof(prog_ident),
- ">> OpenBSD/" MACHINE " %s %s", progname, version);
+ ">> HelloBoot/" MACHINE " %s %s", progname, version);
printf("%s\n", prog_ident);
devboot(bootdev, cmd.bootdev);
# make
...
# make install
install -c -s -o root -g bin -m 555 boot /usr/mdec/boot
BFD: /usr/mdec/sttIyjey: warning: allocated section `.bss' not in segment
install -c -o root -g bin -m 444 boot.8 /usr/share/man/man8/amd64/boot.8
# installboot -v sd0
Using / as root
installing bootstrap on /dev/rsd0c
using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
copying /usr/mdec/BOOTIA32.EFI to
/tmp/installboot.F3tHu75peT/efi/BOOT/BOOTIA32.EFI
copying /usr/mdec/BOOTX64.EFI to
/tmp/installboot.F3tHu75peT/efi/BOOT/BOOTX64.EFI
#reboot
when I reboot I see "OpenBSD/amd64" not "HelloBoot/amd64"
-alfred
Re: sysupgrade failure due to boot.conf
Brian wrote: > (echo boot /bsd.upgrade; echo boot) > /etc/boot.conf Brian, that doesn't work. I tried that already before. It seems to stop at the error not finding bsd.upgrade and won't continue. -alfred
awk segfaults on RS regexp
This is current/amd64.
On UTF input, awk segfaults when using a multi-character RS:
$ cat /tmp/in
č
$ hexdump -C /tmp/in
c4 8d 0a |...|
0003
$ cat /tmp/in | awk '{print$1}'
č
$ cat /tmp/in | awk -v RS=x '{print$1}'
č
$ cat /tmp/in | awk -v RS=xy '{print$1}'
Segmentation fault (core dumped)
See the debug (awk -d3) output below.
It does not happen with plain ascii input.
If happens reproducibly if the input contains an UTF char.
According to the manpage,
RS Input record separator (default newline).
If empty, blank lines separate records.
If more than one character long, RS is treated
as a regular expression, and records are separated
by text matching the expression.
So I *speculate* that the regexp matching is what breaks
when matching against non-ascii input; that's a bit over my head,
but the last debug message before the segfault is "reparse ".
Jan
Script started on Mon Jul 13 12:58:39 2020
hans@biblio:~$ cat /tmp/in | awk -d3 -v RS=xy '{print$1}'
awk version 20200702
setsymtab set 0x1e34d6ca8e00: n=RS s="xy" f=0 t=2
starting setsval 0x1e34d6ca8e00: RS = "xy", t=2, r,f=0,0
setsval 0x1e34d6ca8e00: RS = "xy (0x1e34deeddd10) ", t=2 r,f=0,0
command line set RS to |xy|
program = |{print$1}|
setsymtab set 0x1e34d256d0c0: n=0 s="0" f=0 t=17
setsymtab set 0x1e34d256d840: n=$zero&null s="" f=0 t=17
setsymtab set 0x1e34d6ca8a00: n=FS s=" " f=0 t=6
setsymtab found 0x1e34d6ca8e00: n=RS s="xy" f=0 t=2
setsymtab set 0x1e3479030080: n=OFS s=" " f=0 t=6
setsymtab set 0x1e3479030c00: n=ORS s="
" f=0 t=6
setsymtab set 0x1e34d256d340: n=OFMT s="%.6g" f=0 t=6
setsymtab set 0x1e34e3d38cc0: n=CONVFMT s="%.6g" f=0 t=6
setsymtab set 0x1e34e3d38e00: n=FILENAME s="" f=0 t=6
setsymtab set 0x1e34d256d780: n=NF s="" f=0 t=1
setsymtab set 0x1e34790308c0: n=NR s="" f=0 t=1
setsymtab set 0x1e34d6ca84c0: n=FNR s="" f=0 t=1
setsymtab set 0x1e34d6ca8980: n=SUBSEP s=" " f=0 t=6
setsymtab set 0x1e34e3d38040: n=RSTART s="" f=0 t=1
setsymtab set 0x1e34d256d4c0: n=RLENGTH s="" f=0 t=1
setsymtab set 0x1e34d256d900: n=SYMTAB s="" f=0 t=20
argc=1, argv[0]=awk
setsymtab set 0x1e34d6ca89c0: n=ARGC s="" f=1 t=1
setsymtab set 0x1e34e3d38d80: n=ARGV s="" f=0 t=20
setsymtab set 0x1e34d256d280: n=0 s="awk" f=0 t=2
setsymtab set 0x1e34d256dc80: n=ENVIRON s="" f=0 t=20
setsymtab set 0x1e3479030680: n=_ s="/usr/bin/awk" f=0 t=2
setsymtab set 0x1e34e3d38100: n=LOGNAME s="hans" f=0 t=2
setsymtab set 0x1e34d256db00: n=WINDOWID s="60817421" f=6.08174e+07 t=3
setsymtab set 0x1e3479030640: n=XTERM_SHELL s="/bin/ksh" f=0 t=2
setsymtab set 0x1e34e3d38ac0: n=HOME s="/home/hans" f=0 t=2
setsymtab set 0x1e34d256d880: n=CVSROOT s="anon...@mirror.osn.de:/cvs" f=0 t=2
setsymtab set 0x1e34e3d38740: n=XTERM_VERSION s="XTerm/OpenBSD(351)" f=0 t=2
setsymtab set 0x1e34d256d400: n=LC_MONETARY s="C" f=0 t=2
setsymtab set 0x1e34d6ca8dc0: n=LANG s="C" f=0 t=2
setsymtab set 0x1e34d256d100: n=MANPATH
s="/home/hans/man:/usr/local/man:/usr/share/man:/usr/X11R6/man" f=0 t=2
setsymtab set 0x1e3479030d80: n=SSH_AUTH_SOCK
s="/tmp/ssh-IQXXB2Cn9jHz/agent.92135" f=0 t=2
setsymtab set 0x1e34790300c0: n=PAGER s="less" f=0 t=2
setsymtab set 0x1e34d256d8c0: n=CVS_RSH s="ssh" f=0 t=2
setsymtab set 0x1e34d6ca8480: n=SHELL s="/bin/ksh" f=0 t=2
setsymtab set 0x1e34d256de80: n=PS1 s="\u@\h:\W$ " f=0 t=2
setsymtab set 0x1e34e3d38880: n=TERM s="xterm-color" f=0 t=2
setsymtab set 0x1e34e3d38b40: n=XTERM_LOCALE s="cs_CZ.UTF-8" f=0 t=2
setsymtab set 0x1e34e3d386c0: n=LC_NUMERIC s="C" f=0 t=2
setsymtab set 0x1e34d6ca8a80: n=WINDOWPATH s="ttyC4" f=0 t=2
setsymtab set 0x1e3479030dc0: n=PWD s="/home/hans" f=0 t=2
setsymtab set 0x1e34e3d38a00: n=XENVIRONMENT s="/home/hans/.Xresources" f=0 t=2
setsymtab set 0x1e34790302c0: n=LC_CTYPE s="en_US.UTF-8" f=0 t=2
setsymtab set 0x1e3479030e40: n=DISPLAY s=":0" f=0 t=2
setsymtab set 0x1e34e3d38440: n=LESS s="-g -i -M -R" f=0 t=2
setsymtab set 0x1e3479030b40: n=SSH_AGENT_PID s="86537" f=86537 t=3
setsymtab set 0x1e34d6ca8b40: n=LC_TIME s="C" f=0 t=2
setsymtab set 0x1e34d6ca8f40: n=BASH_ENV s="/home/hans/.shrc" f=0 t=2
setsymtab set 0x1e3479030c40: n=LC_MESSAGES s="C" f=0 t=2
setsymtab set 0x1e34d256dbc0: n=ENV s="/home/hans/.shrc" f=0 t=2
setsymtab set 0x1e3479030c80: n=PATH
s="/home/hans/bin:/home/hans/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin"
f=0 t=2
setsymtab set 0x1e34d6ca8ec0: n=HISTFILE s="/home/hans/.history" f=0 t=2
setsymtab set 0x1e34d256dd80: n=USER s="hans" f=0 t=2
lex token 123
adjbuf gettok: 5 100 (pbuf=0x1e34deedd500, tbuf=0x1e34de2a3480)
lex PRINT
lex INDIRECT
setsymtab set 0x1e34e3d38e40: n=1 s="1" f=1 t=11
lex NUMBER
lex token 59
lex token 125
errorflag=0
RS=, FS=< >, ARGC=1, FILENAME=
getsval 0x1e34d6ca8a00: FS = " (0x1e34f11bd350)", t=6
argno=1, file=||
getsval 0x1e34d6ca8e00: RS = "xy (0x1e34deeddd10)", t=2
reparse
Segmentation fault (core dumped)
hans@bibli
Re: sysupgrade failure due to boot.conf
I wrote: > I attempted over the weekend and I'm trying but my new code is not taking. > when I reboot I see "OpenBSD/amd64" not "HelloBoot/amd64" I figured out the issue. I need to compile efiboot separately. # cd /usr/src/sys/arch/amd64/stand/efiboot/ # make # make install ... This did the trick. I see my expected HelloBoot so I can continue with my deep dive. -alfred
sndiod mostly required
The following paragraph from sndio(7) probably no longer applies as is: DEFAULTS If default is used as the audio device, the program will use the one specified in the AUDIODEVICE environment variable. If it is not set, the program first tries to connect to snd/0. If that fails, it then tries to use rsnd/0. This allows the sndiod(8) audio server to be used by default and the raw hardware as fallback; programs don't have to be reconfigured when sndiod(8) is started or stopped. With the recent audio(4)/midi(4) change (as described at http://www.openbsd.org/faq/upgrade67.html) users cannot access the raw devices any more, so e.g. $ aucat -o /tmp/file.wav ^C $ doas rcctl stop sndiod sndiod(ok) $ aucat -o /tmp/file.wav default: couldn't open audio device instead of falling back to rsnd/0. (I'll leave the rewording to Alexandre.) Jan
Re: awk segfaults on RS regexp
On Mon, 13 Jul 2020 13:02:44 +0200, Jan Stary wrote:
> This is current/amd64.
>
> On UTF input, awk segfaults when using a multi-character RS:
>
> $ cat /tmp/in
> č
>
> $ hexdump -C /tmp/in
> c4 8d 0a|...|
> 0003
>
> $ cat /tmp/in | awk '{print$1}'
> č
>
> $ cat /tmp/in | awk -v RS=x '{print$1}'
> č
>
> $ cat /tmp/in | awk -v RS=xy '{print$1}'
> Segmentation fault (core dumped)
Nice catch. The actual bug is caused by using a signed char as an
index into an array, resulting in a negative index. Once debugged,
the fix is simple.
- todd
diff --git a/b.c b/b.c
index c167b50..f7fbc0e 100644
--- a/b.c
+++ b/b.c
@@ -684,7 +684,7 @@ bool fnematch(fa *pfa, FILE *f, char **pbuf, int *pbufsize,
int quantum)
FATAL("stream '%.30s...' too
long", buf);
buf[k++] = (c = getc(f)) != EOF ? c : 0;
}
- c = buf[j];
+ c = (unsigned char)buf[j];
/* assert(c < NCHARS); */
if ((ns = pfa->gototab[s][c]) != 0)
Installation problem on Fujitsu RX1330M4
Hi all, we have new Fujitsu RX1330M4 machines here. When I try to boot the install67.iso (cd) or the install67.fs (usb) the installaiotn media is not recognized by the system and therefore i can not select the media in the boot menu of the bios. My installation medias work as expected on normal pc hardware. Also no chance to boot the install kernel with a virtual cd (install67.iso) via the iRMC management system of the server. (secure boot config is disabled in the bios options). I’ve also installed a linux system (opensuse) and tried to boot the bsd.rd with the grub command line but it is doing a reboot only and therefore starting the grub again without starting the bsd install-kernel. Has anyone an idea or experience with installing on newer Fujitsu systems ? Regards Martin
Re: Installation problem on Fujitsu RX1330M4
On 13/07/2020, martin.scha...@l-bank.de wrote: > Hi all, > > we have new Fujitsu RX1330M4 machines here. When I try to boot the > install67.iso (cd) or the install67.fs (usb) the installaiotn media is not > recognized by the system and therefore i can not select the media in the > boot menu of the bios. > My installation medias work as expected on normal pc hardware. Also no > chance to boot the install kernel with a virtual cd (install67.iso) via the > iRMC management system of the server. (secure boot config is disabled in the > bios options). > > I’ve also installed a linux system (opensuse) and tried to boot the bsd.rd > with the grub command line but it is doing a reboot only and therefore > starting the grub again without starting the bsd install-kernel. > > Has anyone an idea or experience with installing on newer Fujitsu systems ? > > Regards > Martin > Presumably you've tried setting the USB to legacy or auto in the bios?
how to mount phone?
Hi, Just wishing to mount my phone to access photos. Here's the output from dmesg: ugen0 at uhub0 port 3 "Alcatel U50? Alcatel U50?" rev 2.00/3.10 addr 2 Any ideas on how this might be mounted?? tia!
Re: how to mount phone?
Have you set your USB preferences on your phone? To File transfer? My Android defaults to charging only. On Mon, Jul 13, 2020 at 2:57 PM Justin Muir wrote: > Hi, > > Just wishing to mount my phone to access photos. > > Here's the output from dmesg: > > ugen0 at uhub0 port 3 "Alcatel U50? Alcatel U50?" rev 2.00/3.10 addr 2 > > Any ideas on how this might be mounted?? > > > tia! >
Re: Issue with relayd and redirections
> On Jul 13, 2020, at 8:30 PM, Gabri Tofano wrote:
>
> I have tried to implement the workaround as per man page
> but it still doesn't work, here the pf.conf config:
>
> eth0 = "xnf0"
> web1 = "172.16.101.31"
>
> anchor "relayd/*"
>
> set skip on lo
>
> block return log
> pass log
>
> pass out quick on $eth0 proto tcp to $web1 port 80 \
> received-on $eth0 nat-to $eth0
Try putting this before the anchor. The quick entry in the anchor that relayd
creates takes precedence.
>
> block return in on ! lo0 proto tcp to port 6000:6010
> block return out log proto {tcp udp} user _pbuild
>
>
> I'm trying to gather some useful log on relayd and see if
> there's any error but even with "relayctl log verbose"
> nothing is showing beside the startup entries
>
> Thank you!
>
>> There's a "workaround" also mentioned in pf.conf(5) which also works
>> with relayd inserted rdr-rules, e.g.
>> pass out quick on vlan99 proto tcp to 192.168.89.13 received-on vlan99
>> nat-to 192.168.89.1
>> vlan99 has 'inet 192.168.89.1/24' and 192.168.89.13 is the relayd rdr
>> "target".
>> HTH,
>> --
>> pb
>>> On 2020-07-13 01:08, Gabri Tofano wrote:
>> After some further troubleshooting, tonight I took some time to sit down and
>> read again the man pages as everything on my config files was looking fine
>> and
>> no errors were showing up in any log. With Brian's help we were leading to
>> the
>> direction that something was wrong with the pf translation itself and so I
>> tested a static rdr-to configuration with pf only in the same environment,
>> and
>> neither this test worked as expected. So I went back to read the pf.conf man
>> page and here comes the rdr-to relevant section:
>> "Redirections cannot reflect packets back through the interface they
>> arrive on, they can only be redirected to hosts connected to different
>> interfaces or to the firewall itself."
>> Focusing on relayd, my oversight was to not going back and read again the
>> pf.conf man page in order to make sure that my box's network configuration
>> was
>> ok, since apparently I got it to work with relays without problems.
>> The next challenge now is to find if there is another way to make this setup
>> working with just 1 network interface and implement relayd redirects for SSL
>> passthrough, or give up. There seems to be few options here that I can think
>> of:
>> - Keep my current configuration with HAproxy
>> - Add another network interface to the box and configure an additional
>> network to
>> it (it might be tricky when deploying a droplet with a direct public IP
>> address)
>> - Migrate to relayd relays and give up with SSL passthrough (with the
>> benefit of
>> SSL offloading if want to implement it)
>> Thank you to the community and the devs for the great work on this OS!
>> Especially
>> on the man pages :)
>> On 2020-07-11 12:58, Gabri Tofano wrote:
It isn’t. rdr-to, and by extension redirects, are not natting the source
address.
Clients connecting through relayd and to the backend will have source
addresses
not that of the relayd machine but of the original client.
>>> Thank you for correcting me on this as it was a bad statement told before
>>> getting coffee in the morning :)
I’m going to play around on my boxes and try and come up with some options
for you.
I’ll get back to you later.
>>> Thank you for dedicating time in looking to this issue!
>>> On 2020-07-11 12:08, Brian Brombacher wrote:
>> On Jul 11, 2020, at 11:20 AM, Gabri Tofano wrote:
> On 2020-07-11 06:33, Brian Brombacher wrote:
>>> On Jul 10, 2020, at 11:42 PM, Gabri Tofano
>>> wrote:
>
>> Does http work with redirects? It wasn’t clear if it did or not in
>> your first post.
> It doesn't work with http and that is the redirect that I was testing.
>> Indications from your pf anchor rules and the down
>> status above, and the check http attribute on the https forward to
>> directives tell me relayd isn’t liking your check http configuration
>> for port 443.
>> Start by switching to check icmp or check tcp or something else, see
>> if it works, unless you can fix the check http based on logs or
>> otherwise.
> I changed it to tcp and now the servers are showing as "up":
> LAB1-LB1# relayctl sh sum
> Id TypeNameAvlblty Status
> 1 redirecthttpactive
> 1 table web_servers:80
> active (1 hosts)
> 1 host172.16.101.31 100.00% up
> 2 table nc_servers:80
> active (1 hosts)
> 2 host172.16.101.32 100.00% up
> 2 redirecthttps act
Re: Issue with relayd and redirections
I have tried to implement the workaround as per man page
but it still doesn't work, here the pf.conf config:
eth0 = "xnf0"
web1 = "172.16.101.31"
anchor "relayd/*"
set skip on lo
block return log
pass log
pass out quick on $eth0 proto tcp to $web1 port 80 \
received-on $eth0 nat-to $eth0
block return in on ! lo0 proto tcp to port 6000:6010
block return out log proto {tcp udp} user _pbuild
I'm trying to gather some useful log on relayd and see if
there's any error but even with "relayctl log verbose"
nothing is showing beside the startup entries
Thank you!
There's a "workaround" also mentioned in pf.conf(5) which also works
with relayd inserted rdr-rules, e.g.
pass out quick on vlan99 proto tcp to 192.168.89.13 received-on vlan99
nat-to 192.168.89.1
vlan99 has 'inet 192.168.89.1/24' and 192.168.89.13 is the relayd rdr
"target".
HTH,
--
pb
On 2020-07-13 01:08, Gabri Tofano wrote:
After some further troubleshooting, tonight I took some time to sit
down and
read again the man pages as everything on my config files was looking
fine and
no errors were showing up in any log. With Brian's help we were leading
to the
direction that something was wrong with the pf translation itself and
so I
tested a static rdr-to configuration with pf only in the same
environment, and
neither this test worked as expected. So I went back to read the
pf.conf man
page and here comes the rdr-to relevant section:
"Redirections cannot reflect packets back through the interface they
arrive on, they can only be redirected to hosts connected to different
interfaces or to the firewall itself."
Focusing on relayd, my oversight was to not going back and read again
the
pf.conf man page in order to make sure that my box's network
configuration was
ok, since apparently I got it to work with relays without problems.
The next challenge now is to find if there is another way to make this
setup
working with just 1 network interface and implement relayd redirects
for SSL
passthrough, or give up. There seems to be few options here that I can
think of:
- Keep my current configuration with HAproxy
- Add another network interface to the box and configure an additional
network to
it (it might be tricky when deploying a droplet with a direct public IP
address)
- Migrate to relayd relays and give up with SSL passthrough (with the
benefit of
SSL offloading if want to implement it)
Thank you to the community and the devs for the great work on this OS!
Especially
on the man pages :)
On 2020-07-11 12:58, Gabri Tofano wrote:
It isn’t. rdr-to, and by extension redirects, are not natting the
source address.
Clients connecting through relayd and to the backend will have source
addresses
not that of the relayd machine but of the original client.
Thank you for correcting me on this as it was a bad statement told
before
getting coffee in the morning :)
I’m going to play around on my boxes and try and come up with some
options for you.
I’ll get back to you later.
Thank you for dedicating time in looking to this issue!
On 2020-07-11 12:08, Brian Brombacher wrote:
On Jul 11, 2020, at 11:20 AM, Gabri Tofano
wrote:
On 2020-07-11 06:33, Brian Brombacher wrote:
On Jul 10, 2020, at 11:42 PM, Gabri Tofano
wrote:
Does http work with redirects? It wasn’t clear if it did or
not in
your first post.
It doesn't work with http and that is the redirect that I was
testing.
Indications from your pf anchor rules and the down
status above, and the check http attribute on the https forward
to
directives tell me relayd isn’t liking your check http
configuration
for port 443.
Start by switching to check icmp or check tcp or something
else, see
if it works, unless you can fix the check http based on logs or
otherwise.
I changed it to tcp and now the servers are showing as "up":
LAB1-LB1# relayctl sh sum
Id TypeNameAvlblty
Status
1 redirecthttp
active
1 table web_servers:80
active (1 hosts)
1 host172.16.101.31 100.00%
up
2 table nc_servers:80
active (1 hosts)
2 host172.16.101.32 100.00%
up
2 redirecthttps
active
3 table web_servers:443
active (1 hosts)
3 host172.16.101.31 100.00%
up
4 table nc_servers:443
active (1 hosts)
4 host172.16.101.32 100.00%
up
However I was hoping to fix the http redirect first and then
move to https, but it
looks like more of a "general issue" with redirects in my
current configuration.
Thanks
If http redirection isn’t working, I’d be curious from where you’re
trying to connect or what router you have configured on the backend
hosts
