no pcap file from isakmpd in OBSD6.6
Hi,
after upgrading openbsd6.5 to oopenbsd6.6 using sysupgrade isakmpd does no
longer write pcap files in /var/run.
In /var/log/messages we see the following message:
isakmpd[7385]: log_packet_init: fopen ("/var/run/isakmpd.pcap", "w") failed:
Permission denied
Any ideas?
Mit freundlichen Grüßen / Best regards / Meilleures salutations
Christoph Leser
Systemtechnik
S Computersysteme GmbH
Systemhaus für Logistik
Zettachring 4
70567Stuttgart
www.sup-logistik.de
T: +49 711 726 41-0
F: +49 711 726 41-70
christoph.le...@sup-logistik.de
Amtsgericht Stuttgart HRB 11921
Geschäftsführer: Horst Reichert, Rémy El Abd
Informationspflicht zur Datenverarbeitung:
Kunden: Hier >>
Dienstleister / Lieferanten: Hier>>
IKEv1 IKEv2 coexistance ?
I read in an 2013 paper by Reyk Floeter about openIKED (https://www.openbsd.org/papers/openiked-asiabsdcon2013.pdf) "The design intends to allow operation of both protocol versions on the same host" but "The unprivileged IKEv1 process is currently an empty stub" Does this mean that I cannot have both IKEv1 and IKEv2 on a single openBSD machine? Is there any way to run iked and isakmpd on the same machine ( maybe with the help of pf to redirect ike2 hosts to a non default port )? Thanks Chis
ipsec outgoing address translation question
Hello, with ipsecctl I can configure outgoing address translation in ipsec.conf like this: ike esp from 10.10.10.1 (192.168.1.0/24) to 192.168.2.0/24 peer 10.10.20.1 Is there an equivalent syntax for isakmpd.conf? ( Due to problems with NAT-T I need to use isakmpd.conf and cannot use ipsec.conf for the moment ) Thanks
Re: ipsec outgoing address translation question
Great hint, you saved me a lot of time. Thanks a lot Christoph -Ursprüngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Christian Weisgerber Gesendet: Montag, 16. September 2013 16:42 An: misc@openbsd.org Betreff: Re: ipsec outgoing address translation question Christoph Leser le...@sup-logistik.de wrote: with ipsecctl I can configure outgoing address translation in ipsec.conf like this: ike esp from 10.10.10.1 (192.168.1.0/24) to 192.168.2.0/24 peer 10.10.20.1 Is there an equivalent syntax for isakmpd.conf? All that ipsecctl does with ike rules is to translate them into a piece of isakmpd.conf-style configuration and pass it to isakmpd's FIFO control socket. Use ipsecctl -n -v to inspect or capture and re-use that output. C set [Phase 1]:10.10.20.1=peer-10.10.20.1 force C set [peer- 10.10.20.1]:Phase=1 force C set [peer-10.10.20.1]:Address=10.10.20.1 force C set [peer-10.10.20.1]:Configuration=phase1-peer-10.10.20.1 force C set [phase1-peer-10.10.20.1]:EXCHANGE_TYPE=ID_PROT force C add [phase1- peer-10.10.20.1]:Transforms=phase1-transform-peer-10.10.20.1-RSA_SIG- SHA-AES128-MODP_1024 force C set [phase1-transform-peer-10.10.20.1- RSA_SIG-SHA-AES128-MODP_1024]:AUTHENTICATION_METHOD=RSA_SIG force C set [phase1-transform-peer-10.10.20.1-RSA_SIG-SHA-AES128- MODP_1024]:HASH_ALGORITHM=SHA force C set [phase1-transform-peer- 10.10.20.1-RSA_SIG-SHA-AES128- MODP_1024]:ENCRYPTION_ALGORITHM=AES_CBC force C set [phase1- transform-peer-10.10.20.1-RSA_SIG-SHA-AES128- MODP_1024]:KEY_LENGTH=128,128:256 force C set [phase1-transform-peer- 10.10.20.1-RSA_SIG-SHA-AES128- MODP_1024]:GROUP_DESCRIPTION=MODP_1024 force C set [phase1- transform-peer-10.10.20.1-RSA_SIG-SHA-AES128- MODP_1024]:Life=LIFE_MAIN_MODE force C set [from-10.10.10.1-to- 192.168.2.0/24]:Phase=2 force C set [from-10.10.10.1-to- 192.168.2.0/24]:ISAKMP-peer=peer-10.10.20.1 force C set [from-10.10.10.1- to-192.168.2.0/24]:Configuration=phase2-from-10.10.10.1-to-192.168.2.0/24 force C set [from-10.10.10.1-to-192.168.2.0/24]:Local-ID=from-10.10.10.1 force C set [from-10.10.10.1-to-192.168.2.0/24]:NAT-ID=nat-192.168.1.0/24 force C set [from-10.10.10.1-to-192.168.2.0/24]:Remote-ID=to-192.168.2.0/24 force C set [phase2-from-10.10.10.1-to- 192.168.2.0/24]:EXCHANGE_TYPE=QUICK_MODE force C set [phase2-from- 10.10.10.1-to-192.168.2.0/24]:Suites=phase2-suite-from-10.10.10.1-to- 192.168.2.0/24 force C set [phase2-suite-from-10.10.10.1-to- 192.168.2.0/24]:Protocols=phase2-protocol-from-10.10.10.1-to- 192.168.2.0/24 force C set [phase2-protocol-from-10.10.10.1-to- 192.168.2.0/24]:PROTOCOL_ID=IPSEC_ESP force C set [phase2-protocol- from-10.10.10.1-to-192.168.2.0/24]:Transforms=phase2-transform-from- 10.10.10.1-to-192.168.2.0/24-AES128-SHA2_256-MODP_1024-TUNNEL force C set [phase2-transform-from-10.10.10.1-to-192.168.2.0/24-AES128-SHA2_256- MODP_1024-TUNNEL]:TRANSFORM_ID=AES force C set [phase2-transform- from-10.10.10.1-to-192.168.2.0/24-AES128-SHA2_256-MODP_1024- TUNNEL]:KEY_LENGTH=128,128:256 force C set [phase2-transform-from- 10.10.10.1-to-192.168.2.0/24-AES128-SHA2_256-MODP_1024- TUNNEL]:ENCAPSULATION_MODE=TUNNEL force C set [phase2-transform- from-10.10.10.1-to-192.168.2.0/24-AES128-SHA2_256-MODP_1024- TUNNEL]:AUTHENTICATION_ALGORITHM=HMAC_SHA2_256 force C set [phase2-transform-from-10.10.10.1-to-192.168.2.0/24-AES128-SHA2_256- MODP_1024-TUNNEL]:GROUP_DESCRIPTION=MODP_1024 force C set [phase2-transform-from-10.10.10.1-to-192.168.2.0/24-AES128-SHA2_256- MODP_1024-TUNNEL]:Life=LIFE_QUICK_MODE force C set [from- 10.10.10.1]:ID-type=IPV4_ADDR force C set [from- 10.10.10.1]:Address=10.10.10.1 force C set [nat-192.168.1.0/24]:ID- type=IPV4_ADDR_SUBNET force C set [nat- 192.168.1.0/24]:Network=192.168.1.0 force C set [nat- 192.168.1.0/24]:Netmask=255.255.255.0 force C set [to-192.168.2.0/24]:ID- type=IPV4_ADDR_SUBNET force C set [to- 192.168.2.0/24]:Network=192.168.2.0 force C set [to- 192.168.2.0/24]:Netmask=255.255.255.0 force C add [Phase 2]:Connections=from-10.10.10.1-to-192.168.2.0/24 -- Christian naddy Weisgerber na...@mips.inka.de
Re: Help with ISAKMP Nat Traversal Problem needed
There seems to be no interest in this issue on @misc. Would it be ok to file a bug for this? -Ursprüngliche Nachricht- Von: Christoph Leser Gesendet: Montag, 9. September 2013 16:45 An: Christoph Leser; misc@openbsd.org Betreff: AW: Help with ISAKMP Nat Traversal Problem needed Here is another debug output and tcpdump for the same problem. Following the advice from Stuart Henderson I change the debug levels to isakmpd -D0=29 -D1=49 -D2=10 -D3=30 -D6=99 -D7=99 -D8=99 -D9=30 -D10=20 -K -L Here again the tcpdump and the new debug output 16:08:35.114550 0.0.0.0.500 217.86.184.8.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef- msgid: len: 184 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 = AES_CBC attribute HASH_ALGORITHM = MD5 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute KEY_LENGTH = 128 payload: VENDOR len: 20 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 212) 16:08:35.184157 217.86.184.8.500 217.110.66.79.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef-be3ad6b901947e8e msgid: len: 116 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 = AES_CBC attribute KEY_LENGTH = 128 attribute HASH_ALGORITHM = MD5 attribute GROUP_DESCRIPTION = MODP_1024 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 12 payload: VENDOR len: 20 (supports NAT-T, RFC 3947) [ttl 0] (id 1, len 144) 16:08:35.275577 217.110.66.79.500 217.86.184.8.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef-be3ad6b901947e8e msgid: len: 220 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D len: 20 payload: NAT-D len: 20 [ttl 0] (id 1, len 248) 16:08:35.363848 217.86.184.8.500 217.110.66.79.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef-be3ad6b901947e8e msgid: len: 268 payload: KEY_EXCH len: 132 payload: NAT-D len: 20 payload: NAT-D len: 20 payload: NONCE len: 24 payload: VENDOR len: 12 payload: VENDOR len: 12 (supports draft-ietf-ipsra-isakmp-xauth- 06.txt) payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 296) 16:08:35.454563 217.110.66.79.4500 217.86.184.8.4500: [bad udp cksum c9d0!] udpencap: isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef-be3ad6b901947e8e msgid: len: 88 payload: ID len: 12 type: IPV4_ADDR = 217.110.66.79 payload: HASH len: 20 payload: NOTIFICATION len: 28 notification: INITIAL CONTACT (1a0208d771df46ef- be3ad6b901947e8e) [ttl 0] (id 1, len 120) 16:08:35.523331 217.86.184.8.4500 217.110.66.79.4500: [bad udp cksum 1c00!] udpencap: isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef-be3ad6b901947e8e msgid: len: 60 payload: ID len: 12 type: IPV4_ADDR = 192.168.50.253 payload: HASH len: 20 [ttl 0] (id 1, len 92) 16:08:35.615285 217.110.66.79.4500 217.86.184.8.4500: [udp sum ok] udpencap: isakmp v1.0 exchange QUICK_MODE cookie: 1a0208d771df46ef-be3ad6b901947e8e msgid: ceee06b6 len: 288 payload: HASH len: 20 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x4dc1e13b payload: TRANSFORM len: 32 transform: 1 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 1200 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_MD5 attribute GROUP_DESCRIPTION = 2 attribute KEY_LENGTH = 128 payload
Help with ISAKMP Nat Traversal Problem needed
- function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc8000/0xa800 cpu0 at mainbus0: (uniprocessor) amdmsr0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) 0:20:0: io address conflict 0x6100/0x100 0:20:0: io address conflict 0x6200/0x200 pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x31 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:00:24:c9:59:24 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address 00:00:24:c9:59:25 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9, address 00:00:24:c9:59:26 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:00:24:c9:59:27 ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 glxpcib0 at pci0 dev 20 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c gpio0 at glxpcib0: 32 pins iic0 at glxpcib0 pciide0 at pci0 dev 20 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: SanDisk SDCFH2-004G wd0: 4-sector PIO, LBA, 3919MB, 8027712 sectors wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 21 function 0 AMD CS5536 USB rev 0x02: irq 15, version 1.0, legacy support ehci0 at pci0 dev 21 function 1 AMD CS5536 USB rev 0x02: irq 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 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 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pcppi0 at isa0 port 0x61 spkr0 at pcppi0 nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 10: GPIO VLM TMS gpio1 at nsclpcsio0: 29 pins npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 mtrr: K6-family MTRR support (2 registers) vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (5acd6c91162ffb03.a) swap on wd0b dump on wd0b Please also note the message in the debug output: Sep 9 10:36:51 q-dsl isakmpd[8122]: nat_t_exchange_check_nat_d: NAT detected, we're behind it Which seems either wrong or at least misleading: we are directly connect to the internet, it is the other side that is behind a NAT. What also strikes me is that the 'Next Proposal' fields at byte offset 005c and 0068 are zero instead of 02 (PROPOSAL) and 03 (TRANSFORM) as the figure ant page of rfc 2408 suggests. Please let me know how you read this matter. Thanks Christoph Leser
Re: Help with ISAKMP Nat Traversal Problem needed
: finalizing exchange 0x848b5200 with arg 0x7ee80e40 (from-129.143.250.128/25-to-192.168.199.0/24) fail = 0 Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_lookup_by_name: from-129.143.250.128/25-to-192.168.199.0/24 == peer-217.86.184.8 2 == 1? Sep 9 16:08:35 q-dsl isakmpd[13061]: sa_find: return SA 0x848b5a00 Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_establish_p2: 0x848b5800 from-129.143.250.128/25-to-192.168.199.0/24 phase2-from-129.143.250.128/25-to-192.168.199.0/24 policy initiator phase 2 doi 1 exchange 32 step 0 Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_establish_p2: icookie 1a0208d771df46ef rcookie be3ad6b901947e8e Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_establish_p2: msgid ceee06b6 sa_list Sep 9 16:08:35 q-dsl isakmpd[13061]: sa_reference: SA 0x848b5400 now has 1 references Sep 9 16:08:35 q-dsl isakmpd[13061]: sa_enter: SA 0x848b5400 added to SA list Sep 9 16:08:35 q-dsl isakmpd[13061]: sa_reference: SA 0x848b5400 now has 2 references Sep 9 16:08:35 q-dsl isakmpd[13061]: sa_create: sa 0x848b5400 phase 2 added to exchange 0x848b5800 (from-129.143.250.128/25-to-192.168.199.0/24) Sep 9 16:08:35 q-dsl isakmpd[13061]: sa_reference: SA 0x848b5a00 now has 6 references Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_nonce: NONCE_i: Sep 9 16:08:35 q-dsl isakmpd[13061]: c12733f7 6971d438 46759740 a12b2918 Sep 9 16:08:35 q-dsl isakmpd[13061]: initiator_send_HASH_SA_NONCE: IDic: Sep 9 16:08:35 q-dsl isakmpd[13061]: c01d1b82 0400 818ffa80 ff80 Sep 9 16:08:35 q-dsl isakmpd[13061]: initiator_send_HASH_SA_NONCE: IDrc: Sep 9 16:08:35 q-dsl isakmpd[13061]: 0100 0400 c0a8c700 ff00 Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_validate: checking for required HASH Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_validate: checking for required SA Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_validate: checking for required NONCE Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_run: exchange 0x848b5800 finished step 0, advancing... Sep 9 16:08:35 q-dsl isakmpd[13061]: sa_find: no SA matched query Sep 9 16:08:35 q-dsl isakmpd[13061]: sa_release: SA 0x848b5a00 had 6 references Sep 9 16:08:35 q-dsl isakmpd[13061]: exchange_free_aux: freeing exchange 0x848b5200 Sep 9 16:08:35 q-dsl isakmpd[13061]: sa_release: SA 0x848b5a00 had 5 references Sep 9 16:08:35 q-dsl isakmpd[13061]: virtual_send_message: enabling NAT-T encapsulation for this exchange Sep 9 16:08:35 q-dsl isakmpd[13061]: transport_send_messages: message 0x848b3500 scheduled for retransmission 1 in 7 secs Sep 9 16:08:42 q-dsl isakmpd[13061]: transport_send_messages: message 0x848b3500 scheduled for retransmission 2 in 9 secs Sep 9 16:08:42 q-dsl isakmpd[13061]: sa_reference: SA 0x848b5a00 now has 5 references Sep 9 16:08:42 q-dsl isakmpd[13061]: message_recv: phase 1 message after ISAKMP SA is ready Sep 9 16:08:42 q-dsl isakmpd[13061]: sa_release: SA 0x848b5a00 had 5 references Sep 9 16:08:51 q-dsl isakmpd[13061]: transport_send_messages: message 0x848b3500 scheduled for retransmission 3 in 11 secs Sep 9 16:08:51 q-dsl isakmpd[13061]: sa_reference: SA 0x848b5a00 now has 5 references Sep 9 16:08:51 q-dsl isakmpd[13061]: message_recv: phase 1 message after ISAKMP SA is ready Sep 9 16:08:51 q-dsl isakmpd[13061]: sa_release: SA 0x848b5a00 had 5 references Sep 9 16:09:02 q-dsl isakmpd[13061]: transport_send_messages: giving up on exchange from-129.143.250.128/25-to-192.168.199.0/24, no response from peer 217.86.184.8:4500 Sep 9 16:09:02 q-dsl isakmpd[13061]: sa_release: SA 0x848b5a00 had 4 references Sep 9 16:09:02 q-dsl isakmpd[13061]: sa_reference: SA 0x848b5a00 now has 4 references Sep 9 16:09:02 q-dsl isakmpd[13061]: message_recv: phase 1 message after ISAKMP SA is ready Sep 9 16:09:02 q-dsl isakmpd[13061]: sa_release: SA 0x848b5a00 had 4 references Sep 9 16:09:35 q-dsl isakmpd[13061]: sa_find: no SA matched query Sep 9 16:09:35 q-dsl isakmpd[13061]: exchange_lookup_by_name: from-129.143.250.128/25-to-192.168.199.0/24 == from-129.143.250.128/25-to-192.168.199.0/24 2 == 2? Sep 9 16:09:35 q-dsl isakmpd[13061]: exchange_establish: from-129.143.250.128/25-to-192.168.199.0/24 exchange already exists as 0x848b5800 Sep 9 16:09:39 q-dsl isakmpd[13061]: ui_shutdown_daemon: received shutdown command Sep 9 16:09:39 q-dsl isakmpd[13061]: isakmpd: shutting down... -Ursprüngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Christoph Leser Gesendet: Montag, 9. September 2013 12:13 An: misc@openbsd.org Betreff: Help with ISAKMP Nat Traversal Problem needed Hello misc, My openBSD Gateway seems to have a problem with ISAKMP Nat Traversal to a remote Sonicwall. The ISAKMP Exchange fails in pase 2. The remote Sonicwall is behind a NAT device. Before I blame one side or the other for misbehavior, I would like you to take a look at the traces I will provide here and help me with the proper interpretation
Re: ISAKMPD NAT/Traversal
Von: owner-m...@openbsd.org [owner-m...@openbsd.org]quot; im Auftrag von quot;Stuart Henderson [s...@spacehopper.org] Gesendet: Samstag, 7. September 2013 00:11 An: misc@openbsd.org Betreff: Re: ISAKMPD NAT/Traversal On 2013-09-06, Christoph Leser le...@sup-logistik.de wrote: Hello, list, from a remark by Stuart Henderson on an older thread http://marc.info/?l=openbsd-miscm=134849 788026722w=2 back in September 2012,I understood that NAT-T support in openBSD was not complete at that time, especially the handling of the 'ENCAPSULATION_MODE' attribute in the phase 2 'TRANSFORM'. Sometimes this gets set to a value incompatible with other equipment ( cisco ). Can someone please point me to where I can find more information on this matter. Has anything changed in openBSD with regard to this, will openBSD follow RFC3947 with regard to the encapsulation modes ( or is RFC3947 deas, it seems to be a standard proposal since 2005 ). Mit freundlichen Gr��en Christoph Leser SP Computersysteme GmbH Zettachring 4 70567 Stuttgart Fasanenhof EMail: le...@sup-logistik.de You misunderstand. OpenBSD uses the proper assigned encapsulation mode values from the newer internet-drafts and the published RFC: http://tools.ietf.org/html/draft-ietf-ipsec-nat-t-ike-04#section-5.1 http://tools.ietf.org/html/rfc3947#section-5.1 It is Cisco who use the old encapsulation mode values from the early versions of the internet-draft (marked XXX CHANGE here): http://tools.ietf.org/html/draft-ietf-ipsec-nat-t-ike-03#section-5.1 thanks for the clarification. Does that mean that openBSD sends UDP-Encapsulated-Tunnel (=3) mode when it detects NAT? But the isakmpd.pcap still shows attribute ENCAPSULATION_MODE = TUNNEL in the TRANSFORM payload? I ask because I have problems with a SonicWall behind a Nat on the remote site, which claims that my openBSD TUNNEL(=1) instead of Encapsulated Tunnel(=3).
ISAKMPD NAT/Traversal
Hello, list, from a remark by Stuart Henderson on an older thread http://marc.info/?l=openbsd-miscm=134849 788026722w=2 back in September 2012,I understood that NAT-T support in openBSD was not complete at that time, especially the handling of the 'ENCAPSULATION_MODE' attribute in the phase 2 'TRANSFORM'. Sometimes this gets set to a value incompatible with other equipment ( cisco ). Can someone please point me to where I can find more information on this matter. Has anything changed in openBSD with regard to this, will openBSD follow RFC3947 with regard to the encapsulation modes ( or is RFC3947 deas, it seems to be a standard proposal since 2005 ). Mit freundlichen Grüßen Christoph Leser SP Computersysteme GmbH Zettachring 4 70567 Stuttgart Fasanenhof EMail: le...@sup-logistik.de
Re: ../../../../arch/i386/i386/locore.s:1755: Error: no such instruction: `stac'
Thanks for the clarification. I now understand that I have got things messed up. I have been on -current ( as of 25. Sep ) , at least I strongly believe this but cannot prove because I have overwritten the system in the meantime. Then I run into problems rebuilding the kernel after a cvs update. I figured that I should update the binaries and pick the wrong ones, as you have pointed out. I fixed that and now all is fine again. Thanks Christoph PS: I should work on my googling abilities. I search for locore.s and thus missed the message you referred to. -Ursprüngliche Nachricht- Von: Philip Guenther [mailto:guent...@gmail.com] Gesendet: Montag, 26. November 2012 21:44 An: Christoph Leser Cc: 'misc@openbsd.org' (misc@openbsd.org) Betreff: Re: ../../../../arch/i386/i386/locore.s:1755: Error: no such instruction: `stac' On Mon, Nov 26, 2012 at 10:42 AM, Christoph Leser le...@sup-logistik.de wrote: I'm trying to build the kernel for -current I updated the binaries first, then updated the source tree and then did ... ../../../../arch/i386/i386/locore.s:1755: Error: no such instruction: `stac' ../../../../arch/i386/i386/locore.s:1759: Error: no such instruction: `clac' *** Error code 1 This question was asked and answered 3 weeks ago: http://comments.gmane.org/gmane.os.openbsd.misc/200525 Alternatively, you're thinking about -stable when you say -current. Note the start of your dmesg: OpenBSD 5.2 (GENERIC) #278: Wed Aug 1 10:04:16 MDT 2012 That sure looks like *stable* and not *current*. Indeed, the -current i386 snapshot right now says: OpenBSD 5.2-current (GENERIC) #89: Mon Nov 19 12:49:11 MST 2012 If you want -stable, you'll need to change your cvs checkout to the branch instead of the trunk. Philip Guenther
../../../../arch/i386/i386/locore.s:1755: Error: no such instruction: `stac'
I'm trying to build the kernel for -current I updated the binaries first, then updated the source tree and then did cd /usr/src/sys/arch/i386/conf config GENERIC cd ../compile/GENERIC make clean make This fails while processing locoer.s with these messages: ../../../../arch/i386/i386/locore.s: Assembler messages: ../../../../arch/i386/i386/locore.s:1755: Error: no such instruction: `stac' ../../../../arch/i386/i386/locore.s:1759: Error: no such instruction: `clac' *** Error code 1 Stop in /usr/src/sys/arch/i386/compile/GENERIC (line 165 of /usr/share/mk/sys.mk). The cvs status of locore.s is 'Up to date', Revision 1.145 I followed the same procedure some weeks ago ( Sep. 25. ) and had no problems. dmesg.boot is included at the end of this message. Best Regards / Mit freundlichen Grüßen Christoph Leser Dmesg.boot: OpenBSD 5.2 (GENERIC) #278: Wed Aug 1 10:04:16 MDT 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (GenuineIntel 686-class) 2.40 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,MWAIT,SSSE3,LAHF real mem = 66580480 (63MB) avail mem = 54677504 (52MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @ 0xfbff0, SMBIOS rev. 2.5 @ 0xe1000 (5 entries) bios0: vendor innotek GmbH version VirtualBox date 12/01/2006 bios0: innotek GmbH VirtualBox acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpiprt0 at acpi0: bus 0 (PCI0) acpibat0 at acpi0: BAT0 model 1 serial 0 type VBOX oem innotek acpiac0 at acpi0: AC unit online bios0: ROM list: 0xc/0x9000 0xe2000/0x1000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02 pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00 pciide0 at pci0 dev 1 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: VBOX HARDDISK wd0: 128-sector PIO, LBA, 8192MB, 16777216 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: VBOX, CD-ROM, 1.0 ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 vga1 at pci0 dev 2 function 0 InnoTek VirtualBox Graphics Adapter rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) em0 at pci0 dev 3 function 0 Intel PRO/1000MT (82540EM) rev 0x02: irq 10, address 08:00:27:21:61:44 InnoTek VirtualBox Guest Service rev 0x00 at pci0 dev 4 function 0 not configured auich0 at pci0 dev 5 function 0 Intel 82801AA AC97 rev 0x01: irq 5, ICH AC97 ac97: codec id 0x83847600 (SigmaTel STAC9700) audio0 at auich0 ohci0 at pci0 dev 6 function 0 Apple Intrepid USB rev 0x00: irq 11, version 1.0 piixpm0 at pci0 dev 7 function 0 Intel 82371AB Power rev 0x08: SMBus disabled ehci0 at pci0 dev 11 function 0 Intel 82801FB USB rev 0x00: irq 10 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 Apple OHCI root hub rev 1.00/1.00 addr 1 mtrr: CPU supports MTRRs but not enabled vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on wd0a (57f9ce7f23a8b57c.a) swap on wd0b dump on wd0b
Re: OpenBSD does not initiate ipsec connection
Do a ping -I as Janne advised and take a on the enc0 device and on your
external interface ( both with ip host a.b.102.219 parameter ).
You should
see the icmp packet on enc0 and some esp paket at the same time on the
external interface.
If one or both are missing, you may have a problem with
your pf.conf. If you see both, I would believe your tunnel is ok and the
remote side is filtering your icmp or does not route your packet properly into
the (remote) internal net.
Christoph Leser
SP Computersysteme GmbH
Zettachring 4
70567 Stuttgart Fasanenhof
EMail: le...@sup-logistik.de
Von: owner-m...@openbsd.org
[owner-m...@openbsd.org]quot; im Auftrag von quot;Janne Johansson
[icepic...@gmail.com]
Gesendet: Dienstag, 2. Oktober 2012 11:01
An: Erwin
Schliske
Cc: misc@openbsd.org
Betreff: Re: OpenBSD does not initiate ipsec
connection
2012/10/1 Erwin Schliske erwin.schli...@sevenval.com:
Hello,
I've set up an OpenBSD box as vpn gateway. The tunnel I have to establish is
with a Cisco ASA 5505, which is not under my administration.
Here is the
ipsec.conf
ike esp from { 172.30.77.0/24, 10.70.0.0/24, 10.83.0.0/24,
10.77.4.0/24 } to {
172.16.70.0/24, 172.16.71.0/24, 172.16.72.0/24 } \
peer a.b.102.219 \
local c.d.3.254 \
main auth hmac-sha1 enc 3des group
modp1024 \
quick auth hmac-sha1 enc 3des group none \
psk password
If I try to ping one host on cisco side from OpenBSD side the tunnel doesn't
come up. If I look with tcpdump on the external interface or in the tcpdump
logging of isakmpd OpenBSD doesn't try to establish the tunnel. If I ping from
the Cisco side an host on OpenBSD side the tunnel comes up. In the logging
of
isakmpd I see this loglines
from the X side, does that mean you try to
ping from the openbsd,
OR, from one of the networks listed in the from-line?
One of the common mistakes is to test from the ipsec-gw itself and not
accounting for the fact that the ipsec.conf lines mostly are
to talk from net
A to net B, host X will do ipsec to peer Y. In such
a case, testing from host
X will not go through the tunnel, since the
rule is from net A.
Most of the
time the host X has a leg on net A and can ping -I
my-ip-at-NetA
dest-on-net-B but not always.
Then again, since active esp is the default
for ipsec.conf when you
write ike esp ..., it should start trying to set the
tunnel up as
soon as you load the rules, and not wait until packets want to
traverse it.
--
To our sweethearts and wives. May they never meet. -- 19th
century toast
Re: OpenBSD does not initiate ipsec connection
Please forget about my last response. I didn't read the original message
properly.
The original post states clearly that the VPN tunnel works, when it
is initiated from the remote side, but does not get initiated from the obsd
side when needed ( by a ping packet for instance ).
This somehow suggests
that obsd initiates tunnels on demand ( when a packet for a remote network
arrives ). I do not believe that this is how obsd works, but perhaps those who
know can tell as for sure.
As for why obsd does not try to initiate the
tunnel actively, as suggested by the isakmpd.pcap: What did the debug output
in messages shows for this?
Best Regards / Mit freundlichen Grüßen
Christoph Leser
SP Computersysteme GmbH
Zettachring 4
70567 Stuttgart
Fasanenhof
EMail: le...@sup-logistik.de
Von: Christoph Leser
Gesendet:
Dienstag, 2. Oktober 2012 14:50
An: Janne Johansson; Erwin Schliske
Cc:
misc@openbsd.org
Betreff: AW: OpenBSD does not initiate ipsec connection
Do a
ping -I as Janne advised and take a on the enc0 device and on your external
interface ( both with ip host a.b.102.219 parameter ).
You should see the
icmp packet on enc0 and some esp paket at the same time on the external
interface.
If one or both are missing, you may have a problem with your
pf.conf. If you see both, I would believe your tunnel is ok and the remote
side is filtering your icmp or does not route your packet properly into the
(remote) internal net.
Christoph Leser
SP Computersysteme GmbH
Zettachring 4
70567 Stuttgart Fasanenhof
EMail: le...@sup-logistik.de
Von: owner-m...@openbsd.org
[owner-m...@openbsd.org]quot; im Auftrag von quot;Janne Johansson
[icepic...@gmail.com]
Gesendet: Dienstag, 2. Oktober 2012 11:01
An: Erwin
Schliske
Cc: misc@openbsd.org
Betreff: Re: OpenBSD does not initiate ipsec
connection
2012/10/1 Erwin Schliske erwin.schli...@sevenval.com:
Hello,
I've set up an OpenBSD box as vpn gateway. The tunnel I have to establish is
with a Cisco ASA 5505, which is not under my administration.
Here is the
ipsec.conf
ike esp from { 172.30.77.0/24, 10.70.0.0/24, 10.83.0.0/24,
10.77.4.0/24 } to {
172.16.70.0/24, 172.16.71.0/24, 172.16.72.0/24 } \
peer a.b.102.219 \
local c.d.3.254 \
main auth hmac-sha1 enc 3des group
modp1024 \
quick auth hmac-sha1 enc 3des group none \
psk password
If I try to ping one host on cisco side from OpenBSD side the tunnel doesn't
come up. If I look with tcpdump on the external interface or in the tcpdump
logging of isakmpd OpenBSD doesn't try to establish the tunnel. If I ping from
the Cisco side an host on OpenBSD side the tunnel comes up. In the logging
of
isakmpd I see this loglines
from the X side, does that mean you try to
ping from the openbsd,
OR, from one of the networks listed in the from-line?
One of the common mistakes is to test from the ipsec-gw itself and not
accounting for the fact that the ipsec.conf lines mostly are
to talk from net
A to net B, host X will do ipsec to peer Y. In such
a case, testing from host
X will not go through the tunnel, since the
rule is from net A.
Most of the
time the host X has a leg on net A and can ping -I
my-ip-at-NetA
dest-on-net-B but not always.
Then again, since active esp is the default
for ipsec.conf when you
write ike esp ..., it should start trying to set the
tunnel up as
soon as you load the rules, and not wait until packets want to
traverse it.
--
To our sweethearts and wives. May they never meet. -- 19th
century toast
Re: Router project on OpenBSD questions
Thank you for asking. I refreshed my system to -current as of 24. Sep 2012, so I now have sbin/ipsecctl/ike.c 1.77 Following the suggestion of Stuard Henderson I start isakmpd as isakmpd -K -T Now I get the same behaviour as I have with OpenBSD 4.6. All configured VPNs get connected. So thanks for your help. I still have some problems with some of the VPNs, i.e. some fail to renegotiate after a while but I do not have the details yet for a decent problem report. Regards Christoph -Ursprüngliche Nachricht- Von: Otto Moerbeek [mailto:o...@drijf.net] Gesendet: Freitag, 28. September 2012 13:45 An: misc@openbsd.org Cc: Christoph Leser Betreff: Re: Router project on OpenBSD questions On Tue, Sep 25, 2012 at 05:51:42PM +0100, Stuart Henderson wrote: On 2012/09/25 18:24, Otto Moerbeek wrote: On Tue, Sep 25, 2012 at 11:11:19AM +, Stuart Henderson wrote: On 2012-09-25, Christoph Leser le...@sup-logistik.de wrote: Thank you for this hint. I indeed have ike.c r=1.76. So why did you say you were running 5.2? The art of problem reporting is much underappreciated, sadly. -Otto Quite. I even considered this as a possible problem, then saw that it was 5.2, so discounted it... So any news on this? -Otto
Re: Router project on OpenBSD questions
Thank you for this hint. I indeed have ike.c r=1.76. I will refresh my system tonight, give it a try and report my result. Best Regards Christoph -Ursprüngliche Nachricht- Von: Otto Moerbeek [mailto:o...@drijf.net] Gesendet: Montag, 24. September 2012 22:03 An: Christoph Leser Cc: Stuart Henderson; misc@openbsd.org Betreff: Re: Router project on OpenBSD questions On Mon, Sep 24, 2012 at 06:57:26PM +, Christoph Leser wrote: Thanks for clarification. I disabled NAT-T with isakmpd -K -T. A few of my VPNs came to life with this setting, but were instable ( rapid renegotiation ). Still only about one third of my vpns (that worked with OpenBSD 4.6 ) work with OpenBSD 5.2. Many negotiations get rejected by OpenBSD with 'NO PROPOSAL CHOSEN', or 'PAYLOAD MALFORMED' or 'INVALID ID' For some of those I see messages in /var/log/messages like : Sep 24 20:00:09 q-dsl isakmpd[3828]: attribute_unacceptable: attr ENCRYPTION_ALGORITHM does not exist in phase1-transform-peer-a.b.c.d-PRE_SHARED-MD5-AES128 ( for a VPN peer which is configured with MD5-AES-128 in ipsec.conf and which, according to tcpdump, tries to negotiate exactly MD5 and AES-128 ). No idea what this means. Are you running an ipsecctl from about a week ago? For two days or so there was a bug in it. This bug was fixed by this commit: http://www.openbsd.org/cgi- bin/cvsweb/src/sbin/ipsecctl/ike.c.diff?r1=1.76;r2=1.77;only_with_tag=MAI N -Otto Regards -Urspr??ngliche Nachricht- Von: Stuart Henderson [mailto:s...@spacehopper.org] Gesendet: Montag, 24. September 2012 16:41 An: Christoph Leser Cc: misc@openbsd.org Betreff: Re: Router project on OpenBSD questions On 2012/09/24 13:24, Christoph Leser wrote: It seems that the patch from Stuart Henderson, proposed on Aug.4 2012 on tech@ has not made it into ???current yet. I only forwarded it, the patch is from hshoexer. Also it is only a partial diff, not suitable to be committed, the encap mode value needs to be controllable per-peer so it needs a config option, changes to ipsecctl, etc. This problem certainly would have affected older OpenBSD versions though, if they negotiated NAT-T they would have used the value from the RFC not the one from the internet-draft that cisco use. Have you tried just disabling nat-t completely, see the options list in isakmpd(8), to see what happens?
Re: Router project on OpenBSD questions
Thanks for the replies. You say, there have been problems with NAT-T but these have been fixed. I am on openBSD 5.2 current and have problems with NAT-T to cisco, which I have not had when I was on openBSD 4.7. The problem is, as seen in the debug output from isakmpd, that isakmpd detects that there is a NAT device in between ( it even tells that âwe are behind itâ ) and then proposes âENCAPULATION_MODE=TUNNELâ instead of âENCAPLULATION_MODE=UDP_ENC_TUNNELâ for phase two, which is ( correctly ? ) rejected by the remote peer. Regards Christoph Von: Stuart Henderson [mailto:s...@spacehopper.org] Gesendet: Samstag, 22. September 2012 16:52 An: Christoph Leser; misc@openbsd.org Betreff: Re: Router project on OpenBSD questions Search the archives for the cisco nat-t problem, I sent a mail with more details and I think there was a patch with it. Pretty sure that would have affected older OpenBSD versions too though. Christoph Leser le...@sup-logistik.demailto:le...@sup-logistik.de wrote: On Feb 28, 2012, Stuart Henderson wrote: List: openbsd-mischttp://marc.info/?l=openbsd-miscr=1w=2 Subject:Re: Router project on OpenBSD questionshttp://marc.info/?t=13303717306r=1w=2 From: Stuart Henderson stu () spacehopper ! orghttp://marc.info/?a=10397134052r=1w=2 Date: 2012-02-28 13:57:45http://marc.info/?l=openbsd-miscr=1w=2b=201202 Message-ID: slrnjkpnao.r14.stu () naiad ! spacehopper ! orghttp://marc.info/?i=slrnjkpnao.r14.stu%20()%20naiad%20!%20spacehopper%20!%20org [Download message RAWhttp://marc.info/?l=openbsd-miscm=133043766530365q=raw] IPsec is mostly compatible but there's a bit of breakage if the ipsec gateways are behind NAT (because Cisco still follows a very old nat-t draft rather than the standard). I think I have read similar remarks about NAT-T and Cisco interoperability. But I have found no details about what the problem is with cisco. I completely failed when I tried to move from OBSD 4.6 to OBSD 5.2, because of NAT-T trouble with cisco. I described my experience in a message to this list 'ISAMPD NAT trouble with openBSD 5.2 Any hints to information about interoperabilty issues with cisco ( and possible solutions ) would be highly welcome Mit freundlichen GrüÃen Christoph Leser SP Computersysteme GmbH Zettachring 4 70567 Stuttgart Fasanenhof EMail: le...@sup-logistik.demailto:le...@sup-logistik.de
Re: Router project on OpenBSD questions
It seems that the patch from Stuart Henderson, proposed on Aug.4 2012 on tech@ has not made it into âcurrent yet. Von: Stuart Henderson [mailto:s...@spacehopper.org] Gesendet: Samstag, 22. September 2012 16:52 An: Christoph Leser; misc@openbsd.org Betreff: Re: Router project on OpenBSD questions Search the archives for the cisco nat-t problem, I sent a mail with more details and I think there was a patch with it. Pretty sure that would have affected older OpenBSD versions too though. Christoph Leser le...@sup-logistik.demailto:le...@sup-logistik.de wrote: On Feb 28, 2012, Stuart Henderson wrote: List: openbsd-mischttp://marc.info/?l=openbsd-miscr=1w=2 Subject:Re: Router project on OpenBSD questionshttp://marc.info/?t=13303717306r=1w=2 From: Stuart Henderson stu () spacehopper ! orghttp://marc.info/?a=10397134052r=1w=2 Date: 2012-02-28 13:57:45http://marc.info/?l=openbsd-miscr=1w=2b=201202 Message-ID: slrnjkpnao.r14.stu () naiad ! spacehopper ! orghttp://marc.info/?i=slrnjkpnao.r14.stu%20()%20naiad%20!%20spacehopper%20!%20org [Download message RAWhttp://marc.info/?l=openbsd-miscm=133043766530365q=raw] IPsec is mostly compatible but there's a bit of breakage if the ipsec gateways are behind NAT (because Cisco still follows a very old nat-t draft rather than the standard). I think I have read similar remarks about NAT-T and Cisco interoperability. But I have found no details about what the problem is with cisco. I completely failed when I tried to move from OBSD 4.6 to OBSD 5.2, because of NAT-T trouble with cisco. I described my experience in a message to this list 'ISAMPD NAT trouble with openBSD 5.2 Any hints to information about interoperabilty issues with cisco ( and possible solutions ) would be highly welcome Mit freundlichen GrüÃen Christoph Leser SP Computersysteme GmbH Zettachring 4 70567 Stuttgart Fasanenhof EMail: le...@sup-logistik.demailto:le...@sup-logistik.de
Re: Router project on OpenBSD questions
Thanks for clarification. I disabled NAT-T with isakmpd -K -T. A few of my VPNs came to life with this setting, but were instable ( rapid renegotiation ). Still only about one third of my vpns (that worked with OpenBSD 4.6 ) work with OpenBSD 5.2. Many negotiations get rejected by OpenBSD with 'NO PROPOSAL CHOSEN', or 'PAYLOAD MALFORMED' or 'INVALID ID' For some of those I see messages in /var/log/messages like : Sep 24 20:00:09 q-dsl isakmpd[3828]: attribute_unacceptable: attr ENCRYPTION_ALGORITHM does not exist in phase1-transform-peer-a.b.c.d-PRE_SHARED-MD5-AES128 ( for a VPN peer which is configured with MD5-AES-128 in ipsec.conf and which, according to tcpdump, tries to negotiate exactly MD5 and AES-128 ). No idea what this means. Regards -Ursprüngliche Nachricht- Von: Stuart Henderson [mailto:s...@spacehopper.org] Gesendet: Montag, 24. September 2012 16:41 An: Christoph Leser Cc: misc@openbsd.org Betreff: Re: Router project on OpenBSD questions On 2012/09/24 13:24, Christoph Leser wrote: It seems that the patch from Stuart Henderson, proposed on Aug.4 2012 on tech@ has not made it into –current yet. I only forwarded it, the patch is from hshoexer. Also it is only a partial diff, not suitable to be committed, the encap mode value needs to be controllable per-peer so it needs a config option, changes to ipsecctl, etc. This problem certainly would have affected older OpenBSD versions though, if they negotiated NAT-T they would have used the value from the RFC not the one from the internet-draft that cisco use. Have you tried just disabling nat-t completely, see the options list in isakmpd(8), to see what happens?
Re: Router project on OpenBSD questions
On Feb 28, 2012, Stuart Henderson wrote: List: openbsd-mischttp://marc.info/?l=openbsd-miscr=1w=2 Subject:Re: Router project on OpenBSD questionshttp://marc.info/?t=13303717306r=1w=2 From: Stuart Henderson stu () spacehopper ! orghttp://marc.info/?a=10397134052r=1w=2 Date: 2012-02-28 13:57:45http://marc.info/?l=openbsd-miscr=1w=2b=201202 Message-ID: slrnjkpnao.r14.stu () naiad ! spacehopper ! orghttp://marc.info/?i=slrnjkpnao.r14.stu%20()%20naiad%20!%20spacehopper%20! %20org [Download message RAWhttp://marc.info/?l=openbsd-miscm=133043766530365q=raw] IPsec is mostly compatible but there's a bit of breakage if the ipsec gateways are behind NAT (because Cisco still follows a very old nat-t draft rather than the standard). I think I have read similar remarks about NAT-T and Cisco interoperability. But I have found no details about what the problem is with cisco. I completely failed when I tried to move from OBSD 4.6 to OBSD 5.2, because of NAT-T trouble with cisco. I described my experience in a message to this list 'ISAMPD NAT trouble with openBSD 5.2 Any hints to information about interoperabilty issues with cisco ( and possible solutions ) would be highly welcome Mit freundlichen Grüßen Christoph Leser SP Computersysteme GmbH Zettachring 4 70567 Stuttgart Fasanenhof EMail: le...@sup-logistik.de
Re: isakmpd lifetime trouble with openBSD 5.2 current
Thank for your reply. Ihave the following lines in isakmpd.conf [General] Default-phase-1-lifetime= 28800,60:108000 Default-phase-2-lifetime= 3600,60:86400 Are those the values you were talking about, or are there other values that should be set? Thanks. -Ursprüngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von mxb Gesendet: Dienstag, 18. September 2012 09:43 An: misc@openbsd.org Betreff: Re: isakmpd lifetime trouble with openBSD 5.2 current Tried to add those values into plain old isakmpd.conf? I run 5.2-current and have those values in isakmpd.conf. Never seen those messages and all works fine. On 09/17/2012 09:30 PM, Christoph Leser wrote: After updating to 5.2 current, I noticed, that incoming phase-1 requests get drop due to ( from /var/log/messages ) Sep 17 21:20:51 q-dsl isakmpd[951]: attribute_unacceptable: life attribute received, none in policy Sep 17 21:20:51 q-dsl isakmpd[951]: attribute_unacceptable: life attribute received, none in policy Sep 17 21:20:51 q-dsl isakmpd[951]: message_negotiate_sa: no compatible proposal found Sep 17 21:20:51 q-dsl isakmpd[951]: dropped message from a.b.c.d port 500 due to notification type NO_PROPOSAL_CHOSEN I tried to add the new lifetime parameters in ipsec.conf, but this did not make any difference. Best Regards / Mit freundlichen Grüßen Christoph Leser SP Computersysteme GmbH Systemhaus für Logistik Zettachring 4 70567 Stuttgart www.sup-logistik.de Tel.: 0711 72641 0 Fax: 0711 72641 70 Amtsgericht Stuttgart HRB 11921 Geschäftsführer Jürgen Probst, Horst Reichert
isakmpd lifetime trouble with openBSD 5.2 current
After updating to 5.2 current, I noticed, that incoming phase-1 requests get drop due to ( from /var/log/messages ) Sep 17 21:20:51 q-dsl isakmpd[951]: attribute_unacceptable: life attribute received, none in policy Sep 17 21:20:51 q-dsl isakmpd[951]: attribute_unacceptable: life attribute received, none in policy Sep 17 21:20:51 q-dsl isakmpd[951]: message_negotiate_sa: no compatible proposal found Sep 17 21:20:51 q-dsl isakmpd[951]: dropped message from a.b.c.d port 500 due to notification type NO_PROPOSAL_CHOSEN I tried to add the new lifetime parameters in ipsec.conf, but this did not make any difference. Best Regards / Mit freundlichen Grüßen Christoph Leser SP Computersysteme GmbH Systemhaus für Logistik Zettachring 4 70567 Stuttgart www.sup-logistik.de Tel.: 0711 72641 0 Fax: 0711 72641 70 Amtsgericht Stuttgart HRB 11921 Geschäftsführer Jürgen Probst, Horst Reichert
Re: isakmpd nat problem with openBSD 5.2
Follow on: I investigated another case: Same as in the previous case, 5.2 switches to port 4500 alfter the NAD-D packets are exchanged and the tries to negotiate ENCAPSULATION MODE = TUNNEL ( tcpdump show, that this QUICK MODE packet is udp encapsulated. This is rejected with NO PROPOSAL CHOSEN. I reactivated the 4.6 version: Here, openBSD 4.6 does NOT switch to port 4500 after the NAT-D exchange. The connect gets established file. This could mean: 1. obsd 5.2 switches to udp encapsulation, as soon as it detects that the peer is able to handle this ( and not because a NAT device is positively detected ). I do not know if this is conformant to the rfcs in question. Anyway it seems, that some peers in this case exec ENCAPSULATION_MODE=UDP_ENCAP_TUNNEL instead of plain TUNNEL. Or 2. obsd 5.2 switches to upd encapsulation as it detects a NAT device where there is no NAT device. ( Some problem as in case 1 with ENCAPSULATION_MODE ) Or 3. obsd 4.6 does not recognise the NAT device and the connection works anyway because the NAT device is ISAKMP aware Could anybody please shed some light on what is the expected behavior? Has anybody seen similar problems? -Ursprüngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Christoph Leser Gesendet: Samstag, 15. September 2012 15:51 An: misc@openbsd.org Betreff: isakmpd nat problem with openBSD 5.2 After I upgraded from openBSD 4.6 to 5.2 I have the following problem with isakmpd+nat when the remote side is behind a NAT gateway: openBSD Phase 1 recognizes NAT and switches to port 4500 to send the ID information. openBSD Phase 2 then tries to negotiate TUNNEL mode, but the remote side rejects this with 'no proposal chosen'. The remote side's log says something like 'expected 'UDP Encapsulated TUNNEL', got 'TUNNEL' I believe that I never saw 'UDP_ENCAP_TUNNEL' in tcpdump of isakmpd.pcap where I was on 4.6. Why did it work with 4.6 and not with 5.2? Best Regards / Mit freundlichen Gr??en Christoph
isakmpd nat problem with openBSD 5.2
After I upgraded from openBSD 4.6 to 5.2 I have the following problem with isakmpd+nat when the remote side is behind a NAT gateway: openBSD Phase 1 recognizes NAT and switches to port 4500 to send the ID information. openBSD Phase 2 then tries to negotiate TUNNEL mode, but the remote side rejects this with 'no proposal chosen'. The remote side's log says something like 'expected 'UDP Encapsulated TUNNEL', got 'TUNNEL' I believe that I never saw 'UDP_ENCAP_TUNNEL' in tcpdump of isakmpd.pcap where I was on 4.6. Why did it work with 4.6 and not with 5.2? Best Regards / Mit freundlichen Grüßen Christoph
IPSEC/ISAKMPD routing question
Hello, I have an IPSEC VPNs in Tunnelmode, configured in ipsec.conf with a line like: ike active esp tunnel from my_internal_net to his_internal_net peer his_gateway_address main_mode_parameters quick_mode_parameters preshared_key My isakmpd.policy file is # cat /etc/isakmpd/isakmpd.policy Keynote-version: 2 Authorizer: POLICY Conditions: app_domain == IPsec policy esp_present == yes esp_enc_alg != null - true; Every thing works fine. But today, one of the remote_gateways was replaced by a misconfigured new one, leading to the following phase-2 packet: 13:29:01.098526 remote_gateway_ip.500 my_gateway_ip.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 70de03ee348066c9-76aabe706bed52c2 msgid: 301c68c8 len: 300 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0xcb2d2b94 payload: TRANSFORM len: 32 transform: 1 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = TUNNEL attribute KEY_LENGTH = 128 attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: NONCE len: 20 payload: KEY_EXCH len: 132 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 [ttl 0] (id 1, len 328) Please note that both ID parameters in this packet are 0.0.0.0. This lead to a routing entry ( made by isakmpd, I suppose ): # netstat -rn | grep his_ip default0 default0 0 remote_gateway_ip/esp/use/in default0 default0 0 remote_gateway_ip/esp/require/out This route virtually disconnected my gateway from the external and from the internal network, no ping to any address was successful. I would like to ask: 1. Is it true, that isakmpd is supposed to accept any ID parameter of type IPV4_ADDR_SUBNET ) in quick mode and set up a corresponing route, even when it is the 'default' route? 2. What would I have to change to only accept those remote network Ids that are configured in ipsec.conf? Thanks
Re: IPSec between OpenBSD and Cisco
Hi, from what I see you use the new address translation feature of ipsec 4.7 This requires a nat statement in pf.conf , which is probably missing from your configuration.. See the section on 'outgoing network address translation' in the man page of ipsec.conf Regards Christoph -Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Fernando Alvarez Gesendet: Donnerstag, 28. Oktober 2010 16:30 An: misc@openbsd.org Betreff: IPSec between OpenBSD and Cisco Hi all, I have been trying to setup a VPN connection between OpenBSD and a Cisco router with no success for more than 2 weeks, and I really need some advice on how to resolve this. Basically, I cannot understand what is going wrong during the negociation :-S Any information would be really helpful for me. The scenario: == OpenBSD 4.7 machine (amd64), fresh install, acting as gateway Public IP: A.A.A.A Private IP: 172.22.1.1/16 Cisco Router (IPSec Server) Public IP: B.B.B.B Private LAN: 10.20.10.0/24 (Ipsec tunnel configured only to access 10.20.10.38 machine) Diagram: == Localization A Localization B 172.22/16 [OpenBSD] A.A.A.A --(Internet)--- B.B.B.B [Cisco] -- 10.20.10.38 (machine) Constraints: == 1 - The OpenBSD machine should present itself as 10.0.22.221 in the Site B LAN. 2 - It's not possible to modify Cisco configuration. It's probed to be fully functional with other Cisco peers (at least that's what they have told to me) Cisco Configuration: == name A.A.A.A siteApublicIP object-group network siteA access-list outside_cryptomap_23 extended permit ip object-group siteA host 10.0.22.221 crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac crypto map outside_map 22 match address outside_cryptomap_23 crypto map outside_map 22 set pfs crypto map outside_map 22 set peer siteApublicIP crypto map outside_map 22 set transform-set ESP-3DES-MD5 tunnel-group A.A.A.A type ipsec-l2l tunnel-group A.A.A.A ipsec-attributes pre-shared-key theKey OpenBSD Config: == /etc/ipsec.conf: == ike active esp from 10.0.22.221 (172.22.0.0/16) to 10.20.10.0/24 \ peer B.B.B.B \ main auth hmac-md5 enc 3des \ quick auth hmac-md5 enc 3des group modp1024 \ psk theKey /etc/pf.conf: == set skip on lo match out log on $ext_if from 172.22/16 to 10.20.10.0/24 nat-to 10.0.22.221 match out log on $int_if from 172.22/16 to !172.22/16 nat-to A.A.A.A pass isakmpd output (via tcpdump): == 0.0.0.0.500 B.B.B.B.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 8f5627d25c664fa7- msgid: len: 180 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = MD5 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports OpenBSD-4.0) 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 208) B.B.B.B.500 A.A.A.A.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 8f5627d25c664fa7-a8427e4dfc02591c msgid: len: 124 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = MD5 attribute GROUP_DESCRIPTION = MODP_1024 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 24 [ttl 0] (id 1, len 152) A.A.A.A.500 B.B.B.B.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 8f5627d25c664fa7-a8427e4dfc02591c msgid: len: 220 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D-DRAFT len: 20 payload:
Re: IPSec between OpenBSD and Cisco
Sorry for the noise. I overlooked your nat statement in pf.conf. But it is wrong, as per man page you shopuld nat on enc0, not on $ext_if Hi, from what I see you use the new address translation feature of ipsec 4.7 This requires a nat statement in pf.conf , which is probably missing from your configuration.. See the section on 'outgoing network address translation' in the man page of ipsec.conf Regards Christoph -Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Fernando Alvarez Gesendet: Donnerstag, 28. Oktober 2010 16:30 An: misc@openbsd.org Betreff: IPSec between OpenBSD and Cisco Hi all, I have been trying to setup a VPN connection between OpenBSD and a Cisco router with no success for more than 2 weeks, and I really need some advice on how to resolve this. Basically, I cannot understand what is going wrong during the negociation :-S Any information would be really helpful for me. The scenario: == OpenBSD 4.7 machine (amd64), fresh install, acting as gateway Public IP: A.A.A.A Private IP: 172.22.1.1/16 Cisco Router (IPSec Server) Public IP: B.B.B.B Private LAN: 10.20.10.0/24 (Ipsec tunnel configured only to access 10.20.10.38 machine) Diagram: == Localization A Localization B 172.22/16 [OpenBSD] A.A.A.A --(Internet)--- B.B.B.B [Cisco] -- 10.20.10.38 (machine) Constraints: == 1 - The OpenBSD machine should present itself as 10.0.22.221 in the Site B LAN. 2 - It's not possible to modify Cisco configuration. It's probed to be fully functional with other Cisco peers (at least that's what they have told to me) Cisco Configuration: == name A.A.A.A siteApublicIP object-group network siteA access-list outside_cryptomap_23 extended permit ip object-group siteA host 10.0.22.221 crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac crypto map outside_map 22 match address outside_cryptomap_23 crypto map outside_map 22 set pfs crypto map outside_map 22 set peer siteApublicIP crypto map outside_map 22 set transform-set ESP-3DES-MD5 tunnel-group A.A.A.A type ipsec-l2l tunnel-group A.A.A.A ipsec-attributes pre-shared-key theKey OpenBSD Config: == /etc/ipsec.conf: == ike active esp from 10.0.22.221 (172.22.0.0/16) to 10.20.10.0/24 \ peer B.B.B.B \ main auth hmac-md5 enc 3des \ quick auth hmac-md5 enc 3des group modp1024 \ psk theKey /etc/pf.conf: == set skip on lo match out log on $ext_if from 172.22/16 to 10.20.10.0/24 nat-to 10.0.22.221 match out log on $int_if from 172.22/16 to !172.22/16 nat-to A.A.A.A pass isakmpd output (via tcpdump): == 0.0.0.0.500 B.B.B.B.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 8f5627d25c664fa7- msgid: len: 180 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = MD5 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports OpenBSD-4.0) 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 208) B.B.B.B.500 A.A.A.A.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 8f5627d25c664fa7-a8427e4dfc02591c msgid: len: 124 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = MD5 attribute GROUP_DESCRIPTION = MODP_1024 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 24 [ttl 0] (id 1, len 152) A.A.A.A.500 B.B.B.B.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie:
Re: Editing PDF files
Take a look at pdftk. It is a simple command line tool, that can do a lot of things with pdf files: merge, split, rotate, fill forms etc. http://www.accesspdf.com/pdftk/ Regards -Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Predrag Punosevac Gesendet: Dienstag, 5. Januar 2010 06:21 An: misc@openbsd.org Betreff: Editing PDF files I hope, I am not going to annoy too many people with this rather general question. I have some PDF form that I need to fill in. I thought that I would be able to accomplish the job in couple of minutes. Namely, my idea was to convert PDf file to PS file and then to use pstoedit to convert the PostScript file into fig file. Then like in old good times I would just add text to fig file and export to PDF. Just to be on the safe side I was to do the above process a single page at the time. My problem is that pstoedit is producing a huge non-usable fig file. What would be more claver way to accomplish above task short of buying Acrobat or using on-line PDF editing tools and exposing my private information. I heard that KOffice and Scribe have the ability to edit PDF file as well as Gimp. I am somewhat familiar with PDFEdit even though it is not ported to OpenBSD and not very enthusiastic about its abilities. Most Kind Regards, Predrag Punosevac
Re: IPSec Blues
-Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Aaron Mason Gesendet: Mittwoch, 2. Dezember 2009 23:14 An: OpenBSD Betreff: Re: IPSec Blues On Wed, Dec 2, 2009 at 11:02 AM, Bryan Irvine sparcta...@gmail.com wrote: Does somebody know about an updated guide/tutorial? ipsec(4) ipsec.conf(5) isakmpd(8) -B The saga continues. The guide I've been following is at http://www.openbsdsupport.org/vpn-ipsec.html - it's a bit outdated but it seems to work up to setting up the tunnel. isakmpd -d showed no errors at all, however I can't seem to be able to route data across the secure channel. obsd-ipsec-right# netstat -rn Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 10.255.255.4/30link#2 UC 20 - 4 vic1 10.255.255.5 00:0c:29:f6:20:80 UHLc 2 108 - 4 vic1 10.255.255.6 00:0c:29:e1:29:2c UHLc 00 - 4 lo0 127/8 127.0.0.1 UGRS 00 33200 8 lo0 127.0.0.1 127.0.0.1 UH 2 291 33200 4 lo0 192.168.33/24 link#1 UC 30 - 4 vic0 192.168.33.1 00:50:56:c0:00:06 UHLc 04 - 4 vic0 192.168.33.2 link#1 UHLc 01 - 4 vic0 192.168.33.7 127.0.0.1 UGHS 02 33200 8 lo0 192.168.33.253 link#1 UHLc 1 24 - 4 vic0 224/4 127.0.0.1 URS00 33200 8 lo0 Internet6: cruft Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 192.168.120/24 0 192.168.33/24 0 0 10.255.255.5/esp/use/in 192.168.33/24 0 192.168.120/24 0 0 10.255.255.5/esp/require/out obsd-ipsec-right# ping 192.168.120.130 PING 192.168.120.130 (192.168.120.130): 56 data bytes ping: sendto: No route to host ping: wrote 192.168.120.130 64 chars, ret=-1 --- 192.168.120.130 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss obsd-ipsec-left# netstat -rn Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 10.255.255.4/30link#2 UC 20 - 4 vic1 10.255.255.5 00:0c:29:f6:20:80 UHLc 00 - 4 lo0 10.255.255.6 link#2 UHLc 2 100 - 4 vic1 127/8 127.0.0.1 UGRS 00 33200 8 lo0 127.0.0.1 127.0.0.1 UH 2 288 33200 4 lo0 192.168.120/24 link#1 UC 20 - 4 vic0 192.168.120.1 00:50:56:c0:00:01 UHLc 0 24 - 4 vic0 192.168.120.130127.0.0.1 UGHS 00 33200 8 lo0 192.168.120.25400:50:56:e0:b4:04 UHLc 1 25 - 4 vic0 224/4 127.0.0.1 URS00 33200 8 lo0 Internet6: cruft Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 192.168.33/24 0 192.168.120/24 0 0 10.255.255.6/esp/use/in 192.168.120/24 0 192.168.33/24 0 0 10.255.255.6/esp/require/out obsd-ipsec-left# ping 192.168.33.7 PING 192.168.33.7 (192.168.33.7): 56 data bytes ping: sendto: No route to host ping: wrote 192.168.33.7 64 chars, ret=-1 --- 192.168.33.7 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss I tried setting up a static route pointing at the networks on either side, but these seem to pass unencrypted - when I listen on enc0, nothing appears. I even tried using the pf.conf file listed in that file (while making changes to suit my configuration)... no dice. Any ideas? I'm already using a PSK and tried using PKI, but only one side seemed to be encrypted. Thanks -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse I did not follow the complete thread. I'd just like to mention that I regularly get trapped with 'no route to host' when I set up new ipsec tunnels. In most cases I forgot to fix pf.conf for the new tunnel. Do you use pf? Regards Christoph
Re: How to determine what ports are being used?
1723 is PPTP. This uses GRE ( generic routing encapsulation ). You must allow this protocol. And, as far as I know, openBSD cannot NAT this protocol ( it is possible to nat GRE for pptp if you peek into the next higher level protocol ( ppp in this case ? ) but this is not implemented ) So I did a RDR for GRE to the only windows PC in my local network that needs PPTP. Something like rdr Pass on $ext_if proto gre from any - (address of Windows PC ) And further below in pf.conf allow GRE for your internal and external interface. regards christoph -Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Marcos Laufer Gesendet: Freitag, 27. November 2009 16:06 An: stan; misc@openbsd.org Betreff: Re: How to determine what ports are being used? You could fire up the VPN, connect to it from the outside, and then use the netstat command to see which ports are beeing used knowing the origin and destination IPs Regards, Marcos Laufer stan wrote: I have a home network tat uses an OpenBSD machine as it's firewall. I now have a company laptop (Windows), and it has some sort of Microsoft VPN. If it remove my block all rule I can get this VPN up. The corporate support folks say that it uses port 1723, but putting thta in pf.conf and restarting (with the block all) rule sill does not allow it to work. If I turn off the block all rule, and fire up the VPN, how can I determine what ports it is using, so that I can create the correct pf.conf rules?
Re: isakmpd will not initiate connection to Cisco ASA
Are you sure that obsd does not try to initiate the connection at least once? I have noticed the following problem with cisco: Some Cisco models delete the security association after an inactivity timeout, they call it Cisco IPSec Security Association Idle Timers. When this happens, openBSDs drop the information for this tunnel and is unable to recreate it. Cisco keeps the information and can reestablish the connection when someone pings or otherwise addresses the remote end. I had a short conversation about this with Hans-Jvrg Hvxer, but cannot say whether this behaviour is desired or considered a bug. I would try to delete the tunnel complete and configure it again while running tcpdump on the external interface ( or enable isakmpd packet capture, see the -L switch of isakmpd ). This will at least answer the question, whether openBSD attempts to establish the connection when the tunnel is defined for the first time. Regards Christoph -Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Chris Bullock Gesendet: Dienstag, 17. November 2009 15:45 An: misc@openbsd.org Betreff: isakmpd will not initiate connection to Cisco ASA We have many tunnels and for some reason I just set up a tunnel with a Cisco ASA and we can not initiate the connection from the OpenBSD side. If the Cisco side pings a device on the OpenBSD side the tunnel comes up. On the Cisco side they have bidirectional enabled, and they are not seeing the OpenBSD try to initiate the tunnel. Any help would be appreciated, Regards, Chris Bullock
nat,ipsec,pf,routing question
I'm sure I have seen the answer to my question here on the list some time ago, but I'm too stupid to find it again: In what order are the following operations performed on an IP packet a. IPSEC ( decides whether a packet matches an IPSEC flow ) b. normal kernel routing c. NAT d. packet filtering ( block/pass commands in pf.conf ) The reason I ask is that I failed to setup NAT for a IPSEC tunnel as described in http://marc.info/?l=openbsd-pfm=115875312200995w=2 As far as I understand, this can only work if NAT ( on lo1 ) is performed before IPSEC checks for matching flows. Has this order been changed in OBSD4 ( the above post from 2006 refers to OBSD 3.8 ). There is a newer posting on the same issue at http://archives.neohapsis.com/archives/openbsd/2008-12/1110.html, suggesting essentially the same procedure. Regards Christoph
Re: Problem with slow disk I/O
-Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Tobias Ulmer Gesendet: Donnerstag, 23. April 2009 14:02 An: Thomas Pfaff Cc: misc@openbsd.org Betreff: Re: Problem with slow disk I/O On Thu, Apr 23, 2009 at 03:27:42PM +0200, Thomas Pfaff wrote: I'm getting horrible disk performance compared to Ubuntu on my system. I noticed this when extracting ports.tar.gz on the same machine with different OSs (this is something I did a while back to check for a possible hardware problem when OpenBSD crashed upon extracting ports.tar.gz). OpenBSD (ffs): $ time tar -zxf ports.tar.gz 0m59.90s real 0m1.00s user 0m6.95s system Ubuntu (ext3): $ time tar -zxf ports.tar.gz real 0m18.440s user 0m1.212s sys 0m2.596s 1 minute on OpenBSD and 18.5 seconds on Ubuntu, doing the exact same thing on the exact same hardware! Why the huge difference? Both are default installations, except softdep is turned on. Thanks for any pointers or advice. Try: time tar -zxf ports.tar.gz sync better use parenthesis: time ( tar -zxf ports.tar.gz sync ) Compare # time sleep 1 sleep 5 0m1.01s real 0m0.00s user 0m0.01s system to # time ( sleep 1 sleep 5 ) 0m6.01s real 0m0.00s user 0m0.03s system Christoph
Re: tomcat without X11
You can use -Djava.awt.headless=true on the Java commandline to start without x. Regards Christoph -Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Eugeni Akmuradov Gesendet: Samstag, 14. Mdrz 2009 11:50 An: misc@openbsd.org Betreff: tomcat without X11 Hello out there! The task is to setup a web-server, that can run J2EE application, thoose, which are with .war extensions :) so, the possibility is tomcat+jdk, afaik. all is going at 4.3 - 4.4 updated machine, and here is the transcription: /usr/ports/devel/jdk r...@yangtze # make === devel/jdk/1.5 === jdk-1.5.0.14p1 depends on: kaffe-=1.1.7p1 - not found === Verifying install for kaffe-=1.1.7p1 in lang/kaffe === Checking files for kaffe-1.1.7 `/usr/ports/distfiles/kaffe-1.1.7.tar.gz' is up to date. (SHA256) kaffe-1.1.7.tar.gz: OK === kaffe-1.1.7p6 depends on: zip-* - found === kaffe-1.1.7p6 depends on: jikes-=1.22p0 - found === kaffe-1.1.7p6 depends on: gettext-=0.17 - found === kaffe-1.1.7p6 depends on: gmake-* - found === kaffe-1.1.7p6 depends on: libtool-* - found === kaffe-1.1.7p6 depends on: gtk+2-* - not found === Verifying install for gtk+2-* in x11/gtk+2 === Checking files for gtk+-2.12.11 `/usr/ports/distfiles/gtk+-2.12.11.tar.bz2' is up to date. (SHA256) gtk+-2.12.11.tar.bz2: OK === gtk+2-2.12.11 depends on: cups-* - not found === Verifying install for cups-* in print/cups === cups-1.2.7p9 depends on: foomatic-filters-* - not found === Verifying install for foomatic-filters-* in print/foomatic-filters === foomatic-filters-3.0.2p1 depends on: ghostscript-* - not found === Verifying install for ghostscript-* in print/ghostscript/gnu === Checking files for ghostscript-8.62p2 `/usr/ports/distfiles/ghostscript-8.62.tar.gz' is up to date. (SHA256) ghostscript-8.62.tar.gz: OK === Verifying specs: jpeg.=62 png.=6 ijs iconv.=2 jpeg.=62 png.=6 ijs iconv.=2 m c z X11 Xt Xext m c z X11 Xt Xext Missing library for X11 Missing library for Xt Missing library for Xext Fatal error the server was setuped without X distribution sets, as it should be, and of course, they are not welcome here. In that situation what are possibilites ?
Re: isakmpd does not initiate quick mode after main mode is established
I found that some of my problems are related to 'DELETE' messages from the peer ( cisco ASA's , for example ). There is another thread in this forum discussion this issue. Hans-Joerg Hoexer said that obsd/isakmpd should handle this case, but he will look into it. I would be interested to know if your problems are related to these 'DELETE' messages from the remote side. I see varying behaviour when these messages come in: . Sometimes the flows are deleted, and any further traffic gives 'no route to host' . Sometimes the flows are still shown ( in ipssecctl -sflow or netstat -rn -f encap ) and I see traffic on enc0, but no encap on the external interface. What do you see, when the connection dies? Regards Christoph -Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Christian Weisgerber Gesendet: Sonntag, 25. Januar 2009 23:10 An: misc@openbsd.org Betreff: Re: isakmpd does not initiate quick mode after main mode is established Christoph Leser le...@sup-logistik.de wrote: I'm still struggling to keep my ipsec vpns running smoothly. FWIW, I mostly use IPsec on my home WLAN and I observe a similar lack of reliability. My laptop sets up two IPsec associations, one IPv4 and one IPv6, and from time to time one of these or both fail inexplicably (no response, no proposal chosen) but eventually get established within ten minutes or so. Since this is WLAN, I have considered that packet loss may screw up the ISAKMP negotiation, but I haven't investigated. I wonder how people who run a large number of IPsec associations in production settings deal with this or if they are seeing it at all. -- Christian naddy Weisgerber na...@mips.inka.de
Re: net5501 crypto driver
Yes, I can confirm that glxsb.c 1.15 works fine with 4.4. stable. Now AES 256 works again. Thanks -Urspr|ngliche Nachricht- Von: Markus Friedl [mailto:markus.r.fri...@arcor.de] Gesendet: Dienstag, 20. Januar 2009 13:53 An: Christoph Leser Cc: misc@openbsd.org Betreff: Re: net5501 crypto driver 1.15 should just work fine in stable. -m On Tue, Jan 20, 2009 at 12:19:34PM +0100, Christoph Leser wrote: As described in http://kerneltrap.org/mailarchive/openbsd-misc/2008/9/22/3364064 there is a problem with the driver for the AMD Geode LX series processor security block for openBSD 4.4 ( glxsb.c ). This has been fixed in version 1.15 of this file, but this fix has not been committed to 4.4. stable ( still on 1.14 ). Is it ok to use 1.15 with 4.4 stable or do I have to switch to current inorder to use this patch. Regards Christoph
net5501 crypto driver
As described in http://kerneltrap.org/mailarchive/openbsd-misc/2008/9/22/3364064 there is a problem with the driver for the AMD Geode LX series processor security block for openBSD 4.4 ( glxsb.c ). This has been fixed in version 1.15 of this file, but this fix has not been committed to 4.4. stable ( still on 1.14 ). Is it ok to use 1.15 with 4.4 stable or do I have to switch to current inorder to use this patch. Regards Christoph
Cisco IPSec Security Association Idle Timers and isakmpd
Hi, I noticed that the cisco end of a VPN I configured on my openBSD sends a DELETE message after a certain amount of idle time. This feature is described in http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ftsaidle .html#wp1045897 The effect is, that the VPN no longer works. openBSD still shows the routes active ( in netstat -rnf encap ) and sends packets out to the remote site. It does not try to reestablish the phase 2 sa. Is this a bug or is it that just an incompatibility with ciscos 'idle time' feature ( which may not be 'standard' ) Regards Christoph
Re: Cisco IPSec Security Association Idle Timers and isakmpd
-Urspr|ngliche Nachricht- Von: dug [mailto:d...@xgs-france.com] Gesendet: Montag, 19. Januar 2009 17:44 An: Hans-Joerg Hoexer Cc: Christoph Leser; misc@openbsd.org Betreff: Re: Cisco IPSec Security Association Idle Timers and isakmpd Le 19 janv. 09 ` 17:37, Hans-Joerg Hoexer a icrit : Hi, On Mon, Jan 19, 2009 at 04:56:25PM +0100, Christoph Leser wrote: I noticed that the cisco end of a VPN I configured on my openBSD sends a DELETE message after a certain amount of idle time. Which SAs get deleted? isakmp, ipsec or both? HJ. When you execute netstat -rn, do you always see the SA on your OpenBSD, after DELETE message has been sended ? I cannot tell for sure. Most DELETE messages come in after an new SA has been established, so you would expect to see the SA in netstat output, wouldn't you. I would say that I see the SA, when only IPSEC is DELETED, but no SA, when IPSEC and ISAKMP is deleted.
isakmpd does not initiate quick mode after main mode is established
I'm still struggling to keep my ipsec vpns running smoothly. Is there a reference to a more detailed description of the allowed isakmp exchanges? Watching tcpdump for some time gives me a rough impression of what is going on, but it is hard to tell what's wrong ( if anything at all ) when the exchanges proceed other than they normally do. For example I see that 'normally' my isakmpd enters into phase-2 exchange immediately after phase-1 is established. But sometimes it delays to initiate phase-2 for up to 10 minutes ater phase-1 completes, and it often fails in these case ( no response from remote ). Any hints to books or online material are welcome. Thanks and regards Christoph
IPSEC: packets flow into enc0, but no esp packet are sent
After migrating to OBSD 4.4 ( from 4.1 ) I sometimes find that for a particular VPN ( tunnel mode ) : 1. The corresponding flows are established, as shown by netstat -rnf encap and ipsecctl -sflow 2. The packets sent to the remote site show up in tcpdump -leni enc0 with a valid SPI, as confirmed by ipsecctl -ssa 3. BUT NO corresponding esp packets leave the external interface: tcpdump -leni vr1 ip host remote-peer Only key exchange packets can be seen ( showing that the route to remote-peer is indeed via the external interface ). The other VPN tunnels work just fine. In this situation Tear down and reestablish the flows and/or SAs does not help. Restart isakmpd helps. Any ideas? Regards
migrate from isakmpd.conf to ipsec.conf
I used to configure VPNs using isakmpd.conf, for 2 dozen VPNs, each with a hand crafted set of parameters ( encryption, hmac, key length etc. ). Now I tried to move this setup to ipsec.conf by spelling out the complete line for every VPN like this: ike active esp tunnel from a.b.c.d to e.f.g.h peer u.v.w.x main auth hmac-sha1 enc aes group modp1024 quick auth hmac-sha1 enc aes group modp1024 psk xyz When I start isakmpd and configure these VPNs with ipsecctl -f /etc/ipsec.conf, all VPNs come up properly. But: alter a while, some VPNs stop working. tcpdump of isakmpd.pcap shows that the remote end tries to establish phase-1 with the same parameters that were used when my side ( openBSD ) establishes phase-1. But is rejected with 'NO PROPOSAL CHOSEN'. After setting isaqkmpd debug level, daemon.log reveals: Jan 12 14:00:09 q-dsl isakmpd[31387]: exchange_setup_p1: 0x8a499400 peer-u.v.w.x Default-phase-1-configuration policy responder phase 1 doi 1 exchange 2 step 0 This seems to indicate that for the incoming IP_PROT exchange the Default-phase-1-configuration is used, and the info from ipsec.conf is ignored. I found other incidences in the logfile where the remote end re-established the phase-1 successfully by initiating a ID_PROT exchange. In these case the debug message looks like: Jan 12 14:00:05 q-dsl isakmpd[31387]: exchange_setup_p1: 0x841b2700 peer-u.v.w.x phase1-peer-u.v.w.x policy responder phase 1 doi 1 exchange 2 step 0 I'm with you if you think the above text is rather confused, I apologize for that, I tried my very best :-) But you could do me a favour if you answered the following question: 1. Is it ok that the remote end initiates a phase-1 ID_PROT exchange for a VPN which I have defined as 'active' in my ipsec.conf. 2. If the answer is yes, am I right to expect that isakmpd uses the parameters I have specified for this VPN in ipsec.conf, finding the line with peer u.v.x.x = sender's IP Thank you for your patience. Regards Christoph
Re: ftp from script
Just my 1 cent on the perl script #!/usr/bin/perl `cd /path-to-dir`: `rm *`; will purge your working directory, not /path-to-dir, as each of the `command` constructs is executed in a process of its own and thus has no influence on the next command you would be better of with #!/usr/bin/perl `cd /path-to-dir;rm *`; Regards Christoph Von: owner-m...@openbsd.org im Auftrag von Ed Ahlsen-Girard Gesendet: Mi 31.12.2008 13:27 An: misc@openbsd.org Betreff: ftp from script I'm trying to automate getting the sets and source for running -current. For some reason, this syntax: ftp -ia ftp://host.domain/pub/OpenBSD/snapshots/architecture/*.tgz or this: ftp -ia ftp://host.domain/pub/OpenBSD/snapshots/architecture/bsd.rd works great from the command line. But not in scripts, either shell: #!/bin/sh cd /where/I/put/sets rm * # all above work fine ftp -ia ftp://host.domain/pub/OpenBSD/snapshots/architecture/*.tgz or perl: #!/usr/bin/perl `cd /where/I/put/sets`; `rm *`; # all above work fine `ftp -ia ftp://host.domain/pub/OpenBSD/snapshots/architecture/*.tgz`; ftp://host.domain/pub/OpenBSD/snapshots/architecture/*.tgz%60; Using system () does not get any different behavior, whether I pass a list or a proper array. In all cases I see a connection to the server, followed by a complaint of an invalid directory, and disconnection. I've been using perl for about ten years, and I'm pretty sure my perl is ok. Anybody have an idea of what I'm missing?
Re: How to start Syslogd with -u and -n options
as far as I know you need to set the syslogd_flags variable in /etc/rc.conf.local or /etc/rc.conf regards Christoph -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Sma11T0wnITGuy Gesendet: Donnerstag, 11. Dezember 2008 15:35 An: misc@openbsd.org Betreff: How to start Syslogd with -u and -n options I'm an OpenBSD noob. I'm setting up an OpenBSD Syslog Server. It will be the only device plugged into a particular switchport off its own VLAN on a switchcard in a Router. I'm running OpenBSD 4.3 with all applicable patches. The Syslog Server will not resolve any names, just accept log entries from the router, so I'd like to specify the -n option and the -u option. I've read the man pages for syslogd and syslog.conf, but I can't figure out how to get the daemon to start with the desired options. I must be missing or misunderstanding something in the man pages, or looking in the wrong places. Can someone help me define the startup options for syslogd, and tell me where to do so? Here's my syslog.conf file: # cat /etc/syslog.conf # $OpenBSD: syslog.conf,v 1.17 2005/05/25 07:35:38 david Exp $ # *.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages kern.debug;syslog,user.info /var/log/messages auth.info /var/log/authlog authpriv.debug /var/log/secure cron.info /var/cron/log daemon.info /var/log/daemon ftp.info /var/log/xferlog lpr.debug /var/log/lpd-errs mail.info /var/log/maillog #uucp.info /var/log/uucp # Uncomment this line to send important messages to the system # console: be aware that this could create lots of output. #*.err;auth.notice;authpriv.none;kern.debug;mail.crit /dev/console # Uncomment this to have all messages of notice level and higher # as well as all authentication messages sent to root. *.notice;auth.debug root # Everyone gets emergency messages. *.emerg * # Uncomment to log to a central host named loghost. You need to run # syslogd with the -u option on the remote host if you are using this. # (This is also required to log info from things like routers and # ISDN-equipment). If you run -u, you are vulnerable to syslog bombing, # and should consider blocking external syslog packets. #*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none @loghost #auth,daemon,syslog,user.info;authpriv,kern.debug @loghost # Uncomment to log messages from sudo(8) and chat(8) to their own # respective log files. Matches are done based on the program name. # Program-specific logs: !sudo *.* /var/log/sudo !chat *.* /var/log/chat # This line added to accept log files from Router *.* /var/log/router # -- View this message in context: http://www.nabble.com/How-to-start-Syslogd-with--u-and--n-opti ons-tp20956554p20956554.html Sent from the openbsd user - misc mailing list archive at Nabble.com.
Re: ISAKMPD - cisco : attribute ENCAPSULATION_MODE = 61443 (unknown)
thanks for the clarification. Indeed I can see in the traces that obsd isakmpd accepts 61443 and send out it's reply with the same value. But it uses 3, if it initiates the exchange. if so, I would guess that is the reason for the 'NO PROPOSAL CHOSEN' messages. Can I configure 61443 es encapsulation mode in isakmpd.conf? Thanks again Christoph -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Stuart Henderson Gesendet: Dienstag, 25. November 2008 11:51 An: misc@openbsd.org Betreff: Re: ISAKMPD - cisco : attribute ENCAPSULATION_MODE = 61443 (unknown) On 2008-11-25, Christoph Leser [EMAIL PROTECTED] wrote: I see the above message in the tcpdump of /var/run/isakmpd.pcap, when a cisco router establishes quick mode to my openbsd. The connect works ok, just wondering what this message could mean. I have only seen 'ENCAPSULATION MODE = TUNNEL' in this context. That's the encapsulation mode used by draft-ietf-ipsec-nat-t-ike. The non-draft version uses 3 not 61443. (There is also 61433 used by some broken Watchguard products). As connect setup fails in the opposite direction ( with NO PROPOSAL CHOSEN from cisco ), using the same parameters. You need a lot more information to work out what's happening here.
ISAKMPD - cisco : attribute ENCAPSULATION_MODE = 61443 (unknown)
Hi, I see the above message in the tcpdump of /var/run/isakmpd.pcap, when a cisco router establishes quick mode to my openbsd. The connect works ok, just wondering what this message could mean. I have only seen 'ENCAPSULATION MODE = TUNNEL' in this context. As connect setup fails in the opposite direction ( with NO PROPOSAL CHOSEN from cisco ), using the same parameters. regards christoph
'PAYLOAD MALFORMED' ipsec tunnel to openswan
Trying to establish an ipsec tunnel to a debian linux box with openswan, using this entry in ipsec.conf: ike active esp from 192.168.1.0/24 to 192.168.2.0/24 peer a.b.c.d srcid [EMAIL PROTECTED] dstid [EMAIL PROTECTED] psk xxx I get 'PAYLOAD MALFORMED' in the middle of the phase 1 negotiation: After the transforms are agreed upon and the nonces are exchanged, the message containing the ID payload is rejected by openBSD, either with a notification 'PAYLOAD MALFORMED' or with notification 'INVALID PAYLOAD TYPE' Here is a snippet of isakmpd.pcap: 21:38:55.438591 a.b.c.d.500 u.v.w.x.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 251068307c823c51-5086ce0f33dfbb37 msgid: len: 92 payload: ID len: 9336 [|isakmp] [ttl 0] (id 1, len 120) 21:38:55.439228 u.v.w.x.500 a.b.c.d.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: 88fba1fcd13186bd- msgid: len: 40 payload: NOTIFICATION len: 12 notification: INVALID PAYLOAD TYPE [ttl 0] (id 1, len 68) where a.b.c.d is openswan, and u.v.w.x is openbsd. The IDs are of type USER_FQDN ( or should be, at least ). The len field in the received packet seems queer. Maybe this causes the problem. This error only occurs, when the phase-1 exchange is initiated by openswan. If openbsd starts the phase-1 exchange, all seems ok. I would think this is an openswan problem, but how can I prove this? I have no access to the openswan box. Can I get more information about the offending packet, like a decrypted hexdump or else? Any hints are welcome. Regards Christoph
Re: Oddly high load average
I think the mailing lists would be better if it wasn't always full of people asking stupid questions, and then being answered by people with ridiculous or uneducated answers. Not that I want to be here providing the correct answers. Why bother? They won't be understood, and it isn't worth our time to explain things properly. But it also isn't worth anyone's time to see stupid questions answered with stupid answers, is it. I confess that I have asked stupid questions here too. Nevertheless the replies I got sometimes helped me out. So I even dared to answer to a few messages, although I may well be considered uneducated or even ridiculous. Sorry for this. I promise to keep my mouth shut in the future :-)
Re: isakmpd routing woes
-Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Carlos Laviola Gesendet: Donnerstag, 6. November 2008 13:34 An: misc@openbsd.org Betreff: isakmpd routing woes Hello, I have three /24 networks connected to each other through multihomed OpenBSD 4.0 servers using isakmpd(8). Recently, new point-to-point links have been installed between each of those networks on separate interfaces, and I would like to make it so traffic coming from/through specific (single) IPs in each of those networks reaches other specific single IPs in the other networks. Simply using route(8) was not enough, so I'm wondering if anyone knows if and how this can be done -- if this can still be done through isakmpd, great, but a way to bypass it so that the traffic can be redirected to the interfaces with the new links would also be enough. Thanks in advance! Carlos [ Please Cc replies to me if possible, as I'm not subscribed to the list. ] As far as I understand, the routes defined through isakmpd takes presidence over routes defined via route add command. But you can make isakmpd ignore specific ip addresses by adding bypass rules to your ipsec.conf like flow esp from a.b.c.0/24 to 10.105.60.100/32 type bypass would bypass the ipsec tunnel between a.b.c.0/24 and 10.105.60.0/24 if the target address is 10.150.60.100. Hope this helps Regards
Re: NAT + IPsec problem
-Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von BARDOU Pierre Gesendet: Donnerstag, 6. November 2008 15:30 An: misc@openbsd.org Cc: LOUIS Marc Betreff: NAT + IPsec problem Hello, I am trying to setup an IPsec connection. Here is the ipsec.conf : ike esp from 10.63.61.0/26 to 193.164.151.0/28 peer 193.164.151.35 \ main auth hmac-sha1 enc aes-256 \ quick auth hmac-sha1 enc aes-256 group modp1024 psk Tunnels go up well : flow esp in from 193.164.151.0/28 to 10.63.61.0/26 peer 193.164.151.35 srcid 212.99.28.26/32 dstid 10.3.2.2/32 type use flow esp out from 10.63.61.0/26 to 193.164.151.0/28 peer 193.164.151.35 srcid 212.99.28.26/32 dstid 10.3.2.2/32 type require esp tunnel from 193.164.151.35 to 212.99.28.26 spi 0x1fd5f292 auth hmac-sha1 enc aes esp tunnel from 212.99.28.26 to 193.164.151.35 spi 0xa0b3fc57 auth hmac-sha1 enc aes As my LAN is adressed using 10.31.0.0/16, I need to nat to 10.63.61.xxx before the tunnel. So I put this in my pf.conf : nat from 10.31.30.1 to 193.164.151.1 - 10.63.61.2 The problem is tha packets going from 10.31.30.1 to 193.164.151.1 don't go through the tunnel, they are going to the internet. Here is the pflog : Nov 06 15:16:16.932324 rule 532/(match) pass in on bge0: 10.31.30.1 193.164.151.1: icmp: echo request Nov 06 15:16:16.932362 rule 1/(match) block out on em0: 10.63.61.2 193.164.151.1: icmp: echo request - Packets are going out through em0 (my inet interface) instead of enc0 As pf doc says translation occurs before filtering, I don't understand why pf can see my real adress (10.31.30.1). And the most important : why outgoing packets -with good adresses- don't go through the tunnel ? Have I misconfigured something ? Thank you for your help -- Cordialement, Pierre BARDOU CSIM - Bureau 012 Midi Pyrinies Informatique Hospitalihre 12 rue Michel Labrousse BP93668 F-31036 Toulouse CEDEX 1 Til : 05 67 31 90 84 Fax : 05 34 61 51 00 Mail : [EMAIL PROTECTED] from openBSD ipsec manpage I ould guess that the decision, what flow to use is done before pf processes the packets. And as the original packets do not match the defined flows ( they are on a smaller subnet only ), the packets will go to the internet, and are not reconsidered for matching an ipsec flow after NAT has been done. I saw messages, where people have circumvented this by defining local ( lo ) interface, where the NAT can be done. Not exactly what you want do do, but might be provide some insight: http://fixunix.com/bsd/87865-nat-ipsec-openbsd-pf-isakmpd.html
Re: openbsd fail2ban
-Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Charlie Clark Gesendet: Donnerstag, 6. November 2008 18:34 An: misc Betreff: openbsd fail2ban Hi, I have noticed that people constantly try to brute force sshd on my openbsd box, on my server I use fail2ban to prevent this and wondered if there is a similar solution for openbsd. Regards, -- Charlie Clark Network Engineer Lemon Computing Ltd Unit 9 26-28 Priests Bridge London SW14 8TA UK Tel: +44 208 878 2138 Fax: +44 208 878 2163 Email: [EMAIL PROTECTED] Site: http://www.lemon-computing.com/ Lemon Computing is a limited company registered in England Wales under Company No. 03697052 you can use pf, I think. Put something like this in your pf.conf: table ssh-bruteforce block drop in log quick from ssh-bruteforce to any pass in $log_pass_ext \ on $ext_if \ inet proto tcp \ from any\ to $ext_if port 22 \ flags S/SA \ keep state \ (max-src-conn-rate 3/30,overload ssh-bruteforce flush global) and pf will move offending source ip to the bruteforce table and subsequently drop these packet
Re: How to debug IPSec and PF problem
-Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Rod Whitworth Gesendet: Mittwoch, 29. Oktober 2008 07:47 An: OpenBSD general usage list Betreff: Re: How to debug IPSec and PF problem On Wed, 29 Oct 2008 17:01:21 +1100, Mikel Lindsaar wrote: Hi all, I've got a VPN running between two networks. Works fine for basically everything and very easy to setup, kudos to the guys that worked on ipsecctl and isakmpd. I have one problem though that I am trying to debug. Network looks like this: 192.168.11.250# Asterisk1 | | 192.168.11.1# OpenBSD1 4.3 | | # VPN | 192.168.4.1 # OpenBSD2 4.3 | | 192.168.4.250 # Asterisk2 Firstly, I can ssh from any box to any box over the VPN. This works fine. So the basic VPN is functional. Secondly, 192.168.4.1 has several different routes out of it and a fairly complex setup in pf.conf and this is what I think I have misconfigured. I am trying to setup an IAX2 (port 4569) from asterisk1 to asterisk2. The traffic is running and I get the traffic flowing from one end to the other, but return traffic is getting blocked or misrouted. Tcpdump on 192.168.4.250 eth0 I see the packets from 192.168.11.250 arriving and packets from 192.168.4.250 leaving. Tcpdump on 192.168.4.1 enc0 I see the packets from 192.168.11.250 arriving and packets from 192.168.4.250 leaving. Tcpdump on 192.168.11.1 enc0 I only see the 192.168.11.250 packets. Tcpdump on 192.168.11.250 eth0 I only see the 192.168.11.250 packets. I have disabled any firewalls on both asterisk boxes, but this makes no change. Disabling pf on the 192.168.11.1 box makes no change. I can't disable pf on 192.168.4.1 right now (could schedule a time later) I believe the problem is somewhere in 192.168.4.1's pf.conf or route table. Now, I know this email contains no where near all the data needed to debug this by someone on list, but I want to work it out myself and I have a few questions. 1) Is the ipsec tunnel just treated like a standard interface by PF? 2) how and when does the ipsec tunnel grab packets to send through the tunnel? I can't see any route entries or the like. I assume it attaches somehow the same way PF does and intercepts packets. And probably most importantly: 3) What is the best way to find what rule in PF is matching the IAX UDP packet stream? I'm not getting anywhere with eyeballing it. If I can find how the packet is moving through the stack, I am sure I can fix the darn thing. Thanks Mikel By your statement I can ssh from any box to any box over the VPN. I understand you to mean from any LAN host at either end to any LAN host at the other. Is that correct? If so why would traffic from one LAN host at the 192.168.4. end be any different to the others? There is nothing magic about asterisk. I suggest that you traceroute from 192.168.4.250 to the other asterisk and see just where those packets go. I have a funny feeling they are heading out to the cloud naked rather than through IPsec. Of course if that is true there will be no reply after they hit the $ext_if in the near-end router. I don't know how you would manage to get this situation without screwing up the other hosts on the same LAN but then you have not shown any configurations at all so I have to use my personal ESP which has less than 6/6 vision. FYI your inet routing table gives no hint to packets as to which path to choose involving IPsec. If they don't match your ipsec.conf they don't go up the tunnel. If you need more help you need to supply more info. /R *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device Hi, I think 1. netstat -rn -f encap should show 2 entries for your IPSEC tunnel, one for each direction. 2. tcpdump -lenvvvi pflog0 will show packets being blocked are let pass including the number of the rule which was applied ( if you have logging enabled in your pf.conf ) 3. tcpdump on the other interfaces of your bsd boxed might help to discover the missing packets ( if, as Rod suspects, they are just routed into the cloud ). Regards Christoph
Re: J.C. Roberts [EMAIL PROTECTED] saiz OpenBSD. --We won't miss you.
-Urspr|ngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Im Auftrag von bofh
Gesendet: Dienstag, 28. Oktober 2008 16:13
An: OpenBSD general usage list
Betreff: Re: J.C. Roberts [EMAIL PROTECTED] saiz
OpenBSD. --We won't miss you.
On Tue, Oct 28, 2008 at 9:55 AM, Kevin Wilcox
[EMAIL PROTECTED] wrote:
2008/10/28 Owain Ainsworth [EMAIL PROTECTED]:
On Tue, Oct 28, 2008 at 05:37:24AM -0700, Neko wrote:
git a life
[EMAIL PROTECTED]:~$git clone a://life
Initialized empty Git repository in /home/oga/life/.git/
fatal: I don't handle protocol 'a'
Didn't anyone ever tell you not to run arbitrary commands
you read on
a mailing list? grin
I dunno. I once typed in :(){ :|: };: that I read on a
mailing list into my bash shell but it did nothing to my
openbsd box. Nor my osx box. Linux boxes otoh
I tried on linux ( rhel5 ), where it generated lots of
-bash: fork: Resource temporarily unavailable
messages.
After running it once, a single colon on the commandline gave the same effect,
which was the clue to what happened.
On linux bash
:(){ :|: };:
defines a function calling itself recursively in the background
: ()
{
: | :
}
The last colon then calls this function.
I'm not a shell expert. Is this behaviour expected? I found, that I can define
function '+', '-', '/', '?' etc. .
Re: slow network performance behind cisco
-Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Otto Moerbeek Gesendet: Freitag, 24. Oktober 2008 13:11 An: Sebastian Reitenbach Cc: misc@openbsd.org Betreff: Re: slow network performance behind cisco On Fri, Oct 24, 2008 at 12:58:27PM +0200, Sebastian Reitenbach wrote: Hello everybody, I'm experiencing a very bad network performance, when I try to connect to a remote server. The point-to-point connection is a E3 line, with 34MBit/s, with a cisco 2800 router on each side, terminating the point-to-point connection. These cisco routers have two gigabit interfaces, and a serial point-to-point E3 controller. Below my network layout: +-+ |Remote Server| +-+ |GigaBit Ethernet ++ |Remote Cisco| ++ |Serial E3 Line | ++ GigaBit Ethernet+-+ |Local Cisco |-|Linux Box| ++ +-+ |GigaBit Ethernet +---+ |BSD Box| +---+ I use iperf to measure the connection speed. The OpenBSD box, and the Linux box are in two different networks, so the connection between these two is also routed. When I use iperf between the Linux-Box and the BSD-Box, then iperf measures about 500MBit/s, so thats fine. When I use iperf between the Linux Box and the remote server, then I get sth. about 32 MBits, that's fine too. When I use iperf between the BSD box and the remote server, I only get 2MBit/s. Then I thought, maybe the interface where the BSD box is connected is the problem, so I connected it to the interface on the cisco, where the Linux box was connected before, but still only the 2MBit/s speed to the remote host. I also tried different OpenBSD boxes, with different network adaptors, one with bge, another one with fxp, but also, no difference. With both BSD boxes, connection to the Linux box is fast, connections to the remote server is slow. Then I tried to fiddle around with pf, scrub rules on the BSD box. I tested with disabled firewall, with scrub no-df scrub set-tos lowdelay scrub set-tos throughput and some more, but without any observable difference in the speed. The Linux box and the BSD boxes both had the same MTU on their interfaces, and also no dropped packets, or errors on the interfaces. When I connect the Linux box behind the OpenBSD box, and then try to connect from the Linux box to the OpenBSD box, the performance becomes slow. So right now I'm a bit puzzled, and have no idea, why the connection to the remote host is fast when using a Linux box, but so slow when using OpenBSD. Are there any differences in the IP packets that OpenBSD and Linux creates? I'm going to capture the network traffic on the Linux and OpenBSD box to be able to compare the IP packets. Is there any tool where I can replay the packet sequence on OpenBSD that I have recorded with tcpdump on the Linux box? Unfortunately, I don't have access to the remote cisco, or remote server, so I cannot check anything there. any hint is greatly appreciated. OpenBSD uses a pretty low default send and receive buffer size for sockets. Try increasing net.inet.tcp.recvspace and net.inet.tcp.sendspace, after reading a bit about bandwidth * delay products. -Otto If there is more information needed from my side, to explain the problem, don't hesitate to ask. kind regards Sebastian __ _ Jetzt neu! Sch|tzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 If it is a buffer size problem, why can he transmit 500mb/sec between bsd and local linux?
IKE V2 on openBSD
I'd like to ask the community: Will IKE V2 ever become available on a larger scale and will it eventually replace V1 sometime? Regards
Re: OpenBSD + isakmpd + VPN concentrator 3060
This is interesting. We suffer from spurious connection losses since we started with OBSD ipsec. Do you have any details what caused your problem, and why setting DPD-check-interval helped? In our environnement (we manage openbsd tunnels to cisco 3030 which is out of our scope) we debugged a strange problem when the connection goes down. The tunnels won't come back after a small link shutdown. The problem was Cisco 3030 was doing DPD check and not the OpenBSD. If it's the case for you too, you should add these lines to /etc/isakmpd/isakmpd.conf : --- isakmpd.conf --- [General] DPD-check-interval= 30 --- isakmpd.conf ---
Re: OpenBSD Road Warrior connecting to L2TP/IPSec VPN?
-Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Aaron W. Hsu Gesendet: Montag, 22. September 2008 20:04 An: misc@openbsd.org Betreff: OpenBSD Road Warrior connecting to L2TP/IPSec VPN? Hell All, I am trying to connect to my University's VPN System, with little luck, I am not sure how to even begin, though I have found Undeadly articles on IPSec in Under 4 Minutes, as well as some various tutorials and documents on connecting OpenBSD Servers to other Servers and gateways. I don't even know if this is possible, but looking at ipsec.conf, I can't see any details about how I would configure my system to connect to this VPN. Is it possible? If so, how? I've added just a basic ipsec.conf line: ike dynamic esp from any to any peer ipsec.indiana.edu psk hermanbwells But I haven't gotten much further than that. Does any one have any suggestions? The University's Guide to the VPN is: http://kb.iu.edu/data/ajrq.html Aaron Hsu From the cited page I would guess they use l2tp over ipsec. I think this is not suppoerted by openbsd, but I may be wrong.
arp info overwritten ... log message
I would like to block these messages as they fill up /var/log/messages A MS windows server with a trunked interface sends packets with either of its two hardware addresses, causing these messages Regards
priority of routes ( ipsec and local interface routes )
Hi, I've a question regarding the priority of routing entries. Please take a look at the following routing table for a machine with 3 ethernet interfaces ( link#1 192.168.0.1 ( internal net 1 /24 ) link#2 u.v.w.254 ( internet/30 ) link#4 10.10.60.1 ( internal net 2 /24 ): netstat -rn # netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface defaultu.v.w.253 UGS17 103292 - vr1 192.168.0.0/24 link#1 UC 160 - vr0 u.v.w.252/30 link#2 UC 10 - vr1 10.10.60/24link#4 UC 10 - vr3 127/8 127.0.0.1 UGRS00 33224 lo0 127.0.0.1 127.0.0.1 UH 10 33224 lo0 224/4 127.0.0.1 URS 00 33224 lo0 Internet6: DestinationGatewayFlags Refs UseMtu Interface nothing intesting here Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 10.10/16 0 192.168.0.0/24 0 0 a.b.c.d/esp/use/in 192.168.0.0/24 0 10.10/16 0 0 a.b.c.d/esp/require/out # The point is: There a general route to 10.10/16 via an ipsec tunnel, and a more specific route to 10.10.60/24 on a local interface 4. When I establish an connection from the localhost to host 10.10.60.100 ( on local subnet 2 ), this works fine. When I try to connect to the same host 10.10.60.100 from a host in local subnet 1 ( 192.168.0/24 ), using my host as default gateway, the packet gets routed through the vpn to the more general subnet 10.10/16. I.e. in this case it seems that the VPN route takes precedence over the more specific route via the local interface. Another effect of the same problem is that on the local host: ping 10.10.60.100 works whereas ping -I 192.168.60.1 10.10.60.100 does not work ( packets are routed into the vpn tunnel ). I believe that I read in the networking faqs that a more specific route takes precedence over a less specific one. It seems that this does not hold when one route is via a local interface and the other over vpn. If this is true, can I somehow change this behaviour, so that the more specific route is considered first in any case? Thanks
wrong dst field in /var/run/isakmpd.result
Hi, still hunting down a problem with my ipsec vpn connection terminating, I found inconsistencies in /var/run/isakmpd.result when I do a echo S /var/run/isakmpd.fifo Occationally I find an entry where the destination address and the SA name do not match. The dst address displayed actually belongs to a diffent SA. I these cases, I only have phase 2 SAs for this particular vpn in the dump of SAs. netstat -rnfencap or ipsecctl -ssa do not show this vpn's sa any more. ping to a host in the peer network gives ' no route to network'. I can recover with echo 't quick wrong ip address' /var/run/isakmpd.fifo echo 'c vpn-name' /var/run/isakmpd.fifo Is there anything known about such behaviour ? Thanks Christoph Mit freundlichen Gr|_en Christoph Leser SP Computersysteme GmbH Systemhaus f|r Logistik Tel: 0711 726410 Mail: [EMAIL PROTECTED] Amtsgericht Stuttgart HRB 11921 Geschdftsf|hrer J|rgen Probst, Horst Reichert
Re: Access to a remote Oracle database
Hi, afaik all access to oracle databases require oracle client software. only exception I know of is JDBC ( java database connectivity, which has a thin client requiring only tcp and the oracle jdbc client, which is pure java. maybe that is an option. if not you might connect your ms sql server to the oracle database with Oracle OLE DB or something like and access oracle via mssql. regards -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Joaquin Herrero Gesendet: Dienstag, 4. Dezember 2007 23:09 An: misc@openbsd.org Betreff: Access to a remote Oracle database Hi, I'm using freetds from my OpenBSD machine to connect to a MS SQL Server and works like a charm. Now I need to access to a Oracle server but it seems that the TDS protocol is not supported by Oracle databases, they use their own protocol named TNS and there is no freetns available. I investigated if I could use ODBC, but it seems (afaik) that ODBC needs a specific driver for each database and I do not know if there is such driver for OpenBSD. Perhaps someone know... a) if with freetds it is possible to connect to Oracle (perhaps activating some tds listener in the database) b) if ODBC is usable in OpenBSD to talk to Oracle. I'm using OpenBSD in a sparc machine at the moment (Sun Netra T1), but I can use a x86 machine as well. Any comments appreciated. -- Joaquin Herrero
what is the idea of the delete payload of isakmp exchange info ?
On one of my ipsec vpn I regularly receive messages like the following 16:03:26.685282 remotehost.500 localhost.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: ddae40befdf8a5d6-d38ee14e8992fba1 msgid: f2da6538 len: 76 payload: HASH len: 24 payload: DELETE len: 16 DOI: 1(IPSEC) proto: IPSEC_ESP nspis: 1 SPI: 0x3fcc2416 [ttl 0] (id 1, len 104) 16:03:26.697136 remotehost.500 locahost.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: ddae40befdf8a5d6-d38ee14e8992fba1 msgid: c0312a10 len: 76 payload: HASH len: 24 payload: DELETE len: 16 DOI: 1(IPSEC) proto: IPSEC_ESP nspis: 1 SPI: 0x7c6b161d [ttl 0] (id 1, len 104) 16:03:26.703921 remotehost.500 localhost.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: ddae40befdf8a5d6-d38ee14e8992fba1 msgid: 78727922 len: 92 payload: HASH len: 24 payload: DELETE len: 28 DOI: 1(IPSEC) proto: ISAKMP nspis: 1 cookie: ddae40befdf8a5d6-d38ee14e8992fba1 [ttl 0] (id 1, len 120) In most cases isakmpd reinitiates an id_prot exchange and the vpn is again established. But sometimes it does not try. What do these messages do, why are they sent? Is it a normal behaviour or is the remote site trying to end the vpn. ( remote is a lancom ?? ). Why is it that isakmpd sometimes tries to reestablish and sometimes it does not? Thanks for any hints Mit freundlichen Gr|_en Christoph Leser SP Computersysteme GmbH Systemhaus f|r Logistik Tel: 0711 726410 Mail: [EMAIL PROTECTED] Amtsgericht Stuttgart HRB 11921 Geschdftsf|hrer J|rgen Probst, Horst Reichert
Re: ipsec vpn netgear DG834 : openbsd 4.2 (new thread)
Hi,
here my 50 cent:
tcpdump looks good, obsd maschine receives first message of phase 1 exchange
and sends a suitable response.
your netgear log says, that no response to first message is received.
this means, response from isakmpd gets lost, either in local pf or in netgear
( dont know if they have some sort packet filter ) or somewhere in between .
you could distinguish there two possibilities by either
tcpdump -lenvvi pflog0 # watch out for packets to if_A that are blocked
or
tcpdump -lenvvi external if ip host if_A ( you should see exactly one
message in and one message out )
Once we know whether the packets really leave openBSD, we can do further
analysis.
-Urspr|ngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag
von jcr
Gesendet: Dienstag, 27. November 2007 12:10
An: misc@openbsd.org
Betreff: ipsec vpn netgear DG834 : openbsd 4.2 (new thread)
New thread .. after some new test..
And stiill the same ... shit !
Here is the LAn/WAn network
192.168.0/24(lan)--Netgear DG 834 (adsl + NAT + ipsec +ip fix A)
|
---WEB---
|
Openbsd 4.2
(ipsec.conf+isakmpd.policy+ip fix B+ NAT) -- 10.7.22.0/24(lan)
Here are the conf :
netgear :
local lan : 192.168.0.0/24
remote lan : 10.7.22.0/24
IKE :
direction : initiator respond
mode : main
diffie-Hellman : Groupe 2 (1024)
local id : IP wan
remote id: IP
Params
Crypto algo : 3DES
Algo auth : SHA-1
pre shared key : 123456789
SA life time : 36000
Openbsd :
ipsec.conf
ike passive esp tunnel from IP_A to IP_B \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des psk 123456789
ike dynamic esp tunnel from 192.168.0.0/24 to 10.7.22.0/24 peer IP_A \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des psk 123456789
i have tried passive dynamic for ike esp .. it's the same
isakmpd.policy
KeyNote-Version: 2
Authorizer: POLICY
pf.conf
pass in on $ext_if1 proto udp from $IP_A to $IP_B port {500,4500}
pass out on $ext_if1 proto udp from $IP_B to $IP_A port {500,4500}
pass in on $IP_B proto esp from $IP_A to $IP_B
pass out on $IP_B proto esp from $IP_B to $IP_A
pass in on enc0 proto ipencap from $IP_A to $IP_B keep state
(if-bound)
pass out on enc0 proto ipencap from $IP_B to $IP_A keep state
(if-bound)
pass in on enc0 from 192.168.0.0/24 to 10.7.22.0/24 keep
state (if-bound)
pass out on enc0 from 10.7.22.0/24 to 192.168.0.0/24 keep
state (if-bound)
i have a rule for nat on $IP_B
enc0 is up and running
i start my vpn with
isakmpd -dv -D 8=99
And Finally here is the Trouble , i got this on isakmpd console
151330.400513 Negt 30 message_negotiate_sa: transform 0 proto
1 proposal
0 ok
151330.400933 Negt 20 ike_phase_1_validate_prop: success
151330.401046 Negt 30 message_negotiate_sa: proposal 0 succeeded
151357.435134 Default transport_send_messages: giving up on exchange
peer-IP_A, no response from peer IP_A:500
And this on the DG834
Fri, 2007-11-23 14:13:30 - [idle] initiating Main Mode
Fri, 2007-11-23 14:13:40 - [idle] STATE_MAIN_I1: retransmission; will
wait 20s for response
Fri, 2007-11-23 14:14:00 - [idle] STATE_MAIN_I1: retransmission; will
wait 40s for response
Fri, 2007-11-23 14:14:40 - [idle] max number of
retransmissions reached
STATE_MAIN_I1. No acceptable response to our first IKE message
and finally ( As wanted for those who try to help me .. thanks)
echo p on /var/run/isakmpd.fif and tcpdump -r
/var/run/isakmpd.pcap
-vvn
tcpdump: WARNING: snaplen raised from 96 to 65536
11:40:31.600710 IP_A.500 IP_B.500: [udp sum ok] isakmp v1.0
exchange
ID_PROT
cookie: cb79617a4b409a8f- msgid:
len: 100
payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 40 proposal: 0 proto:
ISAKMP spisz: 0
xforms: 1
payload: TRANSFORM len: 32
transform: 0 ID: ISAKMP
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 3600
attribute ENCRYPTION_ALGORITHM = 3DES_CBC
attribute HASH_ALGORITHM = SHA
attribute AUTHENTICATION_METHOD = PRE_SHARED
attribute GROUP_DESCRIPTION = MODP_1024
payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0]
(id 1, len 128)
11:40:31.601712 IP_B.500 IP_A.500: [udp sum ok] isakmp v1.0
exchange
ID_PROT
cookie: cb79617a4b409a8f-76316a628a99ce2b msgid:
len: 180
payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 40 proposal: 0 proto:
ISAKMP spisz: 0
xforms: 1
payload: TRANSFORM len: 32
Re: ipsec vpn netgear DG834 : openbsd 4.2 (new thread)
I forgot to ask:
what are the NAT statements in your pf.conf, that you mention. the ipsec
packets should not be NAT'ed inyour configuration ( although ipsec can go
through NAT in general ).
-Urspr|ngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag
von jcr
Gesendet: Dienstag, 27. November 2007 12:10
An: misc@openbsd.org
Betreff: ipsec vpn netgear DG834 : openbsd 4.2 (new thread)
New thread .. after some new test..
And stiill the same ... shit !
Here is the LAn/WAn network
192.168.0/24(lan)--Netgear DG 834 (adsl + NAT + ipsec +ip fix A)
|
---WEB---
|
Openbsd 4.2
(ipsec.conf+isakmpd.policy+ip fix B+ NAT) -- 10.7.22.0/24(lan)
Here are the conf :
netgear :
local lan : 192.168.0.0/24
remote lan : 10.7.22.0/24
IKE :
direction : initiator respond
mode : main
diffie-Hellman : Groupe 2 (1024)
local id : IP wan
remote id: IP
Params
Crypto algo : 3DES
Algo auth : SHA-1
pre shared key : 123456789
SA life time : 36000
Openbsd :
ipsec.conf
ike passive esp tunnel from IP_A to IP_B \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des psk 123456789
ike dynamic esp tunnel from 192.168.0.0/24 to 10.7.22.0/24 peer IP_A \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des psk 123456789
i have tried passive dynamic for ike esp .. it's the same
isakmpd.policy
KeyNote-Version: 2
Authorizer: POLICY
pf.conf
pass in on $ext_if1 proto udp from $IP_A to $IP_B port {500,4500}
pass out on $ext_if1 proto udp from $IP_B to $IP_A port {500,4500}
pass in on $IP_B proto esp from $IP_A to $IP_B
pass out on $IP_B proto esp from $IP_B to $IP_A
pass in on enc0 proto ipencap from $IP_A to $IP_B keep state
(if-bound)
pass out on enc0 proto ipencap from $IP_B to $IP_A keep state
(if-bound)
pass in on enc0 from 192.168.0.0/24 to 10.7.22.0/24 keep
state (if-bound)
pass out on enc0 from 10.7.22.0/24 to 192.168.0.0/24 keep
state (if-bound)
i have a rule for nat on $IP_B
enc0 is up and running
i start my vpn with
isakmpd -dv -D 8=99
And Finally here is the Trouble , i got this on isakmpd console
151330.400513 Negt 30 message_negotiate_sa: transform 0 proto
1 proposal
0 ok
151330.400933 Negt 20 ike_phase_1_validate_prop: success
151330.401046 Negt 30 message_negotiate_sa: proposal 0 succeeded
151357.435134 Default transport_send_messages: giving up on exchange
peer-IP_A, no response from peer IP_A:500
And this on the DG834
Fri, 2007-11-23 14:13:30 - [idle] initiating Main Mode
Fri, 2007-11-23 14:13:40 - [idle] STATE_MAIN_I1: retransmission; will
wait 20s for response
Fri, 2007-11-23 14:14:00 - [idle] STATE_MAIN_I1: retransmission; will
wait 40s for response
Fri, 2007-11-23 14:14:40 - [idle] max number of
retransmissions reached
STATE_MAIN_I1. No acceptable response to our first IKE message
and finally ( As wanted for those who try to help me .. thanks)
echo p on /var/run/isakmpd.fif and tcpdump -r
/var/run/isakmpd.pcap
-vvn
tcpdump: WARNING: snaplen raised from 96 to 65536
11:40:31.600710 IP_A.500 IP_B.500: [udp sum ok] isakmp v1.0
exchange
ID_PROT
cookie: cb79617a4b409a8f- msgid:
len: 100
payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 40 proposal: 0 proto:
ISAKMP spisz: 0
xforms: 1
payload: TRANSFORM len: 32
transform: 0 ID: ISAKMP
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 3600
attribute ENCRYPTION_ALGORITHM = 3DES_CBC
attribute HASH_ALGORITHM = SHA
attribute AUTHENTICATION_METHOD = PRE_SHARED
attribute GROUP_DESCRIPTION = MODP_1024
payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0]
(id 1, len 128)
11:40:31.601712 IP_B.500 IP_A.500: [udp sum ok] isakmp v1.0
exchange
ID_PROT
cookie: cb79617a4b409a8f-76316a628a99ce2b msgid:
len: 180
payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 40 proposal: 0 proto:
ISAKMP spisz: 0
xforms: 1
payload: TRANSFORM len: 32
transform: 0 ID: ISAKMP
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 3600
attribute ENCRYPTION_ALGORITHM = 3DES_CBC
attribute HASH_ALGORITHM = SHA
attribute AUTHENTICATION_METHOD = PRE_SHARED
attribute GROUP_DESCRIPTION = MODP_1024
payload: VENDOR len: 20 (supports OpenBSD-4.0)
payload: VENDOR len: 20 (supports
ntp and pppoe
Hi, I use the pppoe0 device to connect to my isp. And I use ntpd. ntpd seems not to be aware of the changing ip address of the interface. It keeps sending messages with the source address it saw on startup, as can be seen for netstat -an or pflog. Is there a signal I can send to ntpd to rebind it upd socket to the new address, or must I restart ntpd. Can this be done by adding some commands to hostname.pppoe0, with the syntax used for the route command: !/sbin/route add default -ifp pppoe0 0.0.0.1 say !/usr/local/bin/restart_ntpd.sh ? i.e. are these ! commands called every time the pppoe interface changes its address? Thanks
isakmpd: lost vpn connection
I have a problem with ipsec/isakmpd. I have setup about 20 vpn's to various other sites, all using tunnel mode ( active ). All but one are working fine. One connection exhibits the following behaviour: After isakmpd starts, the vpn starts correctly, main and quick mode are successfully negotiated and I can ping or ssh the remote site. I can see the route with netstat -rnf encap and the SA and FLOW corresponding to this vpn in ipsecctl -s output. When I leave the connection idle for some time, the routing entry vanishes, as do the flow and sa in ipsecctl output. When I ping the remote site, I get 'no route to host'. isakmpd does not try to restart the connection: using tcpdump on the external interface I see no packets travelling to the remote site. Here is a trace rom isakmpd.pcap, showing the last packets before the vpn connection fails: 12:34:49.770248 yyy.yyy.96.195.500 xxx.xxx.193.254.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: b10f8a7f26c972af-aaae3029f2561bf8 msgid: c6de5870 len: 92 payload: HASH len: 24 payload: NOTIFICATION len: 32 notification: STATUS_DPD_R_U_THERE seq 2013739885 [ttl 0] (id 1, len 120) 12:34:49.770670 xxx.xxx.193.254.500 yyy.yyy.96.195.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: b10f8a7f26c972af-aaae3029f2561bf8 msgid: 1dd317ee len: 84 payload: HASH len: 24 payload: NOTIFICATION len: 32 notification: STATUS_DPD_R_U_THERE_ACK seq 2013739885 [ttl 0] (id 1, len 112) 12:35:49.811361 yyy.yyy.96.195.500 xxx.xxx.193.254.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: b10f8a7f26c972af-aaae3029f2561bf8 msgid: 5cd1ec2c len: 92 payload: HASH len: 24 payload: NOTIFICATION len: 32 notification: STATUS_DPD_R_U_THERE seq 2013739886 [ttl 0] (id 1, len 120) 12:35:49.811751 xxx.xxx.193.254.500 yyy.yyy.96.195.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: b10f8a7f26c972af-aaae3029f2561bf8 msgid: dedfee25 len: 84 payload: HASH len: 24 payload: NOTIFICATION len: 32 notification: STATUS_DPD_R_U_THERE_ACK seq 2013739886 [ttl 0] (id 1, len 112) 12:36:23.879320 yyy.yyy.96.195.500 xxx.xxx.193.254.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: b10f8a7f26c972af-aaae3029f2561bf8 msgid: b4875e25 len: 76 payload: HASH len: 24 payload: DELETE len: 16 DOI: 1(IPSEC) proto: IPSEC_ESP nspis: 1 SPI: 0x7a08d616 [ttl 0] (id 1, len 104) 12:36:23.891020 yyy.yyy.96.195.500 xxx.xxx.193.254.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: b10f8a7f26c972af-aaae3029f2561bf8 msgid: 1c7e734f len: 92 payload: HASH len: 24 payload: DELETE len: 28 DOI: 1(IPSEC) proto: ISAKMP nspis: 1 cookie: b10f8a7f26c972af-aaae3029f2561bf8 [ttl 0] (id 1, len 120) xxx.xxx is my local external ip address, yyy.yyy is the remote peer. So after a few R_U_THERE exchanges, the remote site deletes the SA ( or at least that is what I think it does ). Consequently, the routing entries on my local machine disappear, as said above. Under normal circumstances, my machine ( isakmpd ) immediately restarts the connection, which completes without problem. But sometimes, id does not. In thiese cases, the above shown messages are the last I see. After killing and restarting isakmpd, the vpn is established without problems. One strange observation I can add. I dumped the isakmpd state with echo S /var/runisakmpd.fifo, I get the following: SA name: VPN-1 (Phase 2) src: xxx.xxx.193.254 dst: aaa.aaa.aaa.aaa Lifetime: 2000 seconds Soft timeout in 1597 seconds Hard timeout in 1803 seconds Lifetime: 20 kilobytes Flags 0x000b SPI 0: 11fd2770 SPI 1: af8ec4b7 Transform: IPsec ESP Encryption key length: 16 Authentication key length: 16 Encryption algorithm: AES-128 (CBC) Authentication algorithm: HMAC-MD5 SA name: VPN-1 (Phase 2) src: 87.234.193.254 dst: bbb.bbb.bbb.bbb Lifetime: 3600 seconds Soft timeout in 911 seconds Hard timeout in 1372 seconds Flags 0x0003 SPI 0: 88cce18f SPI 1: 93baf3e0 Transform: IPsec ESP Encryption key length: 24 Authentication key length: 20 Encryption algorithm: 3DES Authentication algorithm: HMAC-SHA1 I find no phase 1 entry for VPN-1, but two phase 2 entries, and both have destination address ( aaa.aaa.aaa.aaa and bbb.bbb.bbb.bbb ) which have nothing to do with the peer address of VPN-1. These to addresses are the peer addresses of two of my other vpns. My policy file is just default, my openBSD is 4.1. Presumeably this is a configuration error, but I have no idea what to look for. Thanks Christoph
WG: isakmp phase 2 negotiation failed
-Urspr|ngliche Nachricht- Von: Christoph Leser Gesendet: Freitag, 21. September 2007 12:58 An: 'n0g0013' Betreff: AW: isakmp phase 2 negotiation failed -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von n0g0013 Gesendet: Donnerstag, 20. September 2007 23:52 An: misc@openbsd.org Betreff: isakmp phase 2 negotiation failed having a nightmare getting two openbsd (one 3.8, one 4.0) boxes to setup a tunnel. finally got the phase 1 negotiation going (or so i believe from reviewing the logs) but it appears that the phase two starts and is just abandoned. my best guess is that the default definitions for QM-ESP-DES-MD5-SUITE are incompatible but i can't seem to get by it. the -DA=99 output and configuration files are attached in the hope that someone make sense of this. i also have the -L dump if anyone needs it. thanks for any assistance. -- t t w # isakmpd configuration [General] Listen-on= 83.104.36.71 [X509-Certificates] CA-directory=/etc/isakmpd/ca/ Cert-directory= /etc/isakmpd/certs/ Private-key= /etc/isakmpd/private/local.key [Phase 1] #84.203.180.117= gw.vpn.cobbled.net [caley01.vpn.cobbled.net] ID-Type= FQDN Name=caley01.vpn.cobbled.net [gw.vpn.cobbled.net] ID-Type= FQDN Name=gw.vpn.cobbled.net [Phase 2] Connections= cobbled-caley [cobbled_net-gw] Phase= 1 Configuration= low-crypto Address= 84.203.180.117 ID= caley01.vpn.cobbled.net Remote-ID= gw.vpn.cobbled.net [cobbled-caley] Phase= 2 ISAKMP-peer=cobbled_net-gw Configuration= low-crypto-quick Local-ID= cobbled_net-caley Remote-ID= cobbled_net-all [cobbled_net-all] ID-Type=IPV4_ADDR_SUBNET Network=10.0.0.0 Netmask=255.0.0.0 [cobbled_net-caley] ID-Type=IPV4_ADDR_SUBNET Network=10.192.0.0 Netmask=255.255.0.0 [min-crypto-quick] DOI= IPSEC EXCHANGE_TYPE= QUICK_MODE Transforms= QM-ESP-DES-MD5-SUITE [low-crypto] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA-RSA_SIG [low-crypto-quick] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Transforms= QM-ESP-3DES-SHA-PFS-SUITE [demime 1.01d removed an attachment of type application/x-gunzip] enable logging to /var/run/isakmpd.pcap by either starting isakmpd with the -L switch or sending the 'p on' command to the isakmpd command pipe (echo 'p on' /var/run/isakmpd.fifo ). Then do a tcpdump -r /var/run/isakmpd.pcap -nvv This will clearly show what parameters are negotiated and with what result the phase 2 negotiation fails. That's my 5 cent regards
WG: Re: isakmp phase 2 negotiation failed
-Urspr|ngliche Nachricht- Von: Christoph Leser Gesendet: Freitag, 21. September 2007 16:44 An: '[EMAIL PROTECTED]' Betreff: Re: isakmp phase 2 negotiation failed w #$OpenBSD: ipsec.conf,v 1.5 2006/09/14 15:10:43 hshoexer Exp $ # # See ipsec.conf(5) for syntax and examples. ike esp from 10.192.0.0/16 to 10.0.0.0/8 \ peer gw.vpn.cobbled.net \ main auth hmac-sha enc 3des-cbc \ quick auth hmac-md5 enc des-cbc \ srcid caley01.vpn.cobbled.net dstid gw.vpn.cobbled.net # isakmpd configuration [General] Listen-on= 83.104.36.71 [X509-Certificates] CA-directory=/etc/isakmpd/ca/ Cert-directory= /etc/isakmpd/certs/ Private-key= /etc/isakmpd/private/local.key [Phase 1] #84.203.180.117= gw.vpn.cobbled.net [caley01.vpn.cobbled.net] ID-Type= FQDN Name=caley01.vpn.cobbled.net [gw.vpn.cobbled.net] ID-Type= FQDN Name=gw.vpn.cobbled.net [Phase 2] Connections= cobbled-caley [cobbled_net-gw] Phase= 1 Configuration= low-crypto Address= 84.203.180.117 ID= caley01.vpn.cobbled.net Remote-ID= gw.vpn.cobbled.net [cobbled-caley] Phase= 2 ISAKMP-peer=cobbled_net-gw Configuration= low-crypto-quick Local-ID= cobbled_net-caley Remote-ID= cobbled_net-all [cobbled_net-all] ID-Type=IPV4_ADDR_SUBNET Network=10.0.0.0 Netmask=255.0.0.0 [cobbled_net-caley] ID-Type=IPV4_ADDR_SUBNET Network=10.192.0.0 Netmask=255.255.0.0 [low-crypto] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA-RSA_SIG [low-crypto-quick] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Transforms= QM-ESP-DES-MD5-SUITE Maybe there is a problem with your isakmpd.conf: The hierachy should be as follows ( that's at least what I read from man isakmpd.conf: Connections lists ipsec-connections: cobbled-caley ipsec-connections names IPsec-configuration: low-crypto-quick IPsec-configuration names Suites QM-ESP-DES-MD5-SUITE !! so maybe it should be [low-crypto-quick] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-DES-MD5-SUITE i.e. transforms is not a valid parameter in the IPsec-configuration section let me know ... regards christoph
aes 256 in ipsec.conf ?
Hi, is AES 256 cipher supported in OBSD 4.1 ipsec implementation? If it is, how can I specify this as input to ipsecctl ( ipsec.conf )? regards Christoph
IPSEC openBSD-LANCOM
Hello, I tried ( and failed ) to set up an IPSEC Tunnel to a LANCOM VPN Router in a somewhat special constellation: main mode is ok quick mode negotiated successfully and established the following flow: # ipsecctl -s flow flow esp in from 172.17.0.0/16 to 172.17.7.50 peer a.b.c.d srcid [EMAIL PROTECTED] dstid [EMAIL PROTECTED] type use flow esp out from 172.17.7.50 to 172.17.0.0/16 peer a.b.c.d srcid [EMAIL PROTECTED] dstid [EMAIL PROTECTED] type require here 172.17.0.0/16 is the private net at the remote site, a.b.c.d is the remote internet address, the ID parmeters of main mode are of type user_fqdn. What is special in the above configuration is that I was asked to use an address from the remote private net range ( 172.17.7.50 ) as my local id parameter in quick mode ( instead of my own local address or local net ). This looks like a typical dial-in setup, where the dial in client is given an address in the remte target network, and the remote router acts as proxy for this address. I do not know whether this is a valid setup for IPSEC, but the person on the remote site told me that he uses this setup for his ( windows ) road worrier clients. If this is valid and can be done on openBSD, what is needed to complete this setup? As shown above, the flow gets established, but ping 172.17.0.1 fails with 'no route to host'. It seems that I'm lacking basic understand of the relationship between 'ipsec flows' and routing. Thanks Christoph
supported internal dsl modem for soekris available ?
hello, I would love to set up a openBSD/soekris based dsl router for accessing the internet from home (my provider is t-com from germany). Can anyone here tell me whether there are internal dsl modem cards available which are supported by openBSD? It would be sad if I had to install an external dsl modem, with yet another external power supply Thanks Christoph
openBSD 3.8 window scaling problem: packets dropped on enc0?
scp from linux to linux via an ipsec tunnel between openBSD gateway and lancom 1611+ router fails( hangs) if tcp window scaling is enabled. This is my setup: Redhat Linux ES3 --- dc0 openBSD IPSEC dc1 internet - lancom 1611+ --- Redhat Linux ES4 RHES3 does scp a.a host:/directory ask for password, and then hangs, given the file is larger that about 1300 bytes. tcpdump on openBSD dc0 and enc0 shows: RHES3 sends SYN with wscale=0, receives SYN with wscale=3 sends and receives some small packets during negotiation sends a first full size packet, which I see on dc0, but not on enc0 and hangs, repeating this first packet. This only happens, when RHES3 is copying data to RHES4. If RHES3 is copying data from RHES4, it works, but very slow. The problem can be worked around by setting net.ipv4.tcp_window_scaling=0 on RHES3, effectively disabling the window scale feature. Is this a known problem? Or possibly caused by some sort of misconfiguration? I will happily provide more details, tcpdumps etc. if you are interested. I found that Stephen Hemminger claims on Linux World Expo Feb. 2005 that openBSD might fail to track state when window scaling is in effect. See http://developer.osdl.org/shemminger/LWE2005_TCP.pdf .
Re: NAT/pf before IPSEC
I tried as suggested and added another flow to the isakmpd.conf. If this isn't mentioned in the connections statement, it will not start with isakmpd, but can be started through the fifo interface to isakmpd using the 'c' command. It works for me, now the packets get routed through enc0 and are properly natted. I took a look at file isakmpd.pcap file and found that this extra flow is indeed negotiated with the remote end. This worries me. I added this flow only to get the routing going and do not want the remote site know about this. Could it be that this negotiation disturbs the other end? Btw. in the netstat -rn output only the 'in' half of this extra flow shows up, not the 'out' part. Strange, I would have expected this the other way. Regards Christoph -Urspr|ngliche Nachricht- Von: Matthew Closson [mailto:[EMAIL PROTECTED] Gesendet: Mi 21.12.2005 19:15 An: Christoph Leser Cc: misc@openbsd.org Betreff: Re: NAT/pf before IPSEC On Wed, 21 Dec 2005, Christoph Leser wrote: Does this imply that I must not mention VPN-2 in the isakmpd.conf Connections statement? Thanks for your help. I tried with and without and didn't get it working either way. I think if you do not include it in your Connections statement then it is irrelevant. You need to specify it in that statement to generate an SPI. From what I've read when packets come in they see if they match an existing SPI to determine if they should be sent to the enc0 interface or not. But like I said I still haven't got it to work so take that with a grain of salt. -Matt- -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Nick Suckling Gesendet: Mittwoch, 21. Dezember 2005 15:32 An: misc@openbsd.org Betreff: Re: NAT/pf before IPSEC No the other side does not need to know about this additional section if you are using NAT as described. Nick On Wed, 2005-12-21 at 14:06 +0100, Christoph Leser wrote: If you add this extra section to your isakmpd.conf, do you need to add it to the remote site too? Does this extra section change the negotiation between the two endpoints. Thanks -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Nick Suckling Gesendet: Mittwoch, 21. Dezember 2005 12:52 An: misc@openbsd.org Betreff: Re: NAT/pf before IPSEC One easier way I have had this working is to add an additional section to your isakmpd.conf. Something like the following. Your NAT then takes care of the rest. [VPN-1] Phase= 2 ISAKMP-peer=remote Configuration= Default-quick-mode Local-ID= ip-10.0.20.254 Remote-ID= network-192.168.60.0/255.255.255.0 [VPN-2] Phase= 2 ISAKMP-peer=remote Configuration= Default-quick-mode Local-ID= network-192.168.20.0/255.255.255.0 Remote-ID= network-192.168.60.0/255.255.255.0 [ip-10.0.20.254] ID-type= IPV4_ADDR Address= 10.0.20.254 [network-192.168.20.0/255.255.255.0] ID-type= IPV4_ADDR_SUBNET Network= 192.168.20.0 Netmask= 255.255.255.0 [network-192.168.60.0/255.255.255.0] ID-type= IPV4_ADDR_SUBNET Network= 192.168.60.0 Netmask= 255.255.255.0 Nick On Wed, 2005-12-21 at 04:09 -0500, Matthew Closson wrote: Hello, I'm running into an issue which was brought up on the list before, the last reference I found was in 2004: http://archive.openbsd.nu/?ml=openbsd-pfa=2004-10m=430206 I have an OpenBSD 3.8 machine. dc0 is an internal NIC assigned 192.168.20.250 fxp0 is an external NIC assigned a.b.c.d public_IP_address 10.0.20.254 is an inet alias on fxp0 192.168.20.0/24 is my internal network. 192.168.20.0/24 | | | 192.168.20.250 - dc0 10.0.20.254 - inet alias on fxp0 a.b.c.d - fxp0 public_IP | | IPSEC Tunnel | | e.f.g.h - public_IP tunnel endpoint 192.168.60.0/24 remote network According to the parameters of the tunnel setup (of which I cannot change) the remote IPSEC tunnel endpoint expects traffic from my network to look like it is coming from 10.0.20.254/32. This works: ping -I 10.0.20.254 192.168.20.10 I get responses back from the pings, now I need to nat my internal network to appear to be coming from 10.0.20.254 So I can do: nat pass on enc0 from 192.168.20.0/24 to 192.168.60.0/24 - 10.0.20.254 And what happens is, packets coming in from the 192.168.20.0/24 network hit my internal NIC, are evaluated for IPSEC routing, are not part of an SPI and are not sent over enc0. This is because IPSEC routing takes place before pf and nat. In the message I linked to above, Cedric said that you can get around this by creating a fake flow into an existing SPI so that your incoming traffic gets routed into enc0
Re: NAT/pf before IPSEC
If you add this extra section to your isakmpd.conf, do you need to add it to the remote site too? Does this extra section change the negotiation between the two endpoints. Thanks -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Nick Suckling Gesendet: Mittwoch, 21. Dezember 2005 12:52 An: misc@openbsd.org Betreff: Re: NAT/pf before IPSEC One easier way I have had this working is to add an additional section to your isakmpd.conf. Something like the following. Your NAT then takes care of the rest. [VPN-1] Phase= 2 ISAKMP-peer=remote Configuration= Default-quick-mode Local-ID= ip-10.0.20.254 Remote-ID= network-192.168.60.0/255.255.255.0 [VPN-2] Phase= 2 ISAKMP-peer=remote Configuration= Default-quick-mode Local-ID= network-192.168.20.0/255.255.255.0 Remote-ID= network-192.168.60.0/255.255.255.0 [ip-10.0.20.254] ID-type= IPV4_ADDR Address= 10.0.20.254 [network-192.168.20.0/255.255.255.0] ID-type= IPV4_ADDR_SUBNET Network= 192.168.20.0 Netmask= 255.255.255.0 [network-192.168.60.0/255.255.255.0] ID-type= IPV4_ADDR_SUBNET Network= 192.168.60.0 Netmask= 255.255.255.0 Nick On Wed, 2005-12-21 at 04:09 -0500, Matthew Closson wrote: Hello, I'm running into an issue which was brought up on the list before, the last reference I found was in 2004: http://archive.openbsd.nu/?ml=openbsd-pfa=2004-10m=430206 I have an OpenBSD 3.8 machine. dc0 is an internal NIC assigned 192.168.20.250 fxp0 is an external NIC assigned a.b.c.d public_IP_address 10.0.20.254 is an inet alias on fxp0 192.168.20.0/24 is my internal network. 192.168.20.0/24 | | | 192.168.20.250 - dc0 10.0.20.254 - inet alias on fxp0 a.b.c.d - fxp0 public_IP | | IPSEC Tunnel | | e.f.g.h - public_IP tunnel endpoint 192.168.60.0/24 remote network According to the parameters of the tunnel setup (of which I cannot change) the remote IPSEC tunnel endpoint expects traffic from my network to look like it is coming from 10.0.20.254/32. This works: ping -I 10.0.20.254 192.168.20.10 I get responses back from the pings, now I need to nat my internal network to appear to be coming from 10.0.20.254 So I can do: nat pass on enc0 from 192.168.20.0/24 to 192.168.60.0/24 - 10.0.20.254 And what happens is, packets coming in from the 192.168.20.0/24 network hit my internal NIC, are evaluated for IPSEC routing, are not part of an SPI and are not sent over enc0. This is because IPSEC routing takes place before pf and nat. In the message I linked to above, Cedric said that you can get around this by creating a fake flow into an existing SPI so that your incoming traffic gets routed into enc0 and then nat'd appropriately. He said you could run this flow from a cron script, I suppose that would run every period of time that your SPI times out. This doesn't seem real solid to me if you need traffic to stay up over your tunnel. If your script doesn't run at the right time, your existing connections over the tunnel are going to fall apart. In another message someone suggested patching isakmpd to modify this behavior. My questions are: Is there a better or newer way of doing NAT before IPSEC routing? Does anyone have a script for adding fake flows to SPI's periodically? Does anyone have a source patch for isakmpd that solves this issue? Any info is much appreciated, I am subscribed to the list. Thanks, -Matt- _ This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com
Re: NAT/pf before IPSEC
Does this imply that I must not mention VPN-2 in the isakmpd.conf Connections statement? Thanks for your help. -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Nick Suckling Gesendet: Mittwoch, 21. Dezember 2005 15:32 An: misc@openbsd.org Betreff: Re: NAT/pf before IPSEC No the other side does not need to know about this additional section if you are using NAT as described. Nick On Wed, 2005-12-21 at 14:06 +0100, Christoph Leser wrote: If you add this extra section to your isakmpd.conf, do you need to add it to the remote site too? Does this extra section change the negotiation between the two endpoints. Thanks -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Nick Suckling Gesendet: Mittwoch, 21. Dezember 2005 12:52 An: misc@openbsd.org Betreff: Re: NAT/pf before IPSEC One easier way I have had this working is to add an additional section to your isakmpd.conf. Something like the following. Your NAT then takes care of the rest. [VPN-1] Phase= 2 ISAKMP-peer=remote Configuration= Default-quick-mode Local-ID= ip-10.0.20.254 Remote-ID= network-192.168.60.0/255.255.255.0 [VPN-2] Phase= 2 ISAKMP-peer=remote Configuration= Default-quick-mode Local-ID= network-192.168.20.0/255.255.255.0 Remote-ID= network-192.168.60.0/255.255.255.0 [ip-10.0.20.254] ID-type= IPV4_ADDR Address= 10.0.20.254 [network-192.168.20.0/255.255.255.0] ID-type= IPV4_ADDR_SUBNET Network= 192.168.20.0 Netmask= 255.255.255.0 [network-192.168.60.0/255.255.255.0] ID-type= IPV4_ADDR_SUBNET Network= 192.168.60.0 Netmask= 255.255.255.0 Nick On Wed, 2005-12-21 at 04:09 -0500, Matthew Closson wrote: Hello, I'm running into an issue which was brought up on the list before, the last reference I found was in 2004: http://archive.openbsd.nu/?ml=openbsd-pfa=2004-10m=430206 I have an OpenBSD 3.8 machine. dc0 is an internal NIC assigned 192.168.20.250 fxp0 is an external NIC assigned a.b.c.d public_IP_address 10.0.20.254 is an inet alias on fxp0 192.168.20.0/24 is my internal network. 192.168.20.0/24 | | | 192.168.20.250 - dc0 10.0.20.254 - inet alias on fxp0 a.b.c.d - fxp0 public_IP | | IPSEC Tunnel | | e.f.g.h - public_IP tunnel endpoint 192.168.60.0/24 remote network According to the parameters of the tunnel setup (of which I cannot change) the remote IPSEC tunnel endpoint expects traffic from my network to look like it is coming from 10.0.20.254/32. This works: ping -I 10.0.20.254 192.168.20.10 I get responses back from the pings, now I need to nat my internal network to appear to be coming from 10.0.20.254 So I can do: nat pass on enc0 from 192.168.20.0/24 to 192.168.60.0/24 - 10.0.20.254 And what happens is, packets coming in from the 192.168.20.0/24 network hit my internal NIC, are evaluated for IPSEC routing, are not part of an SPI and are not sent over enc0. This is because IPSEC routing takes place before pf and nat. In the message I linked to above, Cedric said that you can get around this by creating a fake flow into an existing SPI so that your incoming traffic gets routed into enc0 and then nat'd appropriately. He said you could run this flow from a cron script, I suppose that would run every period of time that your SPI times out. This doesn't seem real solid to me if you need traffic to stay up over your tunnel. If your script doesn't run at the right time, your existing connections over the tunnel are going to fall apart. In another message someone suggested patching isakmpd to modify this behavior. My questions are: Is there a better or newer way of doing NAT before IPSEC routing? Does anyone have a script for adding fake flows to SPI's periodically? Does anyone have a source patch for isakmpd that solves this issue? Any info is much appreciated, I am subscribed to the list. Thanks, -Matt- _ This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com
IKE V1 Vulnerablility 226364
I came across http://www.kb.cert.org/vuls/id/226364 which describes some vulnerablities in IKE Protocol V1 implementations. That page state ( that is at least what I read from it ) that it is unknown whether OpenBSD is affected or not. Is anything known about this issue? Should I care about it ( I use OpenBSD 3.8 ipsec on my gateway ) Thanks
openvpn to ipsec routing question
Hello, the question is about how to route traffic from an openvpn tunnel to an ipsec tunnel. This is my setup: The OpenBSD gateway has an internal (10.0.1.1/24 ) and external (x.x.x.x/30) interface. The internal net is NAT'ed to the external interface to provide internet access to hosts on the internal net. Through the external interface an ipsec SA ( security association ) is established ( tunnel mode ) between my internal net ( 10.0.1/24 ) and another local net of a remote site ( 10.0.2/24 ). So hosts on the internal net can reach hosts on the internet (being NAT'ed ) as well as hosts on the remote private net 10.0.2/24 ( not being NAT'ed ). Now I have setup an openvpn server on this box. This openvpn server gives out addresses from yet another net ( 10.0.3/24 ) to the connected clients. Connections from openvpn clients are NAT'Ed to the internal interface to make them appear as being directly attached to the local private net ( 10.0.1/24 ). So far, it works. Now I want the clients on the openvpn subnet ( 10.0.3/24 ) to get access to the remote side of the ipsec sa ( 10.0.2/24 ). Here is an excerpt of my ipconfig and routing table # ifconfig lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33224 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 fxp0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 address: 00:a0:c9:43:07:20 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255 inet6 fe80::2a0:c9ff:fe43:720%fxp0 prefixlen 64 scopeid 0x1 fxp1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 address: 00:a0:c9:30:b3:34 media: Ethernet autoselect (10baseT) status: active inet x.x.x.254 netmask 0xfffc broadcast x.x.x.255 inet6 fe80::2a0:c9ff:fe30:b334%fxp1 prefixlen 64 scopeid 0x2 pflog0: flags=141UP,RUNNING,PROMISC mtu 33224 pfsync0: flags=0 mtu 2020 enc0: flags=0 mtu 1536 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500 inet 10.0.3.1 -- 10.0.3.2 netmask 0x # netstat -rn Routing tables Internet: DestinationGatewayFlags Refs UseMtu Interface defaultx.x.x.254 UGS11 1211734 - fxp1 10.0.3/24 10.0.3.2 UGS 031900 - tun0 10.0.3.2 10.0.3.1 UH 10 - tun0 x.x.x.x/30 link#2 UC 10 - fxp1 127/8 127.0.0.1 UGRS00 33224 lo0 127.0.0.1 127.0.0.1 UH 1 392 33224 lo0 10.0.1/24 link#1 UC 110 - fxp0 224/4 127.0.0.1 URS 00 33224 lo0 Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 10.0.2/24 0 10.0.1/24 0 0 y.y.y.y/50/use/in 10.0.1/24 0 10.0.2/24 0 0 y.y.y.y/50/require/out where x.x.x.x is the external address of my box, y.y.y.y is the external address of the remote side of the ipsec tunnel. I expected this to be sufficient for the routing from 10.0.3/24 to 10.0.2/24. But it is not. Using tcpdump I see that packets entering the gateway via the openvpn tun0 interface destined to some host on 10.0.2/24 do not get routed to the ipsec tunnel but are routed directly to the external interface, i.e. a packet with source ip = 10.0.3.10 and destination ip 10.0.2.1 is routed as is to the external interface. I assume that the route through the IPSEC SA is not taken into account, as the packet to be routed is not from the internal interface. If there were a way to source-nat the packet when it comes in via the tun interface, i.e. before the routing is done, maybe all would be fine. But I don't know a way to achieve this. The straight forward solution to setup another ipsec tunnel between 10.0.2/24 and 10.0.3/24 is out of reach due to weird administrative constraints. Any suggestions? Thanks Christoph
