correct way to clear sensitive data from env?
hi, case in point: openvpn passing username/password in the environment to openvpn_bsdauth. so there's actually a bit of a sensitive data in env that current wisdom rightly tends to want to junk as soon as possible. getenv(3) states, "If getenv() is successful, the string returned should be considered read-only.", operative word being "should". what's the correct way to deal with this (specifically on openbsd if there are any facilities that help here, as well as on other systems perhaps)? thanks, -- [-] mkdir /nonexistent
4.0-stable panic with pppoe(4)
ok, so i'm not *entirely* sure it's with pppoe(4), but as far as i can put bits and pieces together, it's always happening after ifconfig pppoe0 down; ifconfig pppoe0 destroy and then either sh /etc/netstart pppoe0 or (the second case) starting ppp(8). box has 4 interfaces, one of them (vr0) is unused. fxp0 is plain ethernet, there's a plain old pppoe(8)/ppp(8) driving fxp1 (these are the ppp/pppoe processes that can be seen in the process list), and rl0 is driven by pppoe(4). i'm switching back and forth between pppoe(4) and pppoe/ppp on this one, panic always seems to occur a couple of seconds after the last command (see above) is given. it doesn't happen absolutely all the time, but it does happen quite regularly every other day or so. thanks for any ideas. login: pppoe0: LCP keepalive timeoutmultiply freed item 0xd0c62480 panic: free: duplicated free Stopped at Debugger+0x4: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND 32587 5086 5086 0 30x86 netio tcpdump 5086 7823 5086 76 3 0x4186 bpftcpdump 13042 28245 13042 0 3 0x4086 ttyin ksh 28245 5850 28245 0 3 0x4184 select sshd 7823 24482 7823 0 3 0x4086 pause ksh 24482 5850 24482 0 3 0x4184 select sshd 13534 1 13534 0 3 0x4086 ttyin getty 29162 1 29162 0 3 0x4086 ttyin getty 27900 1 27900 0 3 0x4086 ttyin getty 5419 1 5419 0 3 0x4086 ttyin getty 0 1 0 0 3 0x4086 ttyin getty 26509 1 26509 0 3 0x4086 ttyin ksh 30944 1 30944 0 30x84 select cron 9208 17357 17357 62 3 0x184 piperd spamd 15575 17357 17357 62 3 0x184 select spamd 17357 1 17357 62 3 0x184 nanosleep spamd 5850 1 5850 0 30x84 select sshd 12694 23856 23856 83 3 0x184 poll ntpd 23856 1 23856 0 30x84 poll ntpd *32613 17223 17223 68 7 0x104 isakmpd 17223 1 17223 0 30x84 netio isakmpd 3938 23555 23555 70 3 0x184 select named 23555 1 23555 0 3 0x184 netio named 14867 15702 15702 73 2 0x184 syslogd 15702 1 15702 0 30x8c netio syslogd 2944 1 5430 82 3 0x4184 select pppoe 5430 1 5430 0 3 0x40184 select ppp 12 0 0 0 30x100204 crypto_wa crypto 11 0 0 0 30x100204 aiodoned aiodoned 10 0 0 0 30x100204 syncer update 9 0 0 0 30x100204 cleanercleaner 8 0 0 0 30x100204 reaper reaper 7 0 0 0 30x100204 pgdaemon pagedaemon 6 0 0 0 30x100204 pftm pfpurge 5 0 0 0 30x100204 wait wskbd_hotkey 4 0 0 0 30x100204 usbtsk usbtask 3 0 0 0 30x100204 usbevt usb0 2 0 0 0 30x100204 kmallockmthread 1 0 1 0 3 0x4084 wait init 0 -1 0 0 3 0x80204 scheduler swapper ddb trace Debugger(d0716a84,d0cc0800,daf08c60,d0c62480,9) at Debugger+0x4 panic(d065e4d1,d0c62480,46045c3d,0,db0f9300) at panic+0x63 free(d0c62480,9,14,d0cc0800) at free+0x40 ifafree(d0c62480,daf08e3c,daf08d30,d3c84a6c) at ifafree+0x27 rtfree(d3ca843c,0,daf08d30,d039b67e) at rtfree+0x8d in_selectsrc(d3cd3014,d3c84a6c,200,0,daf08d40,813e46c3,0,daf08e08) at in_select src+0x135 in_pcbconnect(d3c84a24,d3cd3000,daf08d80,0) at in_pcbconnect+0x137 udp_output(d3d09e00,d3c84a24,d3cd3000,0,0) at udp_output+0xa8 sosend(d3c838cc,d3cd3000,daf08e38,d3d09e00,0,0,10,3) at sosend+0x389 sendit(d3d5ae14,1c,daf08ed8,0,daf08f58) at sendit+0x157 sys_sendmsg(d3d5ae14,daf08f68,daf08f58,87a59380,daf08f58) at sys_sendmsg+0x79 syscall() at syscall+0x2ea --- syscall (number 28) --- 0x1c097411: ddb == login: multiply freed item 0xd0c00600 panic: free: duplicated free Stopped at Debugger+0x4: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb trace Debugger(d0716a84,d076e4e0,d089eca4,d0c00600,9) at Debugger+0x4 panic(d065e4d1,d0c00600,d089ed14,d038876e,2) at panic+0x63 free(d0c00600,9,0,0) at free+0x40 ifafree(d0c00600,d089ed7c,d089ed84,d039b1e4) at ifafree+0x27 rtfree(d3cb42f8,0,0,5) at rtfree+0x8d in_losing(d3c036c8,1900,d089edc4,d032f91a,d0716968) at in_losing+0x62
Re: Password escrow
On Thu, 13 Jul 2006, Chris Kuethe wrote: Secret Sharing schemes. http://freshmeat.net/projects/sharesecret/ http://freshmeat.net/projects/shsecret/ also http://freshmeat.net/projects// -- [-] mkdir /nonexistent
Re: cruft?
On Tue, 20 Dec 2005, J.C. Roberts wrote: I hit a panic while doing make build on the Alpha PSW-433. My uneducated guess http://marc.theaimsgroup.com/?t=11082572061r=1w=2 -- [-] mkdir /nonexistent
Re: isakmpd does not enter phase 2
On Tue, 20 Dec 2005, Matthew Closson wrote: matt, all, [Remote-peer-quick-mode] EXCHANGE_TYPE= QUICK_MODE Transforms= QM-ESP-3DES-SHA-SUITE notice the typo (s/Transforms/Suites/ for correct operation) that only became obvious after a healthy dose of sleep. thanks anyway. -- [-] mkdir /nonexistent
isakmpd does not enter phase 2
hello, dec 18 snap, running on i386 given is an ipsec gateway (i think it's running some older openswan or some other swan) to which i need to connect, establishing a net-net tunnel. the parameters needed are IKE rekeying 1440 minutes (24 hours), IPSEC 3600 seconds (1 hour), both with 3DES/SHA1, no PFS, and these are carved in stone, i was told. i can't seem to get isakmpd to establish a tunnel with that site. it seems as if phase 1 would have been negotiatied fine, but when isakmpd then sends an `initial contact', then gets back an ipv4_addr, then things literally stop happening here. i checked isakmpd packet dumps on other machines, and from what i gather, here my isakmpd is the one who should start entering into phase 2 negotiations, but that never happens. that's what the packet log tells me (X.Y.Z.185 is isakmpd, the local side; A.B.C.42 is the remote side) Dec 20 03:45:23.465777 0.0.0.0.500 A.B.C.42.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0- msgid: len: 164 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 00015180 payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports NAT-T, RFC 3947) payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 192) Dec 20 03:45:23.530916 A.B.C.42.500 X.Y.Z.185.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0-83821d77d8a07cd2 msgid: len: 84 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 1 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 00015180 [ttl 0] (id 1, len 112) Dec 20 03:45:23.548557 X.Y.Z.185.500 A.B.C.42.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0-83821d77d8a07cd2 msgid: len: 180 payload: KEY_EXCH len: 132 payload: NONCE len: 20 [ttl 0] (id 1, len 208) Dec 20 03:45:24.141436 A.B.C.42.500 X.Y.Z.185.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0-83821d77d8a07cd2 msgid: len: 184 payload: KEY_EXCH len: 132 payload: NONCE len: 24 [ttl 0] (id 1, len 212) Dec 20 03:45:24.162027 X.Y.Z.185.500 A.B.C.42.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0-83821d77d8a07cd2 msgid: len: 92 payload: ID len: 12 type: IPV4_ADDR = X.Y.Z.185 payload: HASH len: 24 payload: NOTIFICATION len: 28 notification: INITIAL CONTACT (636b40261faa87b0-83821d77d8a07cd2) [ttl 0] (id 1, len 120) Dec 20 03:45:24.899941 A.B.C.42.500 X.Y.Z.185.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0-83821d77d8a07cd2 msgid: len: 68 payload: ID len: 12 type: IPV4_ADDR = A.B.C.42 payload: HASH len: 24 [ttl 0] (id 1, len 96) and then silence. there's nothing not even down the road (i waited for like 20 minutes for something, anything to happen) as `no proposal chosen', or any other kind of message that would give a clue as to where to start. with an other peer, at this point i also see Dec 20 03:55:29.817971 me.500 otherpeer.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 857f6ffe85cd2ad6-3d173193c107d434 msgid: len: 228 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D-DRAFT len: 24 payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256) Dec 20 03:55:29.914622 otherpeer.500 me.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 857f6ffe85cd2ad6-3d173193c107d434 msgid: len: 228 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D-DRAFT len: 24 payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256) and this is when phase2 negotiations actually begin, and eventually complete, and a tunnel is established. the
Re: Alpha Disklabel Question
On Fri, 16 Dec 2005, J.C. Roberts wrote: (1) When booting the cd38.iso with either bsd or bsd.rd you go into UKC rather than directly into the installation. I'm guessing this is normal since I'm sure there might be some things that need doing for some of the more esoteric alpha hardware but it's worth asking to make sure. you probably have a rogue `-s' in boot_osflags (try `show boot_osflags' or even `show boot*' in srm). -- [-] mkdir /nonexistent
Re: Alpha Disklabel Question
On Fri, 16 Dec 2005, J.C. Roberts wrote: Eventually, the boot_osflags in the SRM needs to be set to a but the default is A -The case would make no difference for some OS's but OpenBSD probably won't like it. ;-) fwiw i've been doing fine with `A' for ages. -- [-] mkdir /nonexistent
Re: pf.conf(5) buglet wrt logging
On Sat, 10 Dec 2005, Adriaan Misc wrote: I interpret it that you need a pass before the log ;) that was unfair. sorry for the noise :( -- [-] mkdir /nonexistent
pf.conf(5) buglet wrt logging
hi,
diff below removes the `log' keyword from the nat, binat and rdr bnf
descriptions. ok, i can't quite read code as much to actually verify
the validity of this, but i simply couldn't get it to work (it doesn't
seem so hard to insert a `log' between a `nat' and a `pass' in an
otherwise working setup now does it?), didn't find any references
doing so anyplace, and seem to remember something about it being
removed (but it may have well been log-all...).
questions: if the diff below is not correct, what's the correct syntax
for logging in a nat(/binat/rdr) rule? nat on pcn0 from
192.168.1.0/24 to any - (pcn0) works fine, nat log on pcn... gives
a syntax error).
if the diff below is correct, how can one log nats/rdrs/binats as they
happen?
thanks,
Index: pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.339
diff -u -r1.339 pf.conf.5
--- pf.conf.5 17 Nov 2005 22:18:20 - 1.339
+++ pf.conf.5 10 Dec 2005 01:45:27 -
@@ -2639,21 +2639,18 @@
queue ( string | ( string [ [ , ] string ] ) ) |
probability number%
-nat-rule = [ no ] nat [ pass [ log [ ( logopts ) ] ] ]
- [ on ifspec ] [ af ]
+nat-rule = [ no ] nat [ pass ] [ on ifspec ] [ af ]
[ protospec ] hosts [ tag string ] [ tagged string ]
[ - ( redirhost | { redirhost-list } )
[ portspec ] [ pooltype ] [ static-port ] ]
-binat-rule = [ no ] binat [ pass [ log [ ( logopts ) ] ] ]
- [ on interface-name ] [ af ]
- [ proto ( proto-name | proto-number ) ]
+binat-rule = [ no ] binat [ pass ] [ on interface-name ]
+ [ af ] [ proto ( proto-name | proto-number ) ]
from address [ / mask-bits ] to ipspec
[ tag string ] [ tagged string ]
[ - address [ / mask-bits ] ]
-rdr-rule = [ no ] rdr [ pass [ log [ ( logopts ) ] ] ]
- [ on ifspec ] [ af ]
+rdr-rule = [ no ] rdr [ pass ] [ on ifspec ] [ af ]
[ protospec ] hosts [ tag string ] [ tagged string ]
[ - ( redirhost | { redirhost-list } )
[ portspec ] [ pooltype ] ]
--
[-]
mkdir /nonexistent
pf weirdness with pfctl -f nonexistent.file
hi, i just observed a strange phenomenon, which, if it's intended behavior, i could not really find it documented anywhere (or failed to understand the doc, if it is). in its simplest form, it is as follows. given is a machine with a de0, part of a simple lan. the following configuration is loaded into pf: -- set skip on de0 block log all pass in on de0 from 192.168.1.10 to any keep state -- i'm logged in from 192.168.1.12 via de0, make a fat-fingered typo of `pfctl -f all' (instead of -F all), poof, get thrown out (connection reset by peer). from 192.168.1.10, the box is accessible. logged in from 1.10, looked around, generally everything looks ok, pfctl -sa shows the rules, shows pf enabled, whatnot, but it acts as if the `set skip on de0' part was somehow forgotten. i can not verify my suspicion as i couldn't find a way to get the current (as in `loaded into the kernel') `skip these interfaces' list (shouldn't that be included in -sr anyway?), but i couldn't find any other explanations. reproducible on 3.8-stable i386 and -current (as of 2-3 days ago) alpha. what's that? thanks, -- [-] mkdir /nonexistent
Re: pf weirdness with pfctl -f nonexistent.file
On Fri, 11 Nov 2005, Daniel Hartmeier wrote: I'm pretty sure your theory is correct. You can query the list of interfaces with pfctl -vsI, which prints '(skip)' on those that are currently being skipped. ah, yes, thank you. i did check, and yes, it's the skip flag that gets cleared. Reloading the ruleset does (and should) clear the 'set skip' set, as we agreed that there should be no (or as little as possible) state in the kernel that persists across ruleset reloads. Other options are similarly cleared on reload (and then re-instated, if you reload a ruleset similar to the old one). So loading an empty ruleset should clear all such options. Now, if the ruleset doesn't exist at all (I assume you didn't have a file called 'all' lying in the cwd when running pfctl -f all), I guess nothing should happen except for the error message. I'll check about that. Or what would you prefer instea exactly that. unless there's some master idea i'm not aware of (or can't think of), that seems to be the most reasonable behavior, no? -- [-] mkdir /nonexistent
Re: alpha panic; cpu_initclocks: no clock attached
On Thu, 15 Sep 2005, Miod Vallat wrote: This problem is caused by a bug in sys/dev/pci/pciide.c. If you revert it to revision 1.201, your kernel will work again on your machine. confirmed. by the time i woke up, jsg already reverted it in cvs, i just took that. machine is a happy hippo again. thanks, -- [-] mkdir /nonexistent
alpha panic; cpu_initclocks: no clock attached
hi, i ultimately wanted to try martin reindl's alpha patch on my pws500au (even if i wouldn't have scored extra anyway), when i realized my alpha was hosed, so i grabbed the sept 10 snapshot, installed it fine, cvs'd src/, compiled a generic kernel, and upon reboot: [...] sd0 at scsibus1 targ 0 lun 0: DEC, RZ2CC-KB (C) DEC, DC2B SCSI2 0/direct fixed sd0: 4091MB, 3708 cyl, 20 head, 113 sec, 512 bytes/sec, 8380080 sec total root on sd0a swap on sd0b panic: cpu_initclocks: no clock attached Stopped at Debugger+0x4: ret zero,(ra) RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb trace Debugger(0, fc789598, 5, 8, 3, 8) at Debugger+0x4 panic(fc764f46, 48, 0, 0, 0, fc702a90) at panic+0x130 cpu_initclocks(?, 48, 0, 0, 0, fc702a90) at cpu_initclocks+0x3c initclocks(?, 48, 0, 0, 0, fc702a90) at initclocks+0x2c main(?, ?, ?, ?, 0, fc702a90) at main+0x4b8 __start(?, ?, ?, ?, 0, fc702a90) at __start+0x64 __start(?, ?, ?, ?, 0, fc702a90) at __start+0x64 __start(?, ?, ?, ?, 0, fc702a90) at __start+0x64 [ repeating seemingly indefinitely ] ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND *0 -1 0 0 7 0x80204 swapper ddb i seem to remember having this about a week ago too (that was when the box got hosed, but i didn't have time to investigate it further, i thought i screwed something up), but definitely before sept 10. for quick reference, here's the diff between the dmesg of the snapshot kernel and that of the -current one (both of them are there in full towards the end of this mail): -OpenBSD 3.8 (GENERIC) #587: Sat Sep 10 15:55:00 MDT 2005 -[EMAIL PROTECTED]:/usr/src/sys/arch/alpha/compile/GENERIC +OpenBSD 3.8-current (GENERIC) #0: Wed Sep 14 14:38:19 CEST 2005 +[EMAIL PROTECTED]:/usr/src/sys/arch/alpha/compile/GENERIC -avail memory = 226942976 (221624K) +avail memory = 226934784 (221616K) -sio0 at pci0 dev 7 function 0 Contaq Microsystems CY82C693U ISA rev 0x00 -pciide0 at pci0 dev 7 function 1 Contaq Microsystems CY82C693U ISA rev 0x00: DMA, channel 0 wired to compatibility -pciide0: channel 0 disabled (no drives) -pciide1 at pci0 dev 7 function 2 Contaq Microsystems CY82C693U ISA rev 0x00: no DMA, channel 0 wired to compatibility -atapiscsi0 at pciide1 channel 0 drive 0 +pciide0 at pci0 dev 7 function 0 Contaq Microsystems CY82C693U ISA rev 0x00: unexpected PCI function 0 +pciide1 at pci0 dev 7 function 1 Contaq Microsystems CY82C693U ISA rev 0x00: DMA, channel 0 wired to compatibility +pciide1: channel 0 disabled (no drives) +pciide2 at pci0 dev 7 function 2 Contaq Microsystems CY82C693U ISA rev 0x00: no DMA, channel 0 wired to compatibility +atapiscsi0 at pciide2 channel 0 drive 0 -cd0(pciide1:0:0): using PIO mode 4 -ohci0 at pci0 dev 7 function 3 Contaq Microsystems CY82C693U ISA rev 0x00: isa irq 10, version 1.0, legacy support -usb0 at ohci0: USB revision 1.0 -uhub0 at usb0 -uhub0: Contaq Microsys OHCI root hub, rev 1.00/1.00, addr 1 -uhub0: 2 ports with 2 removable, self powered +cd0(pciide2:0:0): using PIO mode 4 +pciide3 at pci0 dev 7 function 3 Contaq Microsystems CY82C693U ISA rev 0x00: unexpected PCI function 3 -isa0 at sio0 -isadma0 at isa0 -com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo -com0: console -com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo -pckbc0 at isa0 port 0x60/5 -pcppi0 at isa0 port 0x61 -midi0 at pcppi0: PC speaker -spkr0 at pcppi0 -isabeep0 at pcppi0 -lpt0 at isa0 port 0x3bc/4 irq 7 -fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 -fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec -mcclock0 at isa0 port 0x70/2: mc146818 or compatible -stray isa irq 3 -ural0 at uhub0 port 2 -ural0: ASUS 802.11g WLAN Drive, rev 2.00/0.01, addr 2 -ural0: MAC/BBP RT2570 (rev 0x03), RF RT2526, address 00:11:2f:6b:e0:e0 -rootdev=0x800 rrootdev=0x800 rawdev=0x802 -stray isa irq 3 also tried booting without the ural device attached, same result (used to work fine anyway). plugging, unplugging and otherwise abusing ural keeps it working fine. with the snapshot kernel, the box behaves absolutely normal. if any other information is needed, happy to provide them as well. thanks, details: show config Firmware SRM Console: V7.2-1Mar 6 2000 14:47:02 ARC Console: 5.70 PALcode: OpenVMS PALcode V1.20-16, Tru64 UNIX PALcode V1.22-18 SROM Version: v5.90 Processor DECchip (tm) 21164A-2 Pass 500 MHz 96 KBytes SCache 2 MB BCache PYXIS ASIC Pass 257 MEMORY Memory Size = 256Mb Bank Size/Sets Base Addr ---- - 0128Mb 1128Mb 0800 BCache Size = 2Mb Tested Memory = 256Mbytes PCI Bus Bus 00 Slot 03: Digital Semiconductor 21143 Network Controller ewa0.0.0.3.0 08-00-2B-86-3E-F2 Bus 00 Slot 07:
Re: Spamd/Postfix behaving strangely
On Sun, 11 Sep 2005, Jason Dixon wrote: Yes, there is a PIX (eventually to be replaced with OpenBSD/PF), but I don't understand how that could interfere. If I remove the external system from spamd-white, I get redirected to spamd as expected: pix interferes in every possible way, but your current particular problem seems to be it fixing smtp. iirc what you will have to tell the pix is `no fixup protocol smtp 25'. or something like that. (unlikely), but I still see the connections in my maillog, so it's not intercepting the SMTP session. yes, it does... -- [-] mkdir /nonexistent
Re: Modifying man pages and composing new ones
On Sun, 21 Aug 2005, Rod.. Whitworth wrote: I suppose that I'm going to have to try to remember something about the [gnt]roff things I had very small experience with back in the '70s So apart from the mdoc-samples man page are there other required/recommended documents for rust-removal / new learning please? to amend jmc and stuart, http;//www.oreilly.com/openbook/utp/ may also be of interest, though its a bit more heavyweight stuff than just man pages (you should follow the link `troff and postscript files--beta'). this is probably the single best resource you can get on *roff today. -- [-] mkdir /nonexistent
multiple Local-IDs for isakmpd
hi,
i have a situation where a branch office with multiple,
non-overlapping, non-aggregatable local networks need to connect to
the head office, via an ipsec tunnel. of course, the security
gateway is also acting as a gateway to the internet (nat and the usual
collateral stuff), and, as a matter of fact, some of the local
networks are connected to it via openvpn (that is, it itself is a vpn
concentrator of sorts, for openvpn tunnels).
rough sketch:
-- branch office -- | | -- head office --
| |
172.16.187.0/24 - | |
172.19.47.0/24 \ +---+ | | +---+
+- |security gw| - (ipsec tun) - |security gw| - ...
192.168.114.0/24 / ++--+ | | +---+
192.168.2.0/24 - |
\
(internet etc..)
it may also be the case that at the head office end, there will be
more than one hosts/networks to be accessed, this is not clarified
yet. i am not in control of the head office's concentrator, but i know
that they are using a cisco 3060.
how is this realized within isakmpd's configuration? i already have
tried putting more than one ipv4_addr_subnets into the ipsec-id
section, and even more than one ipsec-id section, but isakmpd throw
them out (not surprise).
if this cannot be realized within isakmpd, what other options do i
have? pf route-tos/reply-tos are about the only thing i can think
of... anything else?
tia,
--
[-]
mkdir /nonexistent
