mailrc and muttrc
Hello I use mail in my personal OpenBSD 7.0 without a problem; Opensmtpd only. Now i have a second OpenBSD 7.0 with Opensmtpd + Dovecot + Dkimsign, and i need to collect mail from that server. I tried Mutt, but it fail, Questions: 1. how to configure mail to access an external mail server? 2. How to configure Mutt correctly, it fails sending mail please? My .muttrc: set hostname=mail.consultores.ca set editor=nano set imap_user=a...@consultores.ca set imap_pass="passwd" set folder=imaps://$imap_u...@mail.consultores.ca set spoolfile=+INBOX set imap_check_subscribed set header_cache=~/.cache/mutt set message_cachedir="~/.cache/mutt" unset imap_passive set imap_keepalive=300 set mail_check=180 set record=+Sent set my_pass="passwd" set my_user='a...@consultores.ca' set realname='agro' set from='a...@consultores.ca' set use_from=yes set smtp_pass="passwd" set smtp_url=smtp://$agro:$ag...@consultores.ca:587 set ssl_force_tls=yes set ssl_starttls=no $ openssl s_client -starttls smtp -connect mail.consultores.ca:587 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = consultores.ca verify return:1 140374547838272:error:0407E086:rsa routines:RSA_verify_PKCS1_PSS_mgf1:last octet invalid:../crypto/rsa/rsa_pss.c:88: 140374547838272:error:1417B07B:SSL routines:tls_process_cert_verify:bad signature:../ssl/statem/statem_lib.c:504: --- Certificate chain 0 s:CN = consultores.ca i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 --- Server certificate -BEGIN CERTIFICATE- MIIGYTCCBUmgAwIBAgISBD1nOXs8BJMT17E01SoNp56AMA0GCSqGSIb3DQEBCwUA MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD EwJSMzAeFw0yMjAzMjIxMTE3NTNaFw0yMjA2MjAxMTE3NTJaMBkxFzAVBgNVBAMT DmNvbnN1bHRvcmVzLmNhMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 3R4KmANwxZSr7xQWi504DPEYPBYbskgvPKCKMrQoKOmVlnKMxVg2F132G9C/U2tS BQiunYOdRpyTOhudSoULqfUZS5ZYXcnwlNpiG6LhQcNbPLnURlY/bXDl/Fu4P5a4 wup7Z9TB0iFIsL76fwNvrPT36ynWgOK1pzt5vokElIF2OntgssIf3z4YmkFRup0A VMOQJLhE8RHwt5tPlISuDDVLWMzmCLJ4wxta8fogWZOC/vnDMhIUtEqqoHV3shkr GDOsC+IBLsugHjLKj9+8NnAQT+PR2LUzrvxS57ZqLnnau7nAk5bsaKhAN5JSSKJ4 xvAB7fgtK60do/5G2/62dW4h7AeeStDd2MBo6GFk/lwh1mA3BkHDb0ARG5dVQNav 3vDsMAnFRxqFIwyzx5J4WaRZ7r7VV+Q/+j7146wNjXbxK1LL7S05pE07tRKZ0Oth PWt/b/4dwRiA/9YXdiQUABolrBlhgVZq3F1mgltzVfBtJb8jOOgbki1/YsYFI8xA NQW0KhQj2Z4J88swAfYiFzUXT67/5tTIUS25eHrwQmV6++9ArzSxWwPKJtyfq62x fLkQLUEO669Ul+XhYP+pnw1VeoSsrTO+uFwDtVsx3qBlrgYlZRhzaoYuGqdsIMha XAcJfEP5mshfR5LqCt107cuXpqjWzKXsO+QczmY4HikCAwEAAaOCAogwggKEMA4G A1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYD VR0TAQH/BAIwADAdBgNVHQ4EFgQUeLr0Bp3C9qAG11cdqezlis6MMFYwHwYDVR0j BBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsG AQUFBzABhhVodHRwOi8vcjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6 Ly9yMy5pLmxlbmNyLm9yZy8wVgYDVR0RBE8wTYIOY29uc3VsdG9yZXMuY2GCEmly Yy5jb25zdWx0b3Jlcy5jYYITbWFpbC5jb25zdWx0b3Jlcy5jYYISd3d3LmNvbnN1 bHRvcmVzLmNhMEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgw JgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBBgYKKwYB BAHWeQIEAgSB9wSB9ADyAHcA36Veq2iCTx9sre64X04+WurNohKkal6OOxLAIERc KnMAAAF/sY/qMgAABAMASDBGAiEAq2bGrujJeTE0zxVSPTms+oqHHXkxSIC0TTME YX0p4xQCIQClVwdznCwhWCvC6zuzV7XT9rdM9E8SsoF9CmMjiyCx5QB3ACl5vvCe OTkh8FZzn2Old+W+V32cYAr4+U1dJlwlXceEAAABf7GP6i8AAAQDAEgwRgIhAL1v cQwS8D1NhweV82i186qebCCvS6qhCUgof325YRcoAiEAi5Fyurxjhu30mu9Mb7Dm bd9+WB5mxvJyV6k2hLgAh5cwDQYJKoZIhvcNAQELBQADggEBAFmNjiqgchLRr21v 4rshZ58e/D8KLdmAU4APTtkrVFWf6kFibDzFAkYBsRncGEH/NiRIPXKkvngGSCJr syGxd/8ZlM6g4El/uRHzBijlvPKJDNVJ3ux+uEQWgSkm2evN5QBYiX1W9uqa0CiC oD2UMAXgz+eL53VB0y4S1LC1sA1v5dxc0emyLUX4txs3PR35SYcLYVElUaQutT+X NVJf8yq7DomiYQjbBYhOeSwqFcjesoauNhmfie72NUJ7FbYMOrQE6ExjjdCywASM i7jjSSBUSmAjrA9Q8/M0RIrB+R4Hr3nxESL1vPx3hTZrauWEnXXOw4m6D111piAC OZ7vfos= -END CERTIFICATE- subject=CN = consultores.ca issuer=C = US, O = Let's Encrypt, CN = R3 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 5313 bytes and written 351 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) Thanks
Re: OpenBSD Home Server + Workstation on same machine?
ti 22. maalisk. 2022 klo 5.25 Eric Thomas kirjoitti: > Hello, > > I'd like to learn about secure networking (PKI, x509 certs, DNS, IPS, etc.) > and generally > harden my home network using OpenBSD. Can I use OpenBSD services AND have > it act as a desktop workstation on the same machine? > Hi, My answer is no and yes. This is based on the laziness factor. No part is that sometimes the services may work locally OK but not work from the network. Also it is much nicer to work from the sofa with a laptop and not listen to the server making its noise. The yes part is that it is so nice to have even some real computer to surf when everything seems to be broken and the next step would be to start all over again. It is so nice to start xenodm, login and surf to find the solution to the problem and fix it. if some part of the network configuration is still working. Best regards, Hannu Vuolasaho
Re: OpenBSD Home Server + Workstation on same machine?
On 2022-03-22 16:13:47+0100, ??ukasz Moska??a wrote: > Dnia Mon, Mar 21, 2022 at 08:22:36PM -0700, Eric Thomas napisa??(a): > > Hello, > > > > I'd like to learn about secure networking (PKI, x509 certs, DNS, IPS, etc.) > > and generally > > harden my home network using OpenBSD. Can I use OpenBSD services AND have > > it act as a desktop workstation on the same machine? > > Ref: > > https://superuser.com/questions/1712101/openbsd-home-server-workstation-on-same-machine > > You CAN do that, but you shouldn't. > You should run as little services on firewall as possible. Let's say that > there's bug in browser, that causes machine to hang up. Now, because your > browser had bug, your whole network is down, untill you do hard reboot. OpenBSD's reliability seems to make this very unlikely. Still a valid point, but to be balanced for your needs. I guess there could be hardware issues triggered by a browser? > If someone could exploit bug in browser to gain root access (not very likely, > but still), attacker could see traffic from your entire network, not just > your workstation. > Less services running on firewall means smaller attack surface. Best practice > would be to run only network-related services, like DNS, DHCP, VPNs, IDS/IPS > on firewall, and keep everything else away from it. True there is a smaller attack surface on separate machines, but more other costs (machines to deal with, at least). OpenBSD's mitigations (code auditing, pledge/unveil, and the best track record I have ever heard of in a general-purpose posix OS, etc), plus some other things you can do (which I am learning more about now) to limit what browsers can do to other apps in X, & maybe putting a umask of 0077 in the /etc/profile (but with an exception when running pkg_add), make this less likely enough that using a single machine might be worthwhile for you overall. Especially if learning is the goal, and you are not supporting a huge expensive enterprise or some such. Having an extra machine to test upgrades on before doing it in production can be useful. The other points made (which I didn't quote) could be valid for you. Just $.02.
Re: ipsec traffic is dropped between two machines
On Tue, Mar 22, 2022 at 09:56:49AM -0500, rea...@catastrophe.net wrote:
>Rules on both sides are:
>
># server-east
>--
>pass in proto udp from any to self port { isakmp, ipsec-nat-t } keep state
>pass out proto udp from any to any port { isakmp, ipsec-nat-t } keep state
>
>pass in proto { esp, ah } from any to vio0 keep state
>pass out proto { esp, ah } from vio0 to any keep state
>
>pass on log enc0 keep state (if-bound) tagged VPN.LAX
>pass on log enc0 keep state (if-bound)
[..]
It definitely looks like my issue is the ipsec flows and not pf.
I start a ping on server-east after the ipsec flows are established and
traffic sourcing from server-east vio0 (100.64.1.92) take the default route
and do not get encapsulated when destined for enc0 on server-west
(10.255.255.1):
Flows:
server-east# ipsecctl -sa | grep 10.255.255
flow esp in from 10.255.255.0/24 to 10.254.255.0/24 peer 203.0.113.50 srcid
FQDN/server-east.example.com dstid FQDN/server-west.example.com type require
flow esp in from 10.255.255.0/24 to 100.64.1.92 peer 203.0.113.50 srcid
FQDN/server-east.example.com dstid FQDN/server-west.example.com type require
flow esp out from 10.254.255.0/24 to 10.255.255.0/24 peer 203.0.113.50 srcid
FQDN/server-east.example.com dstid FQDN/server-west.example.com type require
flow esp out from 100.64.1.92 to 10.255.255.0/24 peer 203.0.113.50 srcid
FQDN/server-east.example.com dstid FQDN/server-west.example.com type require
Start generating traffic:
server-east# ping 10.255.255.1 &
[1] 55341
server-east# PING 10.255.255.1 (10.255.255.1): 56 data bytes
Capture packets:
server-east# tcpdump -ni vio0 host 10.255.255.1
tcpdump: listening on vio0, link-type EN10MB
14:58:42.514298 100.64.1.92 > 10.255.255.1: icmp: echo request
14:58:43.514396 100.64.1.92 > 10.255.255.1: icmp: echo request
14:58:44.514326 100.64.1.92 > 10.255.255.1: icmp: echo request
14:58:45.514310 100.64.1.92 > 10.255.255.1: icmp: echo request
14:58:46.514340 100.64.1.92 > 10.255.255.1: icmp: echo request
14:58:47.514263 100.64.1.92 > 10.255.255.1: icmp: echo request
^C
29 packets received by filter
0 packets dropped by kernel
server-east# fg
ping 10.255.255.1
^C
--- 10.255.255.1 ping statistics ---
19 packets transmitted, 0 packets received, 100.0% packet loss
If I source from server-east enc0 (10.254.255.1), then the traffic goes over
the ipsec tunnel:
server-east# ping -c 5 -I 10.254.255.1 10.255.255.1
PING 10.255.255.1 (10.255.255.1): 56 data bytes
64 bytes from 10.255.255.1: icmp_seq=0 ttl=255 time=26.369 ms
64 bytes from 10.255.255.1: icmp_seq=1 ttl=255 time=26.412 ms
64 bytes from 10.255.255.1: icmp_seq=2 ttl=255 time=26.519 ms
64 bytes from 10.255.255.1: icmp_seq=3 ttl=255 time=26.426 ms
64 bytes from 10.255.255.1: icmp_seq=4 ttl=255 time=26.575 ms
--- 10.255.255.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 26.369/26.460/26.575/0.075 ms
Flows from em0 on server-west (203.0.113.50) have no problem when sourcing
from either it's enc0 (10.255.255.1) or em0 (203.0.113.50) interfaces toward
10.254.255.1. Those flows look like this, and they're basically a reverse of
that which is on server-east.
server-west# ipsecctl -sa | grep 10.254.255
flow esp in from 10.254.255.0/24 to 10.255.255.0/24 peer 100.64.1.92 srcid
FQDN/server-west.example.com dstid FQDN/server-east.example.com type require
flow esp in from 10.254.255.0/24 to 203.0.113.50 peer 100.64.1.92 srcid
FQDN/server-west.example.com dstid FQDN/server-east.example.com type require
flow esp out from 10.255.255.0/24 to 10.254.255.0/24 peer 100.64.1.92 srcid
FQDN/server-west.example.com dstid FQDN/server-east.example.com type require
flow esp out from 203.0.113.50 to 10.254.255.0/24 peer 100.64.1.92 srcid
FQDN/server-west.example.com dstid FQDN/server-east.example.com type require
Re: latest amd64 snapshot: Asynchronous wait on fence :Xorg[11217]:16c48 timed out (hint:0xffffffff8121d410s)
On Tue, 22 Mar 2022 15:42:12 +0100 stati...@cryptolab.net wrote: > Le 21/03/2022 à 19:07, Peter N. M. Hansteen a écrit : > > This may be nothing since the system runs fine, but after > > installing the latest amd64 snapshot on my laptop I notice dmesg > > has a sequence of this at the end: > > > > Asynchronous wait on fence :Xorg[11217]:16c48 timed out > > (hint:0x8121d410s) > > Asynchronous wait on fence :Xorg[11217]:170d8 timed out > > (hint:0x8121d410s) > (...) > > > > This is with > > > > OpenBSD 7.1-beta (GENERIC.MP) #424: Sun Mar 20 19:40:39 MDT 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Full dmesg attached. > > > > No obvious ill effects, just odd. > > > > All the best, > > Peter > > > > > > Hei Peter, > > I had this issue for a while using snapshots (by the end of January), > but when I disabled the XFCE compositing function, eveything was fine > again... > > Lykke til! > > Oddmund > I also have this issue on OpenBSD 7.0 when using Xfce (with compositing) and even when switching to cwm (with no compositor). It also had no visible effects, and I was also gonna post it here but I always forgot to :). Full dmesg attached. OpenBSD 7.0 (GENERIC.MP) #5: Mon Jan 31 09:09:02 MST 2022 r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8436883456 (8046MB) avail mem = 8165167104 (7786MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xb9c3f000 (34 entries) bios0: vendor Hewlett-Packard version "68ICF Ver. F.74" date 04/11/2019 bios0: Hewlett-Packard HP EliteBook 8470p acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG SSDT SSDT SLIC MSDM FPDT BGRT SSDT SSDT DMAR ASF! acpi0: wakeup devices LANC(S5) EHC1(S3) EHC2(S3) XHC_(S3) PCIB(S5) RP02(S4) ECF0(S4) RP03(S4) RP04(S5) WNIC(S5) NIC_(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3380M CPU @ 2.90GHz, 2893.86 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3380M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3380M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3380M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEGP) acpiprt2 at acpi0: bus -1 (PCIB) acpiprt3 at acpi0: bus 1 (RP01) acpiprt4 at acpi0: bus 2 (RP02) acpiprt5 at acpi0: bus 35 (RP03) acpiprt6 at acpi0: bus 36 (RP04) acpiec0 at acpi0 "HPQ6001" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 "PNP0A06" at acpi0 not
Re: OpenBSD Home Server + Workstation on same machine?
Dnia Mon, Mar 21, 2022 at 08:22:36PM -0700, Eric Thomas napisał(a): > Hello, > > I'd like to learn about secure networking (PKI, x509 certs, DNS, IPS, etc.) > and generally > harden my home network using OpenBSD. Can I use OpenBSD services AND have > it act as a desktop workstation on the same machine? > > Ref: > https://superuser.com/questions/1712101/openbsd-home-server-workstation-on-same-machine > > Thanks, > Eric Hi Eric, You CAN do that, but you shouldn't. First of all, you most likely overestimate how much resources you need. I used to run pfsense with snort/suricata (can't remember which one) on 3rd gen dual-core i3. You should run as little services on firewall as possible. Let's say that there's bug in browser, that causes machine to hang up. Now, because your browser had bug, your whole network is down, untill you do hard reboot. If someone could exploit bug in browser to gain root access (not very likely, but still), attacker could see traffic from your entire network, not just your workstation. Less services running on firewall means smaller attack surface. Best practice would be to run only network-related services, like DNS, DHCP, VPNs, IDS/IPS on firewall, and keep everything else away from it. Using openbsd as wifi access point is possible, but depending on your network card, it may work well, may work somewhat good, or may not work at all. If you have wifi card laying around, give it a try. If you don't have wifi card laying around, I'd recommend getting seperate AP, as that will give better results. If you want to buy wifi card specifically for openbsd, check in manual if it's supported at all, and if it can work in hostap mode. In my expirience, servers aren't usually a good workstations, as they have crappy GPUs, so for example using web browser may be laggish. Now, why don't you just use your server as a firewall, and use your laptop as a workstation? You can get USB SSD and install openbsd to it, so that it's easy to dual-boot. Also, you could virtualize both workstation and firewall, alongside each other. Keep in mind that to get good graphics performance in VM, you need to allocate entire GPU for it(and then you need another for host, usually integrated will be enough). So beside second GPU, to do gpu passthru, you need CPU that supports VT-d and hypervisor that supports pci passthru (vmware esxi, linux kvm, xcp-ng should work). It's possible, but it's probably the hardest option, and I wouldn't recommend it if you are just starting out. So, all things considered, easiest option would be to use server as firewall, then dualboot laptop as a workstation, or get a cheap second-hand PC. Kind regards, Łukasz
Re: ipsec traffic is dropped between two machines
On Tue, Mar 22, 2022 at 02:38:15AM +, Philipp Buehler wrote:
>Am 21.03.2022 19:04 schrieb rea...@catastrophe.net:
>> The flows look correct in the SA table on server-west and traffic leaves
>> on
>> enc0, hits vio0 on server-east as ESP traffic, but then is dropped.
>> Again,
>> only when I also start a ping on server-east (10.254.255.1) to
>> server-west
>> (10.255.255.1) does the original ping session see replies.
>
>Out of balance / asymmetric rule set not generating needed state.
>
[..]
>Check back your actual interfaces (vio0..) for ESP traffic allowance.
>The '@73' and '@58' already indicates a major difference so check for 'pass
>... proto esp'.
Thanks. There are only differences as one side has other rules for
local access (some web server, etc.).
Rules on both sides are:
# server-east
--
pass in proto udp from any to self port { isakmp, ipsec-nat-t } keep state
pass out proto udp from any to any port { isakmp, ipsec-nat-t } keep state
pass in proto { esp, ah } from any to vio0 keep state
pass out proto { esp, ah } from vio0 to any keep state
pass on log enc0 keep state (if-bound) tagged VPN.LAX
pass on log enc0 keep state (if-bound)
# server-west
--
pass in proto udp from any to self port { isakmp, ipsec-nat-t } keep state
pass out proto udp from any to any port { isakmp, ipsec-nat-t } keep state
pass in proto { esp, ah } from any to em0 keep state
pass out proto { esp, ah } from em0 to any keep state
pass on log enc0 keep state (if-bound) tagged VPN.ORD
pass on log enc0 keep state (if-bound)
Re: ipsec traffic is dropped between two machines
On 2022-03-22, Philipp Buehler wrote: >> server-east PF rule: >> - >> @58 pass log quick on enc0 all flags S/SA tagged VPN.WEST > > enc(4) is an observer interface and not meant to take pf rules besides > "set skip on enc0" :-) I disagree, that's where I hang my "scrub max-mss" rules for tuneLled traffic..
Re: ipsec traffic is dropped between two machines
Problem with service working after cross-pinging the other sides seems like some stateful firewall that needs a nudge from inside. -- Paweł Kraszewski
