Re: PPPoE vlan issue 6.4

2019-02-11 Thread Daniel Gillen
On 11.02.19 04:53, David Gwynne wrote:
> Hi Adam,
> 
> It sounds like you're on an ISP with very similar requirements to me. The 
> exec summary of what my ISP wants is pppoe on vlan2, with the vlan priority 
> forced to a single value.
> 
> Our (OpenBSD's) understanding of the priority field in VLAN headers is that 
> it uses 802.1p for the fields value. 802.1p says that priories 0 and 1 are 
> swapped on the wire, and we use that consistently in the system, ie, the 
> priority you see in tcpdump on a vlan interface is the same as what you 
> configure for the priority value there, and visa versa. Everyone else seems 
> to think 0 is 0 and 1 is 1, which can be confusing.
> 
> My ISP wants priority 0 on the wire, which means 1 in OpenBSD.
> 
> I'm using an APU1, so I have re interfaces instead of em. I have re0 going to 
> the ISP, and re1 is my internal network.
> 
> hostname.re0:
> up
> 
> hostname.vlan2:
> vnetid 2
> parent re0
> link0 llprio 1
> up
> 
> hostname.pppoe0:
> == pppoe0 ==
> inet 0.0.0.0 255.255.255.255 0.0.0.1
> pppoedev vlan2
> authproto pap
> authname 'dlg@the_isp' authkey 'secret'
> group external
> !/sbin/route add default -ifp pppoe0 0.0.0.1
> up
> 
> hostname.re1:
> inet 192.168.1.1/24
> 

Absolutely the same for me. Just a small addition, I also have the
following in my /etc/pf.conf

match on pppoe0 set prio 1

Works like a charm :-)

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: OpenBSD 6.3, pppoe and IPv6 - default route missing

2018-04-13 Thread Daniel Gillen
On 13.04.2018 18:54, Edmund Craske wrote:
> On Fri, Apr 13, 2018, at 9:31 AM, Stuart Henderson wrote:
>> Can you show your whole hostname.pppoe0 file? (mask your password of
>> course).  On Zen I'm using the following
>>
>> mtu 1500
>> inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev em1 authproto chap 
>> authname "XXX@zen" authkey "XXX" up
>> inet6 -autoconfprivacy
>> inet6 autoconf
>> !/sbin/route add default -ifp pppoe0 0.0.0.1
>> !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 -priority 8
>>
>> and hostname.em1 has
>>
>> mtu 1508
>> up
>>
>> In my case, I'm using dhcpcd from packages to get addresses for my internal
>> networks, Zen don't statically route my v6 block unless I request it via
>> DHCPv6-PD, but you won't need that with A, you can just configure them
>> statically on the inside interfaces.
> 
> Of course, here is my /etc/hostname.pppoe0:
> inet 0.0.0.0 255.255.255.255 NONE mtu 1500 pppoedev em1 authproto chap 
> authname foo authkey bar up
> dest 0.0.0.1
> inet6 eui64
> !/sbin/route add default -ifp pppoe0 0.0.0.1
> !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0
> 
> and my /etc/hostname.em1 is:
> inet 192.168.2.2 255.255.255.0 NONE mtu 1508
> 
> Which I think was just me attempting to make it so that I could talk to my 
> modem previously... Anyway the connection comes up and I can do 1500 byte 
> packets over it so all good in that respect.
> 
> My config is basically lifted almost verbatim from the first example on the 
> pppoe(4) man page, with the 1500 mtu modifications from the example lower 
> down... So either there is something really weird with my particular setup 
> which means that this example is no longer suitable, or the example does not 
> work like expected on 6.3.
> 
> As previously mentioned I also tried it with 'eui64' changed to 'autoconf',  
> but it didn't seem that SLAAC was seeing RAs from the remote end - maybe 
> that's not set up on A, or something else is configured wrong? I did try 
> opening up my pf ruleset a bit but it made no difference. However I used an 
> older version of the manpage example on my previous OpenBSD 5.8 router (i.e. 
> no SLAAC or other thing doing any v6 configuration) and it worked fine, so 
> something is seemingly altering the v6 route table in between the pppoe0 if 
> being brought up, and it actually establishing a session...
> 
> Thanks,
> Edmund
> 

Hi

Just upgraded to 6.3 and it works for me. Here is my config:

--- /etc/hostname.em1


llprio 1 mtu 1508 up

--- /etc/hostname.vlan35


vnetid 35 parent em1 mtu 1508 llprio 1 up

--- /etc/hostname.pppoe0
inet 0.0.0.0 255.255.255.255 NONE mtu 1500 llprio 1 \
pppoedev vlan35 \
authproto pap \
authname "foo" \
authkey "bar"
dest 0.0.0.1
inet6 autoconf
!/sbin/route add default -ifp pppoe0 0.0.0.1
!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0

--- /etc/pf.conf
if_ext="pppoe0"
icmp6_types="{ 1, 2, 133, 134, 135, 136 }"
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext),
ff02::1/16 } icmp6-type $icmp6_types
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext),
ff02::1/16 } icmp6-type 3 code 0
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext),
ff02::1/16 } icmp6-type 3 code 1
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext),
ff02::1/16 } icmp6-type 4 code 0
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext),
ff02::1/16 } icmp6-type 4 code 1
pass in quick on $if_ext inet6 proto icmp6 from any to { ($if_ext),
ff02::1/16 } icmp6-type 4 code 2

You don't have to use a vlan as it seems from your config and won't need
the llprio stuff either. If your ISP supports SLAAC, this should work
for you too I guess.

Daniel

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: dokuwiki - /dev/urandom issue

2017-06-11 Thread Daniel Gillen
On 11.06.2017 19:43, Asbel Kiprop wrote:
> Hello
> After todays update my Dokuwiki just throw 500 error "There is no suitable
> CSPRNG installed on your system". Googled a bit and found out it because i
> have no /dev/urandom in my basedir,
> And this kinda obvious cuz i have httpd chrooted by default
> 
> Doku version dokuwiki-2017.02.19b installed from the OpenBSD pacjages, So
> only way is to disable chroot?
> 

Have u tried creating urandom in the httpd chroot?

In case your chroot is /var/www: mkdir /var/www/dev && cd /var/www/dev
&& /dev/MAKEDEV random

I just have no idea whether this might have any security implications.
Probably not, but maybe someone else can enlighten us on this.

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: How easy is to do a MITM/spoof/etc. a public IP address?

2017-01-25 Thread Daniel Gillen
On 25.01.2017 15:42, C. L. Martinez wrote:
> On Wed, Jan 25, 2017 at 02:07:55PM +, Stuart Henderson wrote:
>> On 2017-01-25, C. L. Martinez  wrote:
>>> Hi all,
>>>
>>> I have received a (maybe) "stupid" request from one of our customers.
>>> We have a pair of public OpenBSD firewalls (CARPed) that our development
>>> team use to access to several customers via VPN IPsec tunnels. But this
>>> morning we have received a request from one of these cutomers to access
>>> to our development servers using only one acl to permit their public IP
>>> address (without using VPN IPsec, or VPN SSL tunnels).
>>>
>>> And my (OT) question: how easy is to do a MITM attack (DNS spoofing
>>> for example, or another type of attack that permits to fake source
>>> public ip address) in this scenario?
>>
>> For an attacker with no access to endpoints or network in between:
>>
>> - For many protocols including UDP, it is absolutely trivial to send
>> traffic from a fake source address.
> 
> But, only SYN can be sent, right?? Source's attacker ip address will not 
> receive ACK, etc. Is it correct? If it is, he/she/they only can do DoS 
> attack, they can't steal information, right?
> 

UDP and many other protocols are connectionless, so there is no such
thing as SYN/ACK. You basically just send your data package and hope it
somehow gets to its destination.

https://en.wikipedia.org/wiki/User_Datagram_Protocol

>>
>> - With TCP it depends on various things but sometimes you can predict
>> enough of the IP stack behaviour to spoof blindly and send data.
>> reassemble tcp + random-id can help.
>>
>> If an attacker can MITM (either by getting $client to send to their
>> machine instead of yours directly, they can obviously log or modify
>> packets before forwarding on to the real server. It depends what
>> you're running over it as to whether this is a problem.
>>
> 
> Uhmmm ... but in this case, I don't see how an attacker can fake original ip 
> public source address ... Any theorical example?
> 
> Many thanks Stuart for your help.
> 
> 

In an MITM scenario, the send data packets actually flow _trough_ the
MITM's machine before they are forwarded to your machine. No need to
fake original source address, as it won't be changed. Think of the
MITM's machine as a simple router interconnecting your and the $client's
WAN.

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: PPPoE (5.9 still): https gets stuck

2016-09-13 Thread Daniel Gillen
On 13/09/2016 11:51, Harald Dunkel wrote:
> Hi folks,
> 
> I am using an openbsd (5.9) box as gateway/firewall to the
> internet. ISP is Deutsche Telekom. In between is a Vigor 130
> VDSL2 modem, configured to PPPoE passthrough. The PPPoE
> connection is initiated on the openbsd box.
> 
> Problem: https via the tunnel gets stuck for some sites, e.g.
> https://telekom.de/ (please note the irony). Other sites work
> fine, e.g. https://kundencenter.telekom.de/. I tried a lot of
> clients: chrome, firefox, Safari, wget, etc. and all platforms
> I have at home.
> 
> Other services (http, smtp, dns, ntp, vnc, ...) seem to work
> flawless.
> 
> The problem came up with the migration from ADSL to VDSL this
> weekend. The gateway wasn't changed, but I wonder if there are
> some issues or pitfalls with PPPoE and fragmented packages or
> whatever, possibly breaking https negotiation?
> 
> 
> Every helpful comment is highly appreciated
> Harri
> 

Hi

I had a similar problem. In my case it had to do with Path MTU issues.

This site f.ex.: http://test-ipv6.com/ will check for that.

The solution for me was to switch to "jumbo" frames below the pppoe
device (1508 bytes if I remember correctly) and set the pppoe's MTU to 1500.

Daniel



Re: DigitalOcean and OpenBSD

2016-08-25 Thread Daniel Gillen
On 25.08.2016 14:46, Kamil Cholewiński wrote:
> On Thu, 25 Aug 2016, Gilles Chehade  wrote:
>> There are other alternatives with better hardware, services and policies
>> within the same price ranges. online.net to name one, hetzner.de to name
>> another one.
> 
> Hetzner customer here. Hetzner doesn't support OpenBSD natively. The
> only instructions I could find are kind of dated, in German, seem to
> apply only to dedicated servers (as opposed to VMs), and overall look
> like a giant hack. Anyone had luck getting things running recently?
> 
> <3,K.
> 

Yepp, I do have a dedicated Hetzner server running OpenBSD.

Linux rescue console + qemu is the way to get it installed and going.

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: PPPoE issues

2016-05-29 Thread Daniel Gillen
On 29/05/2016 21:53, Maurice Janssen wrote:
> Hi,
> 
> I'm trying to replace a PC Engines Alix board with an APU 2c4 board, but
> I'm having some issues to get it up and running.
> I have a fiber connection and my ISP requires a PPPoE connection over
> VLAN 6.
> 
> With the old setup, this works like a charm.
> With the new setup, I can't get the PPPoE connection to work.
> When I use tcpdump on the ethernet interface, I can see the PADI packets
> leave the system on VLAN6, but there is no answer at all. OpenBSD keeps
> sending a PADI every minute or so, to no avail.
> 
> I have tried to get it running with 5.9-stable (amd64), with a recent
> snapshot (amd64), with 5.9-stable (i386, as that works fine on the
> Alix), but none of them work.
> 
> When I have a working connection on the old router and then quickly move
> the cable (the one that is connected to the fiber/copper converter) to
> the new router, I can see some packets (belonging to the 'old'  PPPoE
> connection) arriving on the new router (with tcpdump).  So at the
> ethernet level the link is OK.
> 
> Does anyone have a clue what could be causing this?  Some VLAN-tagging
> issue with the I210 NIC on the APU?  Does anyone have a similar setup
> working?
> 
> Thanks a lot in advance,
> Maurice
> 

Hi

I have a similar setup. For me the problem was that the provider did not
accept vlan packages with a prio value other than 0.

Unfortunately, if that's the problem for you too, it can't be fixed by
configuration. You will have to compile a new kernel.

The following patch will make the prio field always be 0, that solved it
for me.

Index: sys/net/if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.151
diff -u -p -r1.151 if_vlan.c
--- sys/net/if_vlan.c   13 Jan 2016 03:18:26 -  1.151
+++ sys/net/if_vlan.c   30 May 2016 05:22:08 -
@@ -270,8 +270,7 @@ vlan_start(struct ifnet *ifp)
 */
} else if ((p->if_capabilities & IFCAP_VLAN_HWTAGGING) &&
(ifv->ifv_type == ETHERTYPE_VLAN)) {
-   m->m_pkthdr.ether_vtag = ifv->ifv_tag +
-   (prio << EVL_PRIO_BITS);
+   m->m_pkthdr.ether_vtag = ifv->ifv_tag;
m->m_flags |= M_VLANTAG;
} else {
struct ether_vlan_header evh;
@@ -279,8 +278,7 @@ vlan_start(struct ifnet *ifp)
m_copydata(m, 0, ETHER_HDR_LEN, (caddr_t));
evh.evl_proto = evh.evl_encap_proto;
evh.evl_encap_proto = htons(ifv->ifv_type);
-   evh.evl_tag = htons(ifv->ifv_tag +
-   (prio << EVL_PRIO_BITS));
+   evh.evl_tag = htons(ifv->ifv_tag);
m_adj(m, ETHER_HDR_LEN);
M_PREPEND(m, sizeof(evh), M_DONTWAIT);
if (m == NULL) {

Daniel



Re: pf sanity check

2016-05-25 Thread Daniel Gillen
On 25.05.2016 15:01, Jeff Ross wrote:
> Hi all,
> 
> I am incrementally bringing my server up to date.  I was on 5.5-current so
> following the instructions I upgraded to 5.6 stable.
> 
> I re-wrote  my pf.conf to remove the oldqueue rules and to simplify the
> rule set.
> 
> Checks okay for syntax but it doesn't seem to be redirecting mail to
> spamd.  If I telnet to my server on port 25 I do not see the stutter of the
> banner at all.
> 
> Here's my current pf.conf for other eyes--maybe I've made a thinko in these
> new ruless
> 
> # $OpenBSD: pf.conf,v 1.49 2009/09/17 06:39:03 jmc Exp $
> #
> # See pf.conf(5) for syntax and examples.
> # Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
> # in /etc/sysctl.conf if packets are to be forwarded between interfaces.
> ext_if="re0"  # External Public Interface
> tcp_services = "{ 22,53,113,25,993,465,80,443 }"
> udp_services = "{ domain, ntp, 1194 }"
> icmp_types = "{ echoreq, unreach }"
> table  persist
> table  persist
> set block-policy return
> set loginterface $ext_if
> set skip on { lo, tun }
> match on $ext_if inet all scrub (no-df max-mss 1398)
> 
> # filter rules and anchor for ftp-proxy(8)
> anchor "ftp-proxy/*"
> pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
> 
> # anchor for relayd(8)
> block log all
> block in log quick proto tcp from  to any
> # rules for spamd(8)
> table  persist
> table  persist file "/etc/mail/nospamd"
> pass in log on egress proto tcp from any to any port smtp \
> rdr-to 127.0.0.1 port spamd
> pass in log on egress proto tcp from  to any port smtp
> pass in log on egress proto tcp from  to any port smtp
> pass out log on egress proto tcp to any port smtp
> 
> pass in log quick on egress proto tcp to port $tcp_services
> pass in log quick on egress proto udp to port $udp_services
> pass out log quick on egress from any to any
> 
> Thanks!
> 
> Jeff Ross
> 

Hi

Your tcp_services variable includes port 25, which is smtp, and you have
a rule to pass in quick all tcp_services.

That one will precede your spamd rules if I got that right.

So, by removing port 25 from tcp_services, your setup should work.

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: OT: Any experience connecting OpenBSD via ONT ?

2016-04-27 Thread Daniel Gillen
On 28/04/2016 05:07, Jeremy wrote:
> On Tue, 26 Apr 2016 17:53:32 -0500
> Adam Thompson  wrote:
>> If all else fails, run "ifconfig em2 up", and then "tcpdump -i em2
>> - -l -n" and see what, if any, traffic is coming from the ONT on
>> the raw ethernet port (this will include the VLAN 10 packets, too).
>> If you're lucky, something it emits will give you a clue.
>> -Adam
> 
> OK, so I have heard from my ISP that I need to use PPPoE.
> 
> My config is now:
> # cat hostname.em2
> up
> 
> #cat hostname.vlan10
> up vlan 10 vlandev em2
> 
> #cat /etc/hostname.pppoe0 
> !/sbin/ifconfig em2 up
> !/sbin/ifconfig vlan10 up
> inet 0.0.0.0 255.255.255.255 NONE \
> pppoedev vlan10 \
> authproto pap \
> authname "xxx" \
> authkey "xx"
> dest 0.0.0.1
> 
> 
> ifconfig shows me the following:
> # ifconfig
> em2: flags=8843 mtu 1500
> lladdr 00:11:0a:08:01:57
> priority: 0
> media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) 
> status: active
> vlan10: flags=8843 mtu 1500
> lladdr 00:11:0a:08:01:57
> priority: 0
> vlan: 10 parent interface: em2
> groups: vlan
> status: active
> pppoe0: flags=8851 mtu 1492
> priority: 0
> dev: vlan10 state: PADI sent
> sid: 0x0 PADI retries: 25 PADR retries: 0
> sppp: phase establish authproto pap authname "medix21" 
> groups: pppoe
> status: no carrier
> inet 0.0.0.0 --> 0.0.0.1 netmask 0x
> 
> 
> Finally running tcpdump on the em2 physical port shows this:
> # tcpdump -nettti em2 - -l -n
> tcpdump: listening on em2, link-type EN10MB
> Apr 28 14:58:26.088559 00:11:0a:08:01:57 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q 
> vid 10 pri 3 PPPoE-Discovery
> code Initiation, version 1, type 1, id 0x, length 12
> tag Service-Name, length 0
> tag Host-Uniq, length 4 w\257\323\236
> Apr 28 14:59:26.281326 00:11:0a:08:01:57 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q 
> vid 10 pri 3 PPPoE-Discovery
> code Initiation, version 1, type 1, id 0x, length 12
> tag Service-Name, length 0
> tag Host-Uniq, length 4 w\257\323\236
> ...
> 
> 
> It looks to me like I cannot contact the PPPoE auth service. 
> Note: I have tried this with the pppoedev set to both the 
> physical em2 interface and the vlan10 interface with the same 
> result. Either I'm connecting to the wrong port on the ONT or 
> I'm missing a further piece of the puzzle.
> 

Supposing it is the correct port, this looks exactly like the problem I
had with the vlan prio field not being 0 and the provider not ignoring it.

Try if this patch helps, it makes the vlan prio field be 0 all the time:

Index: net/if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.151
diff -u -p -r1.151 if_vlan.c
--- net/if_vlan.c   13 Jan 2016 03:18:26 -  1.151
+++ net/if_vlan.c   28 Apr 2016 05:11:34 -
@@ -270,8 +270,7 @@ vlan_start(struct ifnet *ifp)
 */
} else if ((p->if_capabilities & IFCAP_VLAN_HWTAGGING) &&
(ifv->ifv_type == ETHERTYPE_VLAN)) {
-   m->m_pkthdr.ether_vtag = ifv->ifv_tag +
-   (prio << EVL_PRIO_BITS);
+   m->m_pkthdr.ether_vtag = ifv->ifv_tag;
m->m_flags |= M_VLANTAG;
} else {
struct ether_vlan_header evh;
@@ -279,8 +278,7 @@ vlan_start(struct ifnet *ifp)
m_copydata(m, 0, ETHER_HDR_LEN, (caddr_t));
evh.evl_proto = evh.evl_encap_proto;
evh.evl_encap_proto = htons(ifv->ifv_type);
-   evh.evl_tag = htons(ifv->ifv_tag +
-   (prio << EVL_PRIO_BITS));
+   evh.evl_tag = htons(ifv->ifv_tag);
m_adj(m, ETHER_HDR_LEN);
M_PREPEND(m, sizeof(evh), M_DONTWAIT);
if (m == NULL) {



Re: OT: Any experience connecting OpenBSD via ONT ?

2016-04-25 Thread Daniel Gillen
On 26/04/2016 04:56, open...@smartpoint.co.nz wrote:
> Does anyone have experience connecting an OpenBSD box via a fibre ONT ?
> 
> I currently have a working setup using the OpenBSD box as a
> router/firewall for my LAN, connecting to the internet via an ethernet
> connected ADSL modem. I'm trying to replace this ADSL connection with
> Fibre. 
> (Note: I will update default gateway and routes after I can
> successfully bring up the fibre link.)
> 
> I have an ONT installed by my ISP but (for various reasons) they left
> without completing the config. I'm having trouble getting information
> about how my OpenBSD NIC should be configured.
> 
> My LAN is connected on em0
> I have the current ADSL connected on em1
> I have an ethernet cable on em2 plugged into the ONT on its LAN 1 port.
> 
> I'm trying to understand the expected configuration of em2.
> 
> I've tried setting dhcp in /etc/hostname.em2 and doing a netstart.
> Unfortunately I don't get an IP address on this interface (timeout). 
> 
> My ISP tech support has been of little help but they mentioned that I
> should get a public IP address via DHCP on the ONT and should be using
> VLAN 10. I'm not sure how this helps. 
> 
> I tried setting "up" in hostname.em2 and setting "dhcp vlan 10 vlandev
> em2" in /etc/hostname.vlan10 but this failed to get me an IP address
> either. # ifconfig shows em2 is "active" and vlan10 is also "active" but
> I don't see how to route traffic via this link.
> 
> 
> I was expecting that I need a (dhcp?) IP address on an interface
> connected to the ONT but I'm wondering if I have fundamentally
> mis-understood how this should be configured ?  Do I need PPPoE maybe ? 
> Thanks in advance.
> 

I have a similiar setup, except for me it's vlan id 35. And in addition,
I have to do pppoe on the link to reach the internet.

Here's my setup:

-- /etc/hostname.em1
up

-- hostname.vlan35
vlan 35 vlandev em1 up

-- hostname.pppoe0
!/sbin/ifconfig em0 up
!/sbin/ifconfig vlan35 up
inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \
pppoedev vlan35 \
authproto pap \
authname "" \
authkey ""
dest 0.0.0.1
inet6 autoconf
!/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
!/sbin/route add ::/0 -ifp pppoe0 fe80::

Also, there seems to still be a bug in OpenBSD. You have no possibility
to influence the vlan prio field. That struck me in the beginning
because my ISP was requiring it to be 0 and the default value on OpenBSD
is 3 I think. If that's the case for you, you have to patch the kernel
to set the prio field to a fixed value.



Re: unable to add tun interface to bridge

2016-04-24 Thread Daniel Gillen
On 24.04.2016 04:39, niya levi wrote:
> hi everyone
> i am trying to setup openvpn with tun on a bridge (openbsd 5.9),
> i tried the following but got an Invalid argument error,
> 
> ifconfig tun0 create
> ifconfig bridge0 create
> ifconfig bridge0 add em0
> ifconfig bridge0 add tun0
> ifconfig: bridge0: tun0: Invalid argument
> 
> what is the correct way to add the tun interface to the bridge ?
> 
> shadrock
> 

Hi

I think what you need is a tap device, not a tun device.

Prior to 5.9, you could use a tun device and set the link0 flag, but
that was changed in 5.9.

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: upgrade OpenBSD 5.8 to 5.9 daemon: unknown class

2016-04-22 Thread Daniel Gillen
On 22.04.2016 03:25, Ultramedia Libertad wrote:
> hello
> 
> I am upgrade OpenBSD 5.8 to 5.9 and after to reboot
> 
> i have follow errors in remote console :
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *init: daemon: unknown class (failed)syslogdsu: daemon: unknown class
> (failed)pflogdsu: daemon: unknown class (failed)ntpdsu: daemon: unknown
> class (failed)starting RPC daemons:.savecore: no core dumpcheckin quotas:
> done.clearing /tmpkern.securelevel: 0 -> 1creating runtime link editor
> directory cache.preserving editor files.startings networks daemons: sshdsu:
> daemon: unknown class (failed)smtpdsu: daemon: unknown class
> (failed)sndiodsu: daemon: unknown class (failed).Thu apr 21 20:06:24
> CDI 2016*
> 
> 
> y more
> 
> please help me attach image
> 
> --
> editor de sueños
> 
> [demime 1.01d removed an attachment of type image/png which had a name of 
> Screenshot_2016-04-21_21-14-18.png]
> 

Could it have something to do with a damaged /etc/login.conf file?

Can you please post the content of that file.

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



OpenBSD 5.9 / -current kernel hangs on boot

2016-04-18 Thread Daniel Gillen
Hi list

I'm facing a problem here I had never before and hope you can help me.

I'm trying to install OpenBSD (tried 5.9 and -current from 17.04.2016)
onto a Lanner FW-8894A (C610 chipset / Xeon E5-2680) appliance.

Unfortunately the kernel hangs at boot. The last message printed is:

pckbc0 at isa0 port 0x60/5 irq 1 irq 12

Using boot -c, I enabled verbose output which got me to this:

pckbc0 at isa0 port 0x60/5 irq 1 irq 12
>> probing for vga0
>> probing for vga0 failed

I also tried disabling pckbc and/or vga, but neither helps.

It seems as it is the "next step" that hangs, but I don't know what that is.

Has anyone an idea how to solve this or at least get further details
what goes wrong?

BTW: Linux boots on it if that helps.

Thx in advance

Daniel



Re: What do you use to manage contact info?

2016-03-04 Thread Daniel Gillen
On 04.03.2016 15:46, Matthew Weigel wrote:
> On 2016-03-03 21:36, Joe Er wrote:
>> What do you use to manage your contacts?  I am currently using the
>> address book in Thunderbird and am wondering if there is something that
>> is better.
> 
> I'm not proud of it, but I use egroupware.  I almost never actually
> use the web interface, however; I rely on its CardDAV service.  It
> keeps my contacts synchronized between Thunderbird on multiple computers
> and operating systems (via SoGo Connector), RoundCube (via the carddav
> plugin), and multiple Apple devices (used by different people in my
> family).  In general I mostly interact directly with the Addressbook in
> iOS; Thunderbird and Roundcube are integrated primarily to make sure I
> can easily look up email addresses.
> 
> If I were starting over I would also consider ownCloud, but the security
> of this stuff is all terrible.  Google's CardDAV service is probably
> more secure, to everyone but Google anyway, but I prefer to host my own.
> I do what I can to mitigate the security problems, and keep backups.

For something self-hosted and lighter, you might consider using radicale
(http://radicale.org/). Runs perfectly on OpenBSD and supports CalDAV
and CardDAV.

Just my 2c

Daniel

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: inet6 autoconf will not remove invalid addresses on -current

2015-10-02 Thread Daniel Gillen
On 02.10.2015 21:55, Stuart Henderson wrote:
> On 2015/10/02 21:24, Daniel Gillen wrote:
>> But does an ifconfig down really does not remove autoconfigured IPv6
>> addresses?
> 
> Nope, they stay there.
> 
>> I can't test it as ifconfig pppoe0 down does not seem to work
>> as expected at all (but that's another issue).
> 
> pppoe(4)'s normal mode is to reconnect automatically, if your ISP
> allows this to happen quickly then you might not notice it being
> down for any length of time.
> 

Ok, I did assume that 'ifconfig down' would stop automatic reconnection,
so that's solved already.

>> At least another interface (em) with a DHCP configured IPv4 address will
>> have that address removed once it goes down (using ifconfig down).
> 
> If my memory is correct, 'ifconfig down' forces dhclient to exit
> and remove the configured address, but if you just for example
> unplug the cable, that doesn't happen.
> 

True, unplugging will not remove the address.

>> I think (with my limited knowledge of how it actually works :)) the
>> PPPoE issue won't be solved like that as unplugging the cable or loosing
>> the PPPoE connection won't make the interface go down.
> 
> If you watch "route -n monitor" you should see it; looks like this here:
> 
> RTM_IFINFO: iface status change: len 160, if# 19, name: pppoe0, link: active, 
> flags:<PTP,RUNNING,SIMPLEX,MULTICAST>
> RTM_IFINFO: iface status change: len 160, if# 19, name: pppoe0, link: no 
> carrier, flags:<PTP,SIMPLEX,MULTICAST>
> RTM_IFINFO: iface status change: len 160, if# 19, name: pppoe0, link: no 
> carrier, flags:<UP,PTP,SIMPLEX,MULTICAST>
> RTM_IFINFO: iface status change: len 160, if# 19, name: pppoe0, link: no 
> carrier, flags:<PTP,RUNNING,SIMPLEX,MULTICAST>
> RTM_IFINFO: iface status change: len 160, if# 19, name: pppoe0, link: no 
> carrier, flags:<UP,PTP,RUNNING,SIMPLEX,MULTICAST>
> RTM_IFINFO: iface status change: len 160, if# 19, name: pppoe0, link: active, 
> flags:<UP,PTP,RUNNING,SIMPLEX,MULTICAST>
> RTM_IFINFO: iface status change: len 160, if# 19, name: pppoe0, link: active, 
> flags:<UP,PTP,RUNNING,SIMPLEX,MULTICAST>
> RTM_IFINFO: iface status change: len 160, if# 19, name: pppoe0, link: active, 
> flags:<UP,PTP,RUNNING,SIMPLEX,MULTICAST>
> 

You're absolutely right, looks the same here too.

Please excuse my noise, your idea of removing autoconfigured addresses
when an interface goes down would solve this issue.

Daniel

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: inet6 autoconf will not remove invalid addresses on -current

2015-10-02 Thread Daniel Gillen
On 02.10.2015 15:21, Martin Pieuchot wrote:
> On 02/10/15(Fri) 12:53, Stuart Henderson wrote:
>> [...] 
>> I think it would probably make sense to remove an autoconfigured
>> prefix/address if an interface goes down (and one could argue for this
>> being the right thing to do for IPv4/DHCP as well - I lost count of
>> the number of times I have to manually remove addresses so I can
>> continue to reach my home subnet after I've unplugged the laptop).
> 
> This makes sense and should work for LCP keepalive as well. But I
> don't know how hard would it be to teach dhclient(8) to do that...
> 

That makes perfect sense to me too.

But does an ifconfig down really does not remove autoconfigured IPv6
addresses? I can't test it as ifconfig pppoe0 down does not seem to work
as expected at all (but that's another issue).

At least another interface (em) with a DHCP configured IPv4 address will
have that address removed once it goes down (using ifconfig down).

I think (with my limited knowledge of how it actually works :)) the
PPPoE issue won't be solved like that as unplugging the cable or loosing
the PPPoE connection won't make the interface go down.

I think PPPoE should sort of "reset" it's interface (removing all IPv6
autoconfigured addresses) once a connection is lost. And contrary to
DHCP/SLAAC, PPPoE actually has the possibility built-in to detect that
(using ECHOREQ and ECHOREP).

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: inet6 autoconf will not remove invalid addresses on -current

2015-10-01 Thread Daniel Gillen
On 01.10.2015 10:48, Martin Pieuchot wrote:
> Hello,
> 
> On 30/09/15(Wed) 18:19, Daniel Gillen wrote:
>> [...]
>> inet 0.0.0.0 255.255.255.255 NONE \
>> pppoedev vlan35 \
>> authproto pap \
>> authname "@vo.lu" \
>> authkey ""
>> dest 0.0.0.1
>> inet6 autoconf
>> !/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
>> !/sbin/route add ::/0 -ifp pppoe0 fe80::
>>
>> As you can see, it get my IPv6 address trough autoconfiguration.
>>
>> After my pppoe reconnected again, I saw the following in ifconfig:
> 
> What do you mean by "reconnected again" ?
> 
>> pppoe0: flags=208851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6>
>> mtu 1492
>> priority: 0
>> dev: vlan35 state: session
>> sid: 0x44e PADI retries: 8 PADR retries: 0 time: 13:20:45
>> sppp: phase network authproto pap authname "@vo.lu"
>> groups: pppoe egress
>> status: active
>> inet6 fe80::XX:XX:XX:6c3a%pppoe0 ->  prefixlen 64 scopeid 0x8
>> inet6 2001:XX:XX:6f3:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
>> pltime 556434 vltime 2543634
>> [...]
>> inet6 2001:XX:XX:6f3:XX:XX:XX:87b2 ->  prefixlen 64 autoconf
>> autoconfprivacy pltime 1835 vltime 520374
>> inet 85.XX.XX.XX --> 80.XX.XX.XX netmask 0x
>> inet6 2001:XX:XX:7c5:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
>> pltime 604755 vltime 2591955
>> inet6 2001:XX:XX:7c5:XX:XX:XX:30c ->  prefixlen 64 autoconf
>> autoconfprivacy pltime 37915 vltime 556755
>>
>> I got the new 2001:XX:XX:7c5::/64 prefix after the reconnect and OpenBSD
>> added it to my interface.
>>
>> But it didn't remove the now invalid and no longer working
>> 2001:XX:XX:6f3::/64 prefix addresses which caused quite some issues as
>> my NAT was still using that address for part of the connections.
>>
>> Shouldn't those be removed as soon as their prefix is no longer valid?
>> Or at least all be deprecated?
> 
> If this happens again could you include the output of "# ndp -p",
> "# route -n show -inet6" and "# ndp -r" in your report?
> 
> Thanks,
> Martin
> 

I managed to reproduce the issue and executed the commands you told me.

Just one sidenode as it might matter, I'm running -current freshly
checked out and build Thu Oct 1, 18:33:57 CEST 2015.

# uname -a
OpenBSD gate 5.8 GENERIC.MP#1 amd64

And here we go, the short version:

# reboot

# ifconfig pppoe0
IPv4 address is 80.XX.XX.227
Autoconfigured IPv6 address is 2001:XX:XX:707:XX:XX:XX:6c3a

# ping6 -c 1 -S 2001:XX:XX:707:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
Pinging google with that source address works

# ndp -p
2001:XX:XX:707::/64 if=pppoe0
flags=LAD vltime=2592000, pltime=604800, expire=29d23h59m39s, ref=2
advertised by
fe80::46d3:caff:fe9c:ef00%pppoe0 (no neighbor state)

# route -n show -inet6
See long version below

# ndp -r
fe80::46d3:caff:fe9c:ef00%pppoe0 if=pppoe0, flags=O, pref=medium,
expire=29m59s

Now I simmulated a PPPoE dis-/re-connect (Thx again to Todd for the tip)
# ifconfig pppoe0 down up

# ifconfig pppoe0
New IPv4 address is 85.XX.XX.98
But now I have 2 autoconfigured IPv6 addresses, the old
2001:XX:XX:707:XX:XX:XX:6c3a address and the new
2001:XX:XX:7c5:XX:XX:XX:6c3a address.

# ping6 -c 1 -S 2001:XX:XX:707:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
# ping6 -c 1 -S 2001:XX:XX:7c5:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
Pinging google with the old 2001:XX:XX:707::/64 prefix address does not
work anymore, but the new 2001:XX:XX:7c5::/64 prefix address works.

# ndp -p
2001:XX:XX:7c5::/64 if=pppoe0
flags=LAD vltime=2592000, pltime=604800, expire=29d23h59m47s, ref=2
advertised by
fe80::46d3:caff:fe9c:ef00%pppoe0 (no neighbor state)
2001:XX:XX:707::/64 if=pppoe0
flags=LAD vltime=2592000, pltime=604800, expire=29d23h58m45s, ref=2
advertised by
fe80::46d3:caff:fe9c:ef00%pppoe0 (no neighbor state)

# route -n show -inet6
Again, see below

# ndp -r
fe80::46d3:caff:fe9c:ef00%pppoe0 if=pppoe0, flags=O, pref=medium,
expire=29m28

I think the old 2001:XX:XX:707::/64 prefix should be removed as soon as
the same router (fe80::46d3:caff:fe9c:ef00) advertises a new prefix.

Or am I getting something wrong here?

**
And here the log version including 'route' output:

# reboot

# ifconfig pppoe0
pppoe0: flags=208851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6>
mtu 1492
priority: 0
dev: vlan35 state: session
sid: 0x47c PADI retries: 0 PADR retries: 0 time: 00:00:21
sppp: phase network authproto pap authname "@vo.lu"
groups: pppoe egress
status: active
inet6 fe80::XX:XX:XX:6c3a%pppoe0 -> prefixlen 64 scopeid 0x8
in

Re: inet6 autoconf will not remove invalid addresses on -current

2015-10-01 Thread Daniel Gillen
On 01/10/2015 10:48, Martin Pieuchot wrote:
> Hello,
> 
> On 30/09/15(Wed) 18:19, Daniel Gillen wrote:
>> [...]
>> inet 0.0.0.0 255.255.255.255 NONE \
>> pppoedev vlan35 \
>> authproto pap \
>> authname "@vo.lu" \
>> authkey ""
>> dest 0.0.0.1
>> inet6 autoconf
>> !/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
>> !/sbin/route add ::/0 -ifp pppoe0 fe80::
>>
>> As you can see, it get my IPv6 address trough autoconfiguration.
>>
>> After my pppoe reconnected again, I saw the following in ifconfig:
> 
> What do you mean by "reconnected again" ?

The connection was dropped (LCP keepalive timeout) and PPPoE established
a new connection once (I would suspect) PPPoE was available again.

> 
>> pppoe0: flags=208851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6>
>> mtu 1492
>> priority: 0
>> dev: vlan35 state: session
>> sid: 0x44e PADI retries: 8 PADR retries: 0 time: 13:20:45
>> sppp: phase network authproto pap authname "@vo.lu"
>> groups: pppoe egress
>> status: active
>> inet6 fe80::XX:XX:XX:6c3a%pppoe0 ->  prefixlen 64 scopeid 0x8
>> inet6 2001:XX:XX:6f3:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
>> pltime 556434 vltime 2543634
>> [...]
>> inet6 2001:XX:XX:6f3:XX:XX:XX:87b2 ->  prefixlen 64 autoconf
>> autoconfprivacy pltime 1835 vltime 520374
>> inet 85.XX.XX.XX --> 80.XX.XX.XX netmask 0x
>> inet6 2001:XX:XX:7c5:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
>> pltime 604755 vltime 2591955
>> inet6 2001:XX:XX:7c5:XX:XX:XX:30c ->  prefixlen 64 autoconf
>> autoconfprivacy pltime 37915 vltime 556755
>>
>> I got the new 2001:XX:XX:7c5::/64 prefix after the reconnect and OpenBSD
>> added it to my interface.
>>
>> But it didn't remove the now invalid and no longer working
>> 2001:XX:XX:6f3::/64 prefix addresses which caused quite some issues as
>> my NAT was still using that address for part of the connections.
>>
>> Shouldn't those be removed as soon as their prefix is no longer valid?
>> Or at least all be deprecated?
> 
> If this happens again could you include the output of "# ndp -p",
> "# route -n show -inet6" and "# ndp -r" in your report?
> 
> Thanks,
> Martin
> 

Sure, will try this evening to reproduce it somehow and then send you
the output.

Thx

Daniel



inet6 autoconf will not remove invalid addresses on -current

2015-09-30 Thread Daniel Gillen
Hi again

I spotted the following while my ISP disconnected my pppoe link last night.

I have the following /etc/hostname.pppoe0 file:

inet 0.0.0.0 255.255.255.255 NONE \
pppoedev vlan35 \
authproto pap \
authname "@vo.lu" \
authkey ""
dest 0.0.0.1
inet6 autoconf
!/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
!/sbin/route add ::/0 -ifp pppoe0 fe80::

As you can see, it get my IPv6 address trough autoconfiguration.

After my pppoe reconnected again, I saw the following in ifconfig:

pppoe0: flags=208851
mtu 1492
priority: 0
dev: vlan35 state: session
sid: 0x44e PADI retries: 8 PADR retries: 0 time: 13:20:45
sppp: phase network authproto pap authname "@vo.lu"
groups: pppoe egress
status: active
inet6 fe80::XX:XX:XX:6c3a%pppoe0 ->  prefixlen 64 scopeid 0x8
inet6 2001:XX:XX:6f3:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
pltime 556434 vltime 2543634
inet6 2001:XX:XX:6f3:XX:XX:XX:9581 ->  prefixlen 64 deprecated
autoconf autoconfprivacy pltime 0 vltime 2990
inet6 2001:XX:XX:6f3:XX:XX:XX:80b4 ->  prefixlen 64 deprecated
autoconf autoconfprivacy pltime 0 vltime 88911
inet6 2001:XX:XX:6f3:XX:XX:XX:759e ->  prefixlen 64 deprecated
autoconf autoconfprivacy pltime 0 vltime 175252
inet6 2001:XX:XX:6f3:XX:XX:XX:348d ->  prefixlen 64 deprecated
autoconf autoconfprivacy pltime 0 vltime 261652
inet6 2001:XX:XX:6f3:XX:XX:XX:5b7e ->  prefixlen 64 deprecated
autoconf autoconfprivacy pltime 0 vltime 347933
inet6 2001:XX:XX:6f3:XX:XX:XX:a3be ->  prefixlen 64 deprecated
autoconf autoconfprivacy pltime 0 vltime 434046
inet6 2001:XX:XX:6f3:XX:XX:XX:87b2 ->  prefixlen 64 autoconf
autoconfprivacy pltime 1835 vltime 520374
inet 85.XX.XX.XX --> 80.XX.XX.XX netmask 0x
inet6 2001:XX:XX:7c5:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
pltime 604755 vltime 2591955
inet6 2001:XX:XX:7c5:XX:XX:XX:30c ->  prefixlen 64 autoconf
autoconfprivacy pltime 37915 vltime 556755

I got the new 2001:XX:XX:7c5::/64 prefix after the reconnect and OpenBSD
added it to my interface.

But it didn't remove the now invalid and no longer working
2001:XX:XX:6f3::/64 prefix addresses which caused quite some issues as
my NAT was still using that address for part of the connections.

Shouldn't those be removed as soon as their prefix is no longer valid?
Or at least all be deprecated?

Daniel

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: Making IPv6 NAT prefer privacy address

2015-09-24 Thread Daniel Gillen
On 23/09/2015 16:16, Marios Makassikis wrote:
> On 23 September 2015 at 15:34, Giancarlo Razzolini  
> wrote:
>> Em 23-09-2015 04:40, Stuart Henderson escreveu:
>>> Saves messing about with DHCPv6-PD
>>
>> I see. So you translate from what exactly? Wouldn't it be better to use
>> af-to instead of nat?
> 
> Hello,
> 
> Rather than announcing the prefix obtained via DHCPv6-PD you can pick a prefix
> from fd00::/8 and announce that on your network.
> It is the equivalent to RFC1918 addresses, except it is for IPv6.
> Therefore, it is
> not routable and you need to perform NAT on it. The global address is the one
> the router obtained via static configuration/SLAAC/DHCPv6, which will then be
> used by all your clients.
> 
>> But I can relate to that, given that my CPE will
>> give me a PD, but won't route packets back because it thinks the prefix
>> is reachable using NDP. Hence the need for a proxy, which OpenBSD
>> currently doesn't have.
>>
>> Cheers,
>> Giancarlo Razzolini
>>
> 
> Your CPE will see only the OpenBSD router's address so it should work.
> 
> Marios
> 

And that's exactly what I am doing. Well, I don't use DHCP but rather
assign the fd00::/8 addresses statically, but for the rest, it's the same.

Why NAT? I'm using pppoe to establish a connection to my ISP. And for
every new connection, I get new IPv4 and IPv6 addresses. This is at home
and I don't want my machines being accessible from the internet (except
for some specific ports to some specific machines). As the addresses
change all the time, firewalling would be quite difficult. SO NAT is
very useful here :)

But with that configuration, the problem is that all outgoing traffic
(after the NAT) will use the main IPv6 address of the external interface
(auto configured) or will pick one dynamically (auto configured /
privacy address) (depending on the match statement in pf.conf).

I think I will try to write a script to periodically check if the
privacy address has changed and then update my pf.conf for now.

But it would be a nice feature to be able to use something like
egress:privacy for example or make pf automagically prefer the privacy
addresses when natting:)

Daniel



Making IPv6 NAT prefer privacy address

2015-09-22 Thread Daniel Gillen
Hi

I currently have the following rule to nat traffic out to the internet:

match out on $if_ext inet6 from $if_int:network to any nat-to ($if_ext)

But this chooses from one of the configures addresses (using round-robin).

Is there a way I can configure pf to prefer the privacy address (the one
without my MAC in it)?

Thx in advance

Daniel

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Re: Unable to use static ipv6 address on an if when another if has ipv6 autoconf enabled

2015-09-19 Thread Daniel Gillen
On 19.09.2015 11:17, Stuart Henderson wrote:
> On 2015-09-18, Daniel Gillen <gillen.dan...@gmail.com> wrote:
>> If I remove the "inet6 autoconf" line from the hostname.pppoe0 file, I
>> don't receive an ipv6 address from my ISP anymore (which is normal) but
>> now my internal ipv6 network works.
> ..
>> Btw, I applyed this patch
>> (https://marc.info/?l=openbsd-cvs=142730518728044=2) to enable IPv6
>> forwarding and SLAAC at the same time to my kernel, but that does not help.
> 
> This was fixed here:
> 
> -
> PatchSet 1074
> Date: 2015/08/25 00:26:43
> Author: mpi
> Branch: HEAD
> Tag: (none)
> Log:
> Start moving away from the global prefix list by limiting its usage to
> AUTOCONF'd addresses.
> 
> This prevent the kernel from removing connected (/64) routes as soon as
> it configures an AUTOCONF'd address based on a RA.
> 
> Tested by sebastia@, ok sthen@
> 
> Members:
> in6.c:1.167->1.168
> in6_ifattach.c:1.92->1.93
> nd6.c:1.147->1.148
> nd6.h:1.46->1.47
> nd6_rtr.c:1.118->1.119
> 
> -
> 
> IIRC it depends on some previous commits too. So this is in snapshots
> but is post-5.8.
> 
> Are you able to use static addressing towards your ISP as a work-around
> for now? If not then moving to a snapshot is probably the simplest option
> (and stay on snapshots until 5.9).
> 

Thx for that

Unfortunately, static addressing is not possible, well it would, but it
costs 25€/month :(

But -current seems to fix it.

Unfortunately, I think I have another issue now as OpenBSD does not send
any "Packet Too Big" icmpv6 messages to my internal hosts (need to scrub
to 1440 in pf.conf due to pppoe). But I'll check this further and then
open a new thread here if I can't make it work.

Thx again

Daniel

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!



Unable to use static ipv6 address on an if when another if has ipv6 autoconf enabled

2015-09-18 Thread Daniel Gillen
Hi list

I'm having some trouble setting up my home router under OpenBSD
5.7-stable and hope you can help me.

My setup:

I'm connecting to my ISP trough pppoe and basically my box should do
ipv4 and ipv6 NAT for anything that comes from my local network.

For the sake of easyness, I'm using the following addresses on my local
network:

IPv4: 192.168.0.0/24 with 192.168.0.1 set to my obsd box.
IPv6: fd00::192:168:0:0/112 with fd00::192:168:0:1 set to my obsd box.

My /etc/hostname.pppoe0 looks like this:

# cat /etc/hostname.pppoe0
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev vlan35 \
authproto pap \
authname "XXX" \
authkey "XXX"
dest 0.0.0.1
inet6 autoconf
!/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
!/sbin/route add ::/0 -ifp pppoe0 fe80::

and my /etc/hostname.em2 looks like this:

# cat /etc/hostname.em2
inet 192.168.0.1 255.255.255.0
inet6 fd00::192:168:0:1/112

With the above pppoe config, I can connect to my ISP and receive an ipv4
and ipv6 address but unfortunately, the ipv6 connection on my local
network won't work.

No route for my local fd00::192:168:0:0/112 network is added:

# route -n show -inet6 | grep fd00
fd00::192:168:0:1  00:90:0b:33:6c:3d  HLl 0 0 - 1 lo0

and I am unable to ping any ipv6 host in my local network.

If I remove the "inet6 autoconf" line from the hostname.pppoe0 file, I
don't receive an ipv6 address from my ISP anymore (which is normal) but
now my internal ipv6 network works.

# route -n show -inet6 | grep fd00
fd00::192:168:0:0/112 link#4 UC 1 0 - 4 em2
fd00::192:168:0:1  00:90:0b:33:6c:3d  HLl 0 0 - 1 lo0

Is this a bug in OpenBSD 5.7 stable or am I too dumb to configure it?

Thx for any help

Btw, I applyed this patch
(https://marc.info/?l=openbsd-cvs=142730518728044=2) to enable IPv6
forwarding and SLAAC at the same time to my kernel, but that does not help.

Daniel



Re: upgrade openbsd partition cipher

2015-06-18 Thread Daniel Gillen
On 18.06.2015 22:24, Ultramedia Libertad wrote:
 cd /dev  MAKEDEV sd3

try: cd /dev  ./MAKEDEV sd3



pppoe over vlan problem

2013-09-24 Thread Daniel Gillen
Hi list

I recently upgraded my firewall from OpenBSD 5.0 to 5.3 (i386).
Unfortunately, after the upgrade process, my pppoe connection to my ISP
didn't work anymore.

I'm using kernel pppoe with the following setup:

/etc/hostname.xl1:
  up

/etc/hostname.vlan0:
  vlan 35 vlandev xl1 up

/etc/hostname.pppoe0:
inet 0.0.0.0 255.255.255.255 0.0.0.1 \
  pppoedev vlan0 \
  authproto pap authname login authkey pass \
  up
!/sbin/route add default -ifp pppoe0 0.0.0.1

After some debugging with tcpdump, I found out that from 5.0 to 5.1,
OpenBSD introduced vlan priorisation support (IEEE 802.1p) and per
default sets the vlan PCP field to the value 3.

Unfortunately, my ISP only allows connections when this field is set to 0 :(

As a work-around, I removed the setting of this field from the kernel
and now it works but I wonder if there isn't a better way to solve my issue.

According to the vlan(4) manpage, this should be fixable using a pf
rule. I tried all the following (with and without out) but none worked :(

match out on vlan0 set prio 0
pass out on vlan0 set prio 0
match out on pppoe0 set prio 0
pass out on pppoe0 set prio 0

Any ideas are welcome.

Thx in advance

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!