Re: VLAN in 5.9 - NAT problem
pass out on rl0 inet from vlan309:network to any nat-to rl0
match out on rl0 inet from vlan:309:network nat-to rl0
pass out on rl0
Since you did not submit a full pf.conf, I have no chance of knowing if you do
a later pass that changes the NAT state.
You could use tags for more fine-grained control.
#cat /etc/rc.conf.local
dhcpd_flags="vlan300 vlan308 vlan309 vlan310 vlan311 vlan400"
pf_rules=/etc/pf.conf
#cat /etc/dhcpd.interfaces
vlan300
vlan308
vlan309
vlan310
vlan311
vlan400
#cat /etc/hostname.em0
up
#cat /etc/hostname.em1
up
#cat /etc/hostname.trunk0
trunkproto lacp trunkport em0 trunkport em1 lladdr 00:01:02:03:11:11
up
#cat /etc/hostname.vlan300
inet 10.0.30.254 255.255.255.0 NONE vlan 300 vlandev trunk0 lladdr
00:01:02:03:03:00 description "Interface VLAN-SERV"
#cat /etc/hostname.vlan308
inet 10.0.8.254 255.255.255.0 NONE vlan 308 vlandev trunk0 lladdr
00:01:02:03:03:08 description "Interface VLAN-308I"
#cat /etc/hostname.vlan309
inet 10.0.9.254 255.255.255.0 NONE vlan 309 vlandev trunk0 lladdr
00:01:02:03:03:09 description "Interface VLAN-309I"
[...]
@2. Then I removed trunk0. DHCPserver works, clients get IP. NAT does not work
still.
#cat /etc/pf.conf [changed to very short and simple for tests]
pass out on rl0 inet from vlan309:network to any nat-to rl0
#cat /etc/rc.conf.local
dhcpd_flags="vlan300 vlan308 vlan309 vlan310 vlan311 vlan400"
pf_rules=/etc/pf.conf
#cat /etc/dhcpd.interfaces
vlan300
vlan308
vlan309
vlan310
vlan311
vlan400
#cat /etc/hostname.em0
up
#cat /etc/hostname.vlan300
inet 10.0.30.254 255.255.255.0 NONE vlan 300 vlandev em0 lladdr
00:01:02:03:03:00 description "Interface VLAN-SERV"
#cat /etc/hostname.vlan308
inet 10.0.8.254 255.255.255.0 NONE vlan 308 vlandev em0 lladdr
00:01:02:03:03:08 description "Interface VLAN-308I"
#cat /etc/hostname.vlan309
inet 10.0.9.254 255.255.255.0 NONE vlan 309 vlandev em0 lladdr
00:01:02:03:03:09 description "Interface VLAN-309I"
[...]
@3. Finally, I removed VLANs and NAT started to work.
#cat /etc/pf.conf [changed to very short and simple for tests]
pass out on rl0 inet from em0:network to any nat-to rl0
#cat /etc/rc.conf.local
dhcpd_flags="em0"
pf_rules=/etc/pf.conf
#cat /etc/dhcpd.interfaces
em0
#cat /etc/hostname.em0
inet 10.0.8.254 255.255.255.0 NONE lladdr 00:01:02:03:03:08 description
"Interface VLAN-308"
#dmesg
OpenBSD 5.9 (GENERIC) #1561: Fri Feb 26 01:22:37 MST 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) CPU 2.93GHz ("GenuineIntel" 686-class) 2.93 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,xTPR,PERF
real mem = 2137800704 (2038MB)
avail mem = 2084323328 (1987MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 08/26/04, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.3 @
0xfb21f (4 entries)
bios0: vendor American Megatrends Inc. version "P1.80" date 08/26/2004
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC OEMB
acpi0: wakeup devices P0P4(S4) MC97(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4)
EUSB(S4) PS2K(S4) PS2M(S4) UAR1(S4) GBEN(S4) SLPB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P4)
acpicpu0 at acpi0: C1(@1 halt!)
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
bios0: ROM list: 0xc/0xa000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82865G Host" rev 0x02
inteldrm0 at pci0 dev 2 function 0 "Intel 82865G Video" rev 0x02
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xf000, size 0x800
inteldrm0: apic 1 int 16
inteldrm0: 1920x1080
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: apic 1 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: apic 1 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801EB/ER USB" rev 0x02: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801EB/ER USB" rev 0x02: apic 1 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb0 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xc2
pci1 at ppb0 bus 1
1:3:0: mem address conflict 0xfffc/0x4
em0 at pci1 dev 3 function 0 "Intel 82546EB" rev 0x01: apic 1 int 20, address
00:11:0a:62:f3:42
em1 at pci1 dev 3 function 1 "Intel 82546EB" rev 0x01: apic 1
Huawei ME909u-521 - cannot find data bulk in
Hi Needing a backup connection to the internet, I decided to give the Huawei 909u-521 a try. Hardware details: http://consumer.huawei.com/en/solutions/m2m-solutions/products/tech-specs/me909u-521mini-pcie-en.htm It's mounted in a Soekris 6501 device. During boot, the following information is given; cdce0 at uhub1 port 1 configuration 2 interface 0 HUAWEI Technology HUAWEI Mobile rev 2.00/2.28 addr 2 cdce0: could not find data bulk in ugen0 at uhub1 port 1 configuration 2 HUAWEI Technology HUAWEI Mobile rev 2.00/2.28 addr 2 A little more information.. $ usbdevs -dv ... Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 uhub1 port 1 addr 2: high speed, power 500 mA, config 2, HUAWEI Mobile(0x1573), HUAWEI Technology(0x12d1), rev 2.28, iSerialNumber 0123456712ABCA17 cdce0 ugen0 port 2 powered port 3 powered ... So, the device seems to be detected, but some tweaking might be required. Many USB devices notoriously fail to report their class and interfaces correctly. Undetected products might work flawlessly when their vendor and product IDs are added to the driver manually. Can anyone tell me how to move on from this point, what steps are needed to get the id's added manually? -- Regards Brian
Re: Duplicate pf rules when using groupname
Stuart Henderson skrev den 2015-04-28 15:55: Actually this is a bit odd, can't reproduce it here on 5.5 or -current. I'm running 5.5 GENERIC.MP SHA256 (/sbin/pfctl) = 9b84b5b3d846cf2f4c4a189d9711cc5d00c4ea096431df4eaea57ebfcd29de8c
Re: Duplicate pf rules when using groupname
Using a single interface (ex. vlan) will only produce one line (as I expect it to do) in the pfctl -s rules output. This is probably the simplest fix. The actual packets you want to filter show up on the vlan interfaces anyway. You'r right, this would be the best solution at the momemnt. My question is: Why are pf making 4 identical rules when using groupnames? The rule is expanded like this: from carpX:network to carpY:network from carpX:network to vlanY:network from vlanX:network to carpY:network from vlanX:network to vlanY:network It all makes sense now, thank you. I actually tried using the -vg option, hoped that I might get some interface details/id(s) attached to the rule. That would have explained it too. But then again, it is not pf's job :) So you can see how it happens. There would need to be some extra logic in pfctl to suppress duplicates to avoid this. Yes, but other programs show it the same way, tried with pftop, it will also display the duplicates.
Duplicate pf rules when using groupname
Hi, I'm getting a strange output from pfctl that I cannot explain, perhaps someone lurking the list have the answer? When using interface groupnames in my pf.conf, I see the same rule 4 times when doing a pfctl -s rules. The interface group i'm using, have a vlan and carp member. Ex. pass in on groupA from groupA:network to groupB:network tag A_TO_B Will produce something like (pfctl -s rules); ... pass in on groupA inet from 1.2.3.0/24 to 5.6.7.0/24 flags S/SA keep state (pflow) tag A_TO_B pass in on groupA inet from 1.2.3.0/24 to 5.6.7.0/24 flags S/SA keep state (pflow) tag A_TO_B pass in on groupA inet from 1.2.3.0/24 to 5.6.7.0/24 flags S/SA keep state (pflow) tag A_TO_B pass in on groupA inet from 1.2.3.0/24 to 5.6.7.0/24 flags S/SA keep state (pflow) tag A_TO_B ... Using a single interface (ex. vlan) will only produce one line (as I expect it to do) in the pfctl -s rules output. My question is: Why are pf making 4 identical rules when using groupnames? -- Kind regards Brian S. Vangsgaard
Re: Duplicate pf rules when using groupname
Lists
A list allows the specification of multiple similar criteria within a
rule.
For example, multiple protocols, port numbers, addresses, etc. So,
instead of
writing one filter rule for each IP address that needs to be blocked,
one rule
can be written by specifying the IP addresses in a list. Lists are
defined by
specifying items within { } brackets.
When pfctl(8) encounters a list during loading of the ruleset, it
creates
multiple rules, one for each item in the list.
But the rule I wrote, does not use a list (if we define a list by the
use of {}).
I'm aware that PF at some point expand the groupname into some sort of
list,
but that list would have two items, not four?
Thank you for the input, but I dont see lists as being the answer to
the question.
Re: L2TP using Npppd and IPsec
Hi, for the talk he gave at BSDCan IIRC. I don't need to use RADIUS just a local authentication database. It is in the base and it seems very easy to configure. It is. Is anybody running similar setup in production? Any caveats? Any other advises before I take a plunge. Yes I am, with Windows, Mac, Linux and OpenBSD clients connecting. Very easy to configure (linux being the exception :p). You only need to change npppd.conf, npppd-users and ipsec.conf and you are in business. I wrote an up-to-date guide on how to do it, let me know if you want a copy. Caveats... yes. I'm currently seeing issues with some clients (might be a client software issue) sending multiple connect requests. The ip-address reserved for the client is being assigned to the first request, but it seems like the last request wins, but alas! no ip-address available (since it was assigned to the first request). But then again, I have some Windows clients connected for more than 2 weeks non-stop, before they disconnect (prob. a Windows update wanting to reboot ;) ). -- bsv
