Re: relayd redirect not working

[Michael W. Lucas]

Thanks.

Look at the PF rules in the relayd table. See what's redirecting from
where to what.

If that all looks ok, there's always tcpdump...

On Wed, Mar 15, 2017 at 11:42:32PM -0700, Dave Cohen wrote:
> Michael,
> 
> Appreciate you chiming in.  I'm a fan of Absolute OpenBSD!
> 
> I'm having trouble reproducing the settings that I originally wrote about.  
> I've tried to restore /etc/relayd.conf and /etc/pf.conf to what they were 
> when I wrote the email.  But right now, neither port 80 nor 443 are 
> redirecting to the other ports.  Earlier, port 80 was working while 443 was 
> not.  I'm at a loss as to why the behavior is not the same as before.
> 
> Despite that trouble, I tried the commands you suggested.  `relayd -dvvv` 
> shows
> 
> $ doas relayd -dvvv
> startup
> socket_rlimit: max open files 1024
> init_filter: filter init done
> init_tables: created 2 tables
> socket_rlimit: max open files 1024
> socket_rlimit: max open files 1024
> socket_rlimit: max open files 1024
> hce_notify_done: 127.0.0.1 (icmp ok)
> host 127.0.0.1, check icmp (32ms,icmp ok), state unknown -> up, availability 
> 100.00%
> pfe_dispatch_hce: state 1 for host 1 127.0.0.1
> hce_notify_done: 127.0.0.1 (icmp ok)
> host 127.0.0.1, check icmp (33ms,icmp ok), state unknown -> up, availability 
> 100.00%
> pfe_dispatch_hce: state 1 for host 2 127.0.0.1
> table https: 1 added, 0 deleted, 0 changed, 0 killed
> pfe_sync: enabling ruleset
> sync_ruleset: rule added to anchor "relayd/https"
> hce_notify_done: 127.0.0.1 (icmp ok)
> hce_notify_done: 127.0.0.1 (icmp ok)
> table http: 1 added, 0 deleted, 0 changed, 0 killed
> pfe_sync: enabling ruleset
> sync_ruleset: rule added to anchor "relayd/http"
> hce_notify_done: 127.0.0.1 (icmp ok)
> hce_notify_done: 127.0.0.1 (icmp ok)
> hce_notify_done: 127.0.0.1 (icmp ok)
> ...etc...
> 
> and `relayctl sho sum`
> 
> $ relayctl sho sum
> Id  TypeNameAvlblty Status
> 1   redirecthttps   active
> 1   table   httpshosts:8443 active (1 
> hosts)
> 1   host127.0.0.1   100.00% up
> 2   redirecthttpactive
> 2   table   httpshosts:8080 active (1 
> hosts)
> 
> 
> -Dave
> 
> On Sun, Mar 12, 2017, at 03:16 PM, Michael W. Lucas wrote:
> > On Sun, Mar 12, 2017 at 09:26:53AM +0100, Salvatore Cuzzilla wrote:
> > > Ciao Dave,
> > > 
> > > I'm also playing with relayd as a L7 gateway and as far as I can see from 
> > > your
> > > config there is no CA and key configured. In order for HTTPS to work 
> > > relayd
> > > needs to be able to do TLS inspection and of course you should redirect 
> > > all
> > > your https traffic to port 8443 (using PF for example). If you check the
> > > pf.conf man page under both the sections RELAYS and Examples you should be
> > > able to find a lot of good hints.
> > 
> > He's using a redirect, not a relay, so it should work just fine. No L7
> > stuff here, only low-level IP.
> > 
> > Dave, looks OK to me. What does relayd -dvvv say? And relayctl sho sum ?
> > 
> > -- 
> > Michael W. LucasTwitter @mwlauthor 
> > nonfiction: https://www.michaelwlucas.com/
> > fiction: https://www.michaelwarrenlucas.com/
> > blog: http://blather.michaelwlucas.com/

-- 
Michael W. LucasTwitter @mwlauthor 
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
blog: http://blather.michaelwlucas.com/

PPPoE disconnecting frequently

[Nicholas Bachmann]

Hi all,

I’m having a problem where PPPoE disconnects every 6-7 minutes. I’m
originally saw this in 5.9; I then upgraded to 6.0 but still have the
same issue.

If I run “ifconfig pppoe0 up” right after it disconnects, it comes
right back up again. I have a ddwrt box that can successfully keep
this same PPPoE connection up without these disconnects, so I don’t
think the problem is related to the ISP equipment.

My hostname.pppoe0 looks like:

inet 0.0.0.0 255.255.255.255 NONE \
  pppoedev em0 authproto pap peerproto chap \
  authname ‘username’ authkey ‘mypassword’ up
dest 0.0.0.1
!/sbin/route add default -ifp pppoe0 0.0.0.1

In dmesg and /var/log/messages, I see only this:
Mar 17 04:02:42 greatwall /bsd: pppoe0: LCP keepalive timeout

I ran tcpdump, and this is all the pppoe traffic I see:
04:09:07.070988 Echo-Request, Magic-Number=1174906872
04:09:07.070995 Echo-Reply, Magic-Number=1072546934
04:09:09.231366 Configure-Request, Interface-ID=0225:baff:fe7a:03fd
04:09:09.231378 Configure-Ack, Interface-ID=0225:baff:fe7a:03fd
04:09:12.331417 Configure-Request, Interface-ID=0225:baff:fe7a:03fd
04:09:12.331430 Configure-Ack, Interface-ID=0225:baff:fe7a:03fd
04:09:15.631510 Configure-Request, Interface-ID=0225:baff:fe7a:03fd
04:09:15.631522 Configure-Ack, Interface-ID=0225:baff:fe7a:03fd
04:09:32.308186 Echo-Request, Magic-Number=1072546934
04:09:42.310549 Echo-Request, Magic-Number=1072546934
04:09:52.312791 Echo-Request, Magic-Number=1072546934
04:10:02.315637 Terminate-Request
04:10:02.342731 Configure-Request, Magic-Number=849593138,
Max-Rx-Unit=1492, Auth-Prot CHAP/MD5[|lcp]
04:10:02.390879 Configure-Request, Max-Rx-Unit=1492, Auth-Prot PAP,
Magic-Number=535689543, Vendor-Ext
04:10:02.390889 Configure-Ack, Max-Rx-Unit=1492, Auth-Prot PAP,
Magic-Number=535689543[|lcp]
04:10:02.390995 Configure-Reject, Auth-Prot CHAP/MD5, Vendor-Ext
04:10:02.391001 Terminate-Request
04:10:02.392061 Terminate-Ack

This isn't much to go on so I’d be grateful for any suggestions about
where to troubleshoot this further.

Thanks,
Nick

Re: Isakmpd and NAT-T

[Mik J]

Hello Sebastien,Why "group none" for phase 2 ?
"     The following group types are permitted with the group keyword:
           Group       Size
           none        0       [phase 2 only]
"

maybe you should ask them their conf and their logs
Try alsosysctl -a | grep esp



Le Jeudi 16 mars 2017 16h33, Sébastien Morand  a
écrit :


 Hi Mike and everybody,

Thank you Mike for your answer. There is nothing more like you said.
Actually we succeed in phase 1 but not in phase 2.

My client give me the following spec:
Phase 1: SHA1 - 160 bits / DH 5 / Authentication with PSK / CIPHER :
AES-256 / Lifetime 86400s
Phase 2: Tunnel mode / SHA1 / No PFS / Authentication with PSK / CIPHER
AES-128 / Lifetime 3600s

So I end up with the following in ipsec.conf:
ike active esp tunnel \
    from 10.85.98.16/29 to \
        {10.249.0.0/21} \
    peer  \
    main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
    quick auth hmac-sha1 enc aes-128 group none lifetime 3600 \
    srcid "" \
    psk ""

I'm starting the ipsec like this :
isakmpd -Kdvvv (to see what is happening)
and
ipsecctl -f /etc/ipsec.conf

It's look like good to me and conform to the provided specs. Phase 1 is ok
but no phase 2:
155851.640374 Default ipsec_validate_id_information: dubious ID information
accepted
155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154,
responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142
155918.682560 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-10.249.0.0/21, no response from peer
80.125.165.142:4500
155918.682611 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-80.125.172.0/23, no response from peer
80.125.165.142:4500
155918.682644 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-80.125.174.0/24, no response from peer
80.125.165.142:4500

In TCPDUMP I got no answer on port 4500 (but everything fine on port 500)
so it means to me they don't answer to my packet but I don't know why :
16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:41.673655 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:41.673674 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686803 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686862 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686881 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700016 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700106 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700154 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
(... it can last forever ...)

Any idea what can be done or a way to get more information on what's going
on? They are using CISCO 6509 with IOS 12.2-33.SXH3a.

Thanks by advance,
Sebastien

On Tue, Mar 14, 2017 at 12:46 AM, Mik J  wrote:

> Hello Sebastien,
> I'm not sure there's something special to force nat-t, it's automatic.
> The natted side has to initiate the flow to the non natted side.
> If the two sides are natted then there should be a port forward to one of
> them.
> There should be a nat keepalive parameter as well.
>
>
>
> Le Lundi 13 mars 2017 18h40, Sébastien Morand  a
> écrit :
>
>
> Hi,
>
> I'm trying to set up a NAT-T IPSec VPN with one of my client.
>
> Is this configuration ok on ipsec.conf for NAT-T?
> ike esp \
>    from 10.85.98.16/29 to {10.249.0.0/21} \
>    peer  \
>    main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
>    quick auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
>    srcid "" \
>    psk ""
>
> Something else to force NAT-T?
> Thanks by advance,
> Sébastien

Re: how to debug OpenBSD virtio-scsi killing qemu-kvm VM?

[Stefan Fritsch]

On Tuesday, 14 March 2017 20:16:17 CET Jiri B wrote:
> Recent dmesg, and VM exits because of virtio-scsi issue when it is
> installing 'bsd.mp'.

I think I have fixed all the bugs, at least I could not get any corruption any 
more. The changes are in -current, in r1.5 of sys/dev/pv/vioscsi.c . Please 
try if that fixes your problems.

Cheers,
Stefan

Re: Setting rtable 0 from >1 with ping et al

[Joe Holden]

On 09/03/2017 23:35, Joe Holden wrote:

On 09/03/2017 23:02, Joe Holden wrote:

Hi,

So - it seems that pledge will deny a change of rtable to 0 when using
level SOL_SOCKET and the current rtable is >0, so eg if you're in table
1 and you do ping -V0 it will fail.

Can anyone shed any light on why this is restricted?  Especially since
the same can be achieved with route -T0 exec

Thanks!


Actually, just realised why it doesn't work - it drops privs before
setting rtable, nevermind.


Something like:

Index: sbin/ping/ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.218
diff -u -p -r1.218 ping.c
--- sbin/ping/ping.c22 Feb 2017 13:43:35 -  1.218
+++ sbin/ping/ping.c16 Mar 2017 19:58:28 -
@@ -283,10 +283,6 @@ main(int argc, char *argv[])
uid = getuid();
gid = getgid();
}
-   if (setgroups(1, ) ||
-   setresgid(gid, gid, gid) ||
-   setresuid(uid, uid, uid))
-   err(1, "unable to revoke privs");

preload = 0;
datap = [ECHOLEN + ECHOTMLEN];
@@ -427,6 +423,11 @@ main(int argc, char *argv[])
usage();
}
}
+
+   if (setgroups(1, ) ||
+   setresgid(gid, gid, gid) ||
+   setresuid(uid, uid, uid))
+   err(1, "unable to revoke privs");

argc -= optind;
argv += optind;


perhaps, but haven't closely looked if there is any scope for escalation 
or anything during option parsing

Re: Firefox: Recenty instable

[lvdd]

Hi,

On Thu, 16 Mar 2017 12:29:00 +0100
Sebastien Marie  wrote:

> > What did you raise it to? I raised mine to 1536M for both -cur and -max
> > and it's had no visible effect.  
> 
> Sorry, but 1.5 Go could be a small value currently... Javascript JIT
> engine pre-allocate 1 Go for itself at startup, and next the application
> needs to do some malloc too...
> 
> You could check the effective current value (datasize-cur) with:
> 
> ksh$ ulimit -d# value in kbytes
> 786432
> 
> Or read the value configured in login.conf:
> 
> $ getcap -f /etc/login.conf -s datasize-cur default staff
> default: 768M
> staff: 1536M
> 
> For obtain your current login-class:
> 
> $ id -c
> default

I am currently running with the following and have no problems so far:

$ getcap -f /etc/login.conf -s datasize-cur default staff 
default: 768M
staff: 2560MM
$ ulimit -d
2621440
$ id -c
staff

regards
Lars

Re: EMR Featured Client Database

[marguerite . boone]

Hi,

A quick follow up to know if you would be interested in *EMR* Users list
for your marketing campaign?

We have technology users like: *Abbott,* *GE Healthcare,* *McKesson,
Allscripts, Greenway, Cerner, Epic, Nextgen, eClinicalWorks, Praxis* and
many more.

*List Contains*: Name, Company's Name, Phone Number, Fax Number, Job Title,
Email address, Complete Mailing Address, SIC code, Company revenue, size,
Web address etc.

Specialties: business intelligence, data visualization, data analysis,
dashboards.

Let me know your thoughts or pass on the message to the right person in
your company.

Thanks & regards,
*Marguerite Boone*
Marketing Analyst

If you don’t want to receive any message from us then please type “OPT 
OUT”
in the Subject Line.

libexec/login support for u2f devices?

[Leonid Vasilyev]

Hello,

I see there is libexec/login_yubikey program that supports Yubikey tokens.

Are there any plans/active development to support login with u2f tokens?


Thanks!

Re: IKEv2 (iked) VPN with Windows 10 clients

[Roberto Katalinic]

Thanks for the suggestions guys problem solved.

It appears there was a static route on the test machine that was causing the 
issue. Once removed traffic started flowing to the destination.

Kind regards,

Roberto Katalinic
07460663373

kliker IT
www.kliker.it
08455442033

From: Bobby Johnson [mailto:bo...@plexuscomp.com]
Sent: 15 March 2017 02:08
To: Roberto Katalinic 
Cc: misc 
Subject: Re: IKEv2 (iked) VPN with Windows 10 clients

Your configuration looks reasonable. You should upgrade to 6.0.  You could 
replace the local network range with 0.0.0.0/0 to limit the 
flow less.  I've found that config address with a range doesn't work as 
expected with multiple clients.  Below is an example of a working config using 
machine certs for windows clients, including Windows 10.

ikev2 passive esp \
from 0.0.0.0/0 to 192.168.40.2 local 1.2.3.4 peer any \
srcid "asn1_dn of server cert"
dstid "asn1_dn of client cert" \
config address 192.168.40.2 \
config name-server 10.0.0.4


On Mar 10, 2017 7:58 AM, "Roberto Katalinic" 
> wrote:
I have a few remote workers with Windows 10 and would like to move them to
IKEv2 VPN.

On my gateway (OpenBSD 5.7) the iked.conf file is:
ikev2 "IKEv2 DIAL-IN" passive esp \
from 192.168.10.0/24 to 
192.168.40.0/24 \
local 1.2.3.4 peer 0.0.0.0/0 \
srcid 1.2.3.4 \
config access-server 192.168.10.10 \
config name-server 192.168.10.21 \
config address 192.168.40.0/24

My remote client is configured like this:
VPN Type: IKEv2
Data encryption: Optional
Authentication: Use machine Certificates (no EAP)

My PF rules contain the following lines which are definitely not overruled by
any rules further down the line:
set skip on {lo,enc0}
pass in on egress proto udp from any to any port {500,4500}
pass in on egress proto {ah,esp}

When the client attempts connection, the SA is configured and Windows reports
the connection as established. It also acquires an IP address and the DNS
server as specified in the iked.conf file:

PPP adapter EDGE:
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : EDGE
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.40.87(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 192.168.10.21
   NetBIOS over Tcpip. . . . . . . . : Enabled

My gateway also reports the connection as established and the SA is shown by
ipsecctl -sa:
FLOWS:
flow esp in from 192.168.40.87 to 192.168.10.0/24 peer 
5.6.7.8 srcid
IPV4/1.2.3.4 type use
flow esp out from 192.168.10.0/24 to 192.168.40.87 peer 
5.6.7.8 srcid
IPV4/1.2.3.4 type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x7a8197f6 auth hmac-sha1 enc aes-256
esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x926fb219 auth hmac-sha1 enc aes-256

Output from iked -dvvv:
ikev2_pld_cp: INTERNAL_IP4_SERVER 0x5ba0 length 4
ikev2_pld_cp: INTERNAL_IP4_DNS 0x0003 length 4
ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4
ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length
44
ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4
xforms 3 spi 0xe7ce691f
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96
ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE
ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length
24
ikev2_pld_ts: count 1 length 16
ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport
65535
ikev2_pld_ts: start 192.168.40.34 end 192.168.40.34
ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00
length 24
ikev2_pld_ts: count 1 length 16
ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport
65535
ikev2_pld_ts: start 192.168.10.0 end 192.168.10.255
ikev2_msg_send: IKE_AUTH response from 1.2.3.4:4500 to 
5.6.7.8:15573 msgid 1,
1452 bytes, NAT-T
pfkey_sa_add: update spi 0xe7ce691f
pfkey_sa: udpencap port 15573
ikev2_childsa_enable: loaded CHILD SA spi 0xe7ce691f
pfkey_sa_add: add spi 0xabf256a4
pfkey_sa: udpencap port 15573
ikev2_childsa_enable: loaded CHILD SA spi 0xabf256a4
ikev2_childsa_enable: loaded flow 0x1166a0b99800
ikev2_childsa_enable: loaded flow 0x1166a0b99400
sa_state: VALID -> ESTABLISHED from 5.6.7.8:15573 to 
1.2.3.4:4500 

Re: Isakmpd and NAT-T

[Sébastien Morand]

Hi Mike and everybody,

Thank you Mike for your answer. There is nothing more like you said.
Actually we succeed in phase 1 but not in phase 2.

My client give me the following spec:
Phase 1: SHA1 - 160 bits / DH 5 / Authentication with PSK / CIPHER :
AES-256 / Lifetime 86400s
Phase 2: Tunnel mode / SHA1 / No PFS / Authentication with PSK / CIPHER
AES-128 / Lifetime 3600s

So I end up with the following in ipsec.conf:
ike active esp tunnel \
from 10.85.98.16/29 to \
{10.249.0.0/21} \
peer  \
main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
quick auth hmac-sha1 enc aes-128 group none lifetime 3600 \
srcid "" \
psk ""

I'm starting the ipsec like this :
isakmpd -Kdvvv (to see what is happening)
and
ipsecctl -f /etc/ipsec.conf

It's look like good to me and conform to the provided specs. Phase 1 is ok
but no phase 2:
155851.640374 Default ipsec_validate_id_information: dubious ID information
accepted
155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154,
responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142
155918.682560 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-10.249.0.0/21, no response from peer
80.125.165.142:4500
155918.682611 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-80.125.172.0/23, no response from peer
80.125.165.142:4500
155918.682644 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-80.125.174.0/24, no response from peer
80.125.165.142:4500

In TCPDUMP I got no answer on port 4500 (but everything fine on port 500)
so it means to me they don't answer to my packet but I don't know why :
16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:41.673655 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:41.673674 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686803 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686862 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686881 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700016 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700106 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700154 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
(... it can last forever ...)

Any idea what can be done or a way to get more information on what's going
on? They are using CISCO 6509 with IOS 12.2-33.SXH3a.

Thanks by advance,
Sebastien

On Tue, Mar 14, 2017 at 12:46 AM, Mik J  wrote:

> Hello Sebastien,
> I'm not sure there's something special to force nat-t, it's automatic.
> The natted side has to initiate the flow to the non natted side.
> If the two sides are natted then there should be a port forward to one of
> them.
> There should be a nat keepalive parameter as well.
>
>
>
> Le Lundi 13 mars 2017 18h40, Sébastien Morand  a
> écrit :
>
>
> Hi,
>
> I'm trying to set up a NAT-T IPSec VPN with one of my client.
>
> Is this configuration ok on ipsec.conf for NAT-T?
> ike esp \
> from 10.85.98.16/29 to {10.249.0.0/21} \
> peer  \
> main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
> quick auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
> srcid "" \
> psk ""
>
> Something else to force NAT-T?
> Thanks by advance,
> Sébastien

Re: Firefox: Recenty instable

[Sebastien Marie]

On Wed, Mar 15, 2017 at 10:00:33PM -0500, Ed Ahlsen-Girard wrote:
> On Sun, 12 Mar 2017 23:47:36 +0100
> Thomas Weinbrenner  wrote:
> 
> > Since raising datasize-cur in /etc/login.conf my firefox has stopped
> > crashing.
> > 
> 
> What did you raise it to? I raised mine to 1536M for both -cur and -max
> and it's had no visible effect.

Sorry, but 1.5 Go could be a small value currently... Javascript JIT
engine pre-allocate 1 Go for itself at startup, and next the application
needs to do some malloc too...

You could check the effective current value (datasize-cur) with:

ksh$ ulimit -d  # value in kbytes
786432

Or read the value configured in login.conf:

$ getcap -f /etc/login.conf -s datasize-cur default staff
default: 768M
staff: 1536M

For obtain your current login-class:

$ id -c
default

Thanks.
-- 
Sebastien Marie

Re: Firefox: Recenty instable

[Ed Ahlsen-Girard]

On Sun, 12 Mar 2017 23:47:36 +0100
Thomas Weinbrenner  wrote:

> On Sun, Mar 12, 2017 at 11:19:18PM +0100, Stefan Wollny wrote:
>  [...]  
> 
> [...]
>  
>  [...]  
> 
> I found this quite helpful.
> 
> https://marc.info/?l=openbsd-ports=148925156914633
> 
> Since raising datasize-cur in /etc/login.conf my firefox has stopped
> crashing.
> 

What did you raise it to? I raised mine to 1536M for both -cur and -max
and it's had no visible effect.

-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL

Re: relayd redirect not working

[Dave Cohen]

Michael,

Appreciate you chiming in.  I'm a fan of Absolute OpenBSD!

I'm having trouble reproducing the settings that I originally wrote about.  
I've tried to restore /etc/relayd.conf and /etc/pf.conf to what they were when 
I wrote the email.  But right now, neither port 80 nor 443 are redirecting to 
the other ports.  Earlier, port 80 was working while 443 was not.  I'm at a 
loss as to why the behavior is not the same as before.

Despite that trouble, I tried the commands you suggested.  `relayd -dvvv` shows

$ doas relayd -dvvv
startup
socket_rlimit: max open files 1024
init_filter: filter init done
init_tables: created 2 tables
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
hce_notify_done: 127.0.0.1 (icmp ok)
host 127.0.0.1, check icmp (32ms,icmp ok), state unknown -> up, availability 
100.00%
pfe_dispatch_hce: state 1 for host 1 127.0.0.1
hce_notify_done: 127.0.0.1 (icmp ok)
host 127.0.0.1, check icmp (33ms,icmp ok), state unknown -> up, availability 
100.00%
pfe_dispatch_hce: state 1 for host 2 127.0.0.1
table https: 1 added, 0 deleted, 0 changed, 0 killed
pfe_sync: enabling ruleset
sync_ruleset: rule added to anchor "relayd/https"
hce_notify_done: 127.0.0.1 (icmp ok)
hce_notify_done: 127.0.0.1 (icmp ok)
table http: 1 added, 0 deleted, 0 changed, 0 killed
pfe_sync: enabling ruleset
sync_ruleset: rule added to anchor "relayd/http"
hce_notify_done: 127.0.0.1 (icmp ok)
hce_notify_done: 127.0.0.1 (icmp ok)
hce_notify_done: 127.0.0.1 (icmp ok)
...etc...

and `relayctl sho sum`

$ relayctl sho sum
Id  TypeNameAvlblty Status
1   redirecthttps   active
1   table   httpshosts:8443 active (1 hosts)
1   host127.0.0.1   100.00% up
2   redirecthttpactive
2   table   httpshosts:8080 active (1 hosts)


-Dave

On Sun, Mar 12, 2017, at 03:16 PM, Michael W. Lucas wrote:
> On Sun, Mar 12, 2017 at 09:26:53AM +0100, Salvatore Cuzzilla wrote:
> > Ciao Dave,
> > 
> > I'm also playing with relayd as a L7 gateway and as far as I can see from 
> > your
> > config there is no CA and key configured. In order for HTTPS to work relayd
> > needs to be able to do TLS inspection and of course you should redirect all
> > your https traffic to port 8443 (using PF for example). If you check the
> > pf.conf man page under both the sections RELAYS and Examples you should be
> > able to find a lot of good hints.
> 
> He's using a redirect, not a relay, so it should work just fine. No L7
> stuff here, only low-level IP.
> 
> Dave, looks OK to me. What does relayd -dvvv say? And relayctl sho sum ?
> 
> -- 
> Michael W. LucasTwitter @mwlauthor 
> nonfiction: https://www.michaelwlucas.com/
> fiction: https://www.michaelwarrenlucas.com/
> blog: http://blather.michaelwlucas.com/