Re: PPPoE vlan issue 6.4
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
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
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?
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. Martinezwrote: >>> 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
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
On 25.08.2016 14:46, Kamil Cholewiński wrote: > On Thu, 25 Aug 2016, Gilles Chehadewrote: >> 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
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
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 ?
On 28/04/2016 05:07, Jeremy wrote: > On Tue, 26 Apr 2016 17:53:32 -0500 > Adam Thompsonwrote: >> 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 ?
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
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
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
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?
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
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
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
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
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
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=208851mtu 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
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
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
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
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
On 18.06.2015 22:24, Ultramedia Libertad wrote: cd /dev MAKEDEV sd3 try: cd /dev ./MAKEDEV sd3
pppoe over vlan problem
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!