Re: pf anchors attached to irrelevant states
On 5/19/24 13:37, Stuart Henderson wrote: I can confirm this is a problem, definitely seen in 7.4, I can't remember if 7.3 was affected. 7.2 from Dec 22 seems ok. Yes, 7.3 is affected. It is the same problem reported here: https://marc.info/?l=openbsd-misc&m=168754952806369
Re: lcamtuf on the recent xz debacle
On 4/4/24 23:17, Katherine Mcmillan wrote: an open source data compression utility available on almost all installations of Linux and other Unix-like operating systems." There are a couple of problems with this statement, but I just want to focus in on the "almost all installations of Linux and other Unix-like operating systems" part. The statement reads "available on almost all ...", which is correct, as far as I can tell. But yes, the backdoor code in the version that was discovered seems to have targeted only Linux.
Re: Bridging firewall with online update/upgrade
On 4/3/24 18:19, Karel Lucas wrote: I want to use ETH1 for the input from my ADSL modem, ETH2 and ETH3 for the output to my network. Furthermore, I would like to use ETH4 for the update/upgrade of the firewall. Remove the connection from ETH1, plug it into ETH4, and update/upgrade. Then the connection returns to ETH1. ETH4 therefore receives an IP address and ETH1,ETH2 and ETH3 not. But now the problem: as long as the network connection of the ADSL modem is in ETH4, my network, including the firewall, is no longer secured, and attackers can take advantage. I therefore wonder whether it is possible to let the data flow via ETH1 and ETH4 first pass through PF before an update/upgrade is done via ETH4. This means that the bridging firewall will have two entrances, one without and one with an IP address. I would like to know if that is possible, or if there is another option. I'm not entirely sure about how bridging works on OpenBSD and PF, but the answer, from a network point of view, would be "Don't make ETH4 part of the same bridge as ETH1-3, and apply a basic, restrictive ruleset to ETH4, allowing only for the update traffic to/from $self". (I hope I'm not missing something basic here)
Re: can't find PID
I have asked myself the same question. When runninng tcpdump -n -i pflog0 with the -e -v flags (and only in that combination), it outputs tuples that looks like they should be a uid and pid: 16:40:47.110033 rule 2/(match) [uid 0, pid 92257] block in on trunk0: ... (it's 92257 on the machine this example is from, but is different on other machines) The pid that "pid" references does not show up in any invocation of ps (-A, -a, -H, -k). It's also not mentioned in tcpdump[8]. pflog[4] does mention a uid_t uid and pid_t pid field in the pfloghdr struct, but does not say where the values come from. When I reload the pf ruleset with pfctl, the number in the pid field changes. So my assumption is that it is the pid of the pfctl process that inserted the rule. Is that correct? thx /m On 3/5/24 15:45, Theo de Raadt wrote: What are you expecting here?? ofthecentury wrote: Yes, I'm tcdupming pflog and ALL my dropped packets reference some PID 6504 that is not found among the processes that are running.
Re: Open-source security processor
On 9/8/23 00:24, Richard Thornton wrote: Say you had the guts of an x86_64 desktop running Windows on the bench and another computer running OpenBSD right next to it, is there some mechanism available that could allow you to integrity scan the NVMe drive (and also the firmware but that's probably an easier problem solved with something like SPI) of the powered-off x86_64 with the OpenBSD box, like a hardware device that allows both OpenBSD and the laptop physical hardware level access to the same NVMe, or would you have the NVMe in OpenBSD, scan it and then somehow "hand over" the NVMe to Windows? The NVMe drive can't be physically touched, not just swapped from board to board, I'm thinking of this from a more "embedded" viewpoint. If you think about a forensic analysis and/or integrity check of the *contents* of the NVMe, you should draw a binary image of the disk and analyze that. If you cannot remove the disk, but boot the system from an external device (into whatever OS you prefer), you could create such a copy from there (dd is your friend). You could also analyze the disk directly from there, but there's a high probability that you will modify it by doing so (in case you have to mount the filesystems). If you cannot boot the system from an external device (because it is eg. in a hibernated state that you need to preserve), I don't think there is much you can do without removing the disk from the computer. /m
Re: IP6 redirects through relayd no longer working reliably
Just for the record: The problem was caused by a malfunctioning upstream gateway, which did no longer respond properly to neighbor solicitation requests. The SYN ACK from the server was dropped because the firewall had already removed the state created by the SYN. On 6/23/23 22:51, Markus Wernig wrote: pflog shows that the IPv6 SYN-ACK replies from the backend servers are being dropped by pf. But weirdly the blocks are logged over 30 seconds after the SYN is allowed through:
IP6 redirects through relayd no longer working reliably
Hi all
(Sorry for flooding, this seems related to the question I asked earlier.
Please bear with me.)
I am using relayd on 7.3-release as an IP loadbalancer in front of some
dualstack backend hosts. This setup has worked for some years now.
After upgrading to 7.3 about 4 weeks ago I noticed a steady decline of
IPv6 sessions coming into the backend servers, up to the point where
none arrive at all (for 2 days now).
Now users start complaining that their connections to the servers
(public IP) are either timing out or are established only after a very
long time (usually the tcp start timeout when the client switches from
IPv6 to trying IPv4). The IPv4 connections succeed immediately.
pflog shows that the IPv6 SYN-ACK replies from the backend servers are
being dropped by pf. But weirdly the blocks are logged over 30 seconds
after the SYN is allowed through:
Jun 20 14:12:49.489707 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50210 > [Server.IP6].443:
S 2508622700:2508622700(0) win 64800 <[|tcp]> [flowlabel 0xd4400] (len
32, hlim 52)
Jun 20 14:12:49.493267 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50211 > [Server.IP6].443:
S 806421981:806421981(0) win 64800 <[|tcp]> [flowlabel 0x162e5] (len 32,
hlim 52)
Jun 20 14:12:49.507508 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50212 > [Server.IP6].443:
S 3945655871:3945655871(0) win 64800 <[|tcp]> [flowlabel 0x8abc6] (len
32, hlim 52)
Jun 20 14:12:49.517783 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50213 > [Server.IP6].443: S 1191028748:1191028748(0)
win 64800 <[|tcp]> [flowlabel 0xa7d6] (len 32, hlim 52)
Jun 20 14:13:20.943370 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50213: S 3650589557:3650589557(0)
ack 209077342 win 64800 <[|tcp]> [flowlabel 0xd922c] (len 32, hlim 64)
Jun 20 14:13:20.943433 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50212: S 2068945110:2068945110(0)
ack 2313561433 win 64800 <[|tcp]> [flowlabel 0xf8c9c] (len 32, hlim 64)
Jun 20 14:13:20.943476 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50211: S 3395939328:3395939328(0)
ack 1849611325 win 64800 <[|tcp]> [flowlabel 0xb519e] (len 32, hlim 64)
Jun 20 14:13:20.943518 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50210: S 106368970:106368970(0)
ack 1534267447 win 64800 <[|tcp]> [flowlabel 0xca19a] (len 32, hlim 64)
(The rule 2 that is logged is the rule number of the relayd/* anchor.)
tcpdump on vlanX shows the backend server sends the SYN-ACK immediately.
The IPv4 addresses are natted from public to rfc-1918 space and work.
For IPv6, the address of backend server.A is used as the public IP
(service.pub). Only if server.A becomes unavailable, are packets
redirected to server.B.
relayd.conf:
...
table {
Server.A.IP6 retry 2
}
table {
Server.B.IP6 retry 2
}
redirect "service.pub.80.v6" {
listen on Server.A.IP6 tcp port 80 interface trunk0
forward to port 80 \
check http "/" host "server.A" code 200
forward to port 80 \
check http "/" host "server.B" code 200
}
redirect "service.pub.443.v6" {
listen on Server.A.IP6 tcp port 443 interface trunk0
forward to port 443 \
check https "/" host "server.A" code 200
forward to port 443 \
check https "/" host "server.B" code 200
}
I am not 100% sure that the IPv6 failover actually worked before, but
the connections to Server.A.IP6 were definitely working.
I do see the http and https checks succeed on both backend servers.
I've tried flushing the states and rebooting the firewall, to no avail.
relayctl shows all redirects/tables as active and all hosts as up:
2 redirectservice.pub.80.v6 active
3 table server.A:80active (1 hosts)
3 hostServer.A.IP6 100.00% up
4 table server.B:80active (1 hosts)
4 hostServer.B.IP6 100.00% up
3 redirectservice.pub.443.v6 active
5 table server.A:443 active (1 hosts)
5 hostServer.A.IP6 100.00% up
6 table server.B:443 active (1 hosts)
6 hostServer.B.IP6 100.00% up
Now I'm out of ideas on how to debug this further.
Has anyone been experiencing something similar?
Has something fundamental changed in relayd or pf that could cause this?
Does anybody spot an error in my configuration?
Thanks for any pointer!
Best regards
Markus
All packets logged with relayd/* anchor rule number
Hi all I am using relayd on 7.3-release as an incoming IP loadbalancer and therefore have this line near the beginning of the filter section of pf.conf: anchor "relayd/*" It shows up as rule number 2 in pfctl -vv -s rules: @0 match all scrub (no-df reassemble tcp) [ Evaluations: 89452 Packets: 545363Bytes: 161423157 States: 1772 ] [ Inserted: uid 0 pid 59061 State Creations: 0 ] @1 match out all scrub (random-id) [ Evaluations: 89452 Packets: 295160Bytes: 98671558 States: 921 ] [ Inserted: uid 0 pid 59061 State Creations: 0 ] @2 anchor "relayd/*" all [ Evaluations: 89452 Packets: 576068Bytes: 163171696 States: 1772 ] [ Inserted: uid 0 pid 59061 State Creations: 58739 ] But now all packets get logged with rule no. 2 in pflog, regardless of whether or not they match any relayd redirect. Here's an example of an outgoing natted NTP query, which has nothing whatsoever to do with the relayd rules/redirects: # tcpdump -e -vvv -ttt -n -i pflog0 port ntp Jun 23 20:07:56.377848 rule 2/(match) [uid 0, pid 59061] pass in on vlanX: 192.168.x.y.123 > a.b.c.d.123: v4 client strat 2 poll 10 prec -24 dist 0.006881 disp 0.034591 ref a.b.c.d@3896531217.384170621 orig 3896531389.381188988 [|ntp] (DF) [tos 0xb8] (ttl 64, id 1236, len 76) Jun 23 20:07:56.377928 rule 2/(match) [uid 0, pid 59061] pass out on trunk0: [rewritten: src n.m.p.o:55798, dst a.b.c.d:123] 192.168.x.y.123 > a.b.c.d.123: v4 client strat 2 poll 10 prec -24 dist 0.006881 disp 0.034591 ref a.b.c.d@3896531217.384170621 orig 3896531389.381188988 [|ntp] [tos 0xb8] (ttl 63, id 1236, len 76, bad ip cksum dd99! -> de99) Is this the expected behaviour? Is there any way to get the actual rule numbers back? I am quite sure this was different in earlier releases. Thank you in advance Markus
Re: carp status master on both firewalls
for my external carp interface both firewalls show master as status
The config is below for reference:
/etc/hostname.carp0 on fw1
inet x.x.x.114 255.255.255.240 x.x.x.127 vhid 40 carpdev em2 pass password
advskew 1
inet alias x.x.x.115 0xfff0
inet alias x.x.x.116 0xfff0
/etc/hostname.carp0 on fw2
inet x.x.x.114 255.255.255.240 x.x.x.127 vhid 40 carpdev em0 pass password advskew 128
inet alias x.x.x.115 0xfff0
inet alias x.x.x.116 0xfff0
On both firewalls I have added the following in /etc/pf.conf:
pass on { $ext_if $int_if } proto carp keep state (no-sync)
Did anyone already encounter this issue or has any idea what might be wrong?
Hard to tell without logs. Some things that come to mind:
- Do the two fw actually have a link on their carp0 carpdev interfaces?
If both are master, both should be sending out CARP advertisements, so
I'd try to run tcpdump on both external interfaces and look for those:
tcpdump -n -e -i carp0 proto carp
- Did you enable CARP preemption? Try setting these via sysctl:
net.inet.carp.preempt=1
net.inet.carp.log=3
- In your config one fw has carpdev em2, the other carpdev em0. Could be
OK, or could be an error.
Re: redirection puzzle
On 12/2/22 16:17, rsyk...@disroot.org wrote: echo 1 | tee $(tty) | sed 's/1/2/' Not 100% sure, but probably some timing/subshell issue. This works: tty=$(tty) && echo 1 | tee $tty | sed 's/1/2/' best /m
Re: calling all PFsync users for experience, gotchas, feedback, tips and tricks
Hi Tom On 5/11/22 21:32, Tom Smyth wrote: We are updating some course material for an upcoming PF firewall course, and I would like to put a call out to those who use PFsync in a redundant firewall cluster The one thing that immediately comes to mind is to NOT use a crossover cable for the pfsync connection (even though that seems to be kind of recommended in the pfsync(4) man page). Doing so will lead to a change of the other firewall's carp demotion counter on its pfsync interface if one peer is rebooted or shut down (and thus causing a link down event on the cabled interface on the other side). It also gives you three chained single points of failure at the same time (nic1, cable, nic2), which I would rather avoid (do the math). I do of course agree with the intention of the suggestion (only run pfsync over a secure link). Since I am in the position where I only run my PF firewalls in a trusted environment, where I also control the switches (no shared cloud etc. infrastructure), I have found that running pfsync over a dedicated VLAN interface on a pair of trunk(4)ed NICs on 2 trusted switches sufficiently satisfies that requirement. Best, Markus
Re: (bug?) relayd forward to directives interfering
On 11.08.21 08:40, Vladimir Nikishkin wrote:
> table { 127.0.0.1 }
> table { 127.0.0.1 }
Have you tried having the two backend listeners on different IP
addresses rather than on different ports? Eg. 127.0.0.1 and 127.0.0.2?
best /m
Re: Why demotion counter for group carp is set to 33 on boot?
On 7/13/21 9:32 AM, Tom K wrote: > why demotion counter for group carp is set to 33 on boot? This is the > primary firewall and there are no adskew settings in all hostname.carpX > files or anywhere else. > Because of this the other firewall which should be normaly the standby > (adskew 100), is always MASTER (comes up with carp demote count 0). I remember similar symptoms when some of my vlan interfaces were blocking carp traffic. I think I had to add an according rule for every interface like this: pass quick on vlan230 inet proto carp from any to any keep state (no-sync) In another case one of the interfaces on the master was misconfigured (some typo in hostname.if). Maybe setting net.inet.carp.log=3 also shows more info. best /m
Re: rad daemon strange error message
On 6/30/21 1:32 PM, Pierre Dupond wrote: > veteher30 has no IPv6 link-local address, ignoring ^ I don't know rad, but from the output above there seems to be a typo in some config.
Re: IPv6 NDP Confusion with PF enabled
On 3/8/21 11:05 PM, Antonino Sidoti wrote: > There is no blocking showing up when I examine the pflog0, I would run tcpdump -n -i em0 icmp6 during /etc/netstart with and without pf enabled. If you see a difference, that should help you find out what to allow in your ruleset. /m
Re: seeing carp interface state change for unknown reason ; cluestick hunting
On 2/7/21 1:38 AM, Bryan Stenson wrote: 31 RTM_IFINFO: iface status change: len 168, if# 3, name cnmac2, link: no carrier, mtu: 1500, Just grasping for something here...my next steps are to swap this unit out with the other one (to try and eliminate hardware failure of THIS unit). Any other suggestions? Check the switch interface for any errors and messages.
Re: OpenBSD VM creation problem
On 1/23/21 3:25 AM, Hakan E. Duran wrote: I have a few VMs on KVM/QEMU infrastructure. When I try to create an OpenBSD VM, my key strokes start echoing on the VM console. Not sure if this is the same problem, but I did have similar trouble with qemu and OpenBSD in the past. I had to disable mpbios and acpimadt in the kernel to make it work. See boot_config(8). From my notes from back then I also explicitly enabled acpi and ioapic, but I can't remember why ... best /markus
Re: auto-boot
On 1/20/21 10:01 AM, Bastien Durel wrote: If There is no software way to solve this problem, I shall need to buy a small HDMI screen and drop serial console ... If the console gets input from the serial port even with no cable plugged into it (and not just the other side disconnected), there's most likely something wrong with the port. Either it's malfunctioning on the electrical level, or some strange mode is set in the BIOS. best /m
Re: question about hostname.carp
On 11/4/20 4:05 PM, Harald Dunkel wrote: inet 10.0.1.1 0xff00 NONE vhid 41 pass secret carpdev em1 advbase 1 advskew 0 If you use the actual broadcast address 10.0.1.255 instead on NONE it will work with both.
Re: Encrypted notepad software suggestions
On 9/28/20 4:54 PM, William Orr wrote: > https://vim.fandom.com/wiki/Encryption That post is from 2001 (still valid, though). Vim from the current package defaults to blowfish2 as encryption algorithm. best /m
Re: Encrypted notepad software suggestions
On 9/28/20 9:18 AM, Martin wrote: > I'm looking for some notepad with encryption of notes/files created. Simply > Text File encryption is suitable too to hide some info from plain text files > I have. Depending on your definition of "notepad", vim (gvim) should have built-in encryption (:X command), at least it does on Linux. best /m
Re: Routing and forwarding: directly connected computers
On 9/3/20 5:41 PM, Ernest Stewart wrote: > And which pf rules and how to establish those routing tables are exactly what > I'm asking. Maybe if you share the output of the ping test from your original mail we could see what is actually happening. >From your setup I would assume that the IP addresses the hosts are using for the ping are not what you expect. best /m
Re: pfsync interface in carp group
On 6/9/20 9:25 PM, Paul B. Henson wrote: > Hmm, I had never considered using jumbo frames. ... > I guess multicast would work too Neither jumbo frames nor multicast will prevent group demotion when the other side of a crosslink cable goes physically down. Only not having the sync interface in the carp group will.
Re: pfsync interface in carp group
On 6/9/20 12:27 AM, Paul B. Henson wrote: > Yes, I am using a direct link between the two physical firewalls. [...] > Is this no longer a best practice? If it's in the documentation, I suppose it still is. But I have found it problematic, because taking down one firewall, or even only its sync interface, will automatically demote the sync interface on the other one, which then will affect the whole carp group, if the interface is part of that group. When I first tried carp in the lab many, many years ago, I vaguely remember seeing effects similar to what you describe, and have used switched sync interfaces ever since.
Re: pfsync interface in carp group
On 6/8/20 12:29 AM, Paul B. Henson wrote: > whenever I rebooted the secondary firewall, the > carp interfaces on the primary would flip to backup and then back to > master as the secondary one rebooted I don't see that behaviour on my carp pair. Are you using a cross-link cable between the two firewalls? (You shouldn't, in my experience.) best
Re: Select ssh key from ssh-agent?
On 5/24/20 3:55 AM, David A. Pocock wrote: > I can't relate; doing this from OpenBSD6.7 to OpenBSD6.7 the ecdsa forward > through and show up via ssh-add without any issues (and allow using the > intermediary host without having the keys present (and being able to choose > keys as per the initial question). If you want to use a specific agent-forwarded key on the intermediary host, you can put the public key (sic!) in a file on the intermediary host and use that file with the -i option or in the config file. The private key for doing the signature during authentication is then automatically selected from the agent. /m
Re: Strange behavior when I try to use lladdr
On 5/22/20 12:12 PM, Денис Давыдов wrote: > I decided to reinstall OpenBSD to a newer version on my VMware ESXi > cluster. So I deleted an old router and start the new one using the old > configuration, except that I add lladdr parameter with the old MAC address Last I looked into it (some years ago) VMware did not allow to manually set the adapter MAC address in the guest to addresses from some hardcoded ranges, among which the VMware OUI 00:50:56. According to [1] this is still the case today, they also specify the range there that can be used. > Now if I will stop tcpdump on terminal[2] I'll get packet loss again. > This is a weird behavior. What could be wrong? tcpdump by default puts the interface in promiscuous mode, which is why it picked up frames not addressed to the lladr you set, but also to 00:50:56:92:d1:18, which seems to be the MAC that VMware has assigned to the adapter. /m [1] https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.troubleshooting.doc/GUID-7F723748-E7B8-48B9-A773-3822C514684B.html
Re: pfsync on VLAN - supported ?
On 14.11.2019 11:30, Rachel Roch wrote: >>> Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan >>> interface for pfsync ? I have had pfsync running happily over a vlan interface for years, never a problem. > Regarding the extra port, in my case I'm using that for LACP (my switches > support distributed LACP, so i can have two cables going into two switches) Having the sync port physically redundant and connected to a switch is a very good idea, because a crossover cable will cause a carp demote whenever the other firewall goes down or is rebooted, afair. best /m
Re: random packet drops with syncookies/synproxy
On 09.11.2019 15:24, Claudio Jeker wrote: >> So nobody is using syncookies/synproxy at all? > > I guess that is a reasonably safe assumption. syncookies are rather new > and probably need more battle testing. OK, then I will send a bug report. > synproxy never helped me much in > case of a SYN attack since it will cause pf(4) to hit the state limit no > matter what you do and then stuff starts to break. Yes, synproxy will not help with that, but syncookies should. But the syncookies entry in the man page also states that a connection opened via syncookie will then run through synproxy, so the problem I'm seeing might be in either one. best /
Re: random packet drops with syncookies/synproxy
Hm, also no replies to that one :-) On 11/6/19 8:15 PM, Markus Wernig wrote: > So just to make sure: Is anybody using syncookies and/or synproxy in > production in a similar setup? So nobody is using syncookies/synproxy at all? best /m
Re: random packet drops with syncookies/synproxy
Hi again Nobody has answered, so I suppose nobody else has this problem :-) That's good. So just to make sure: Is anybody using syncookies and/or synproxy in production in a similar setup? Thx /markus On 11/4/19 8:35 PM, Markus Wernig wrote: > Hi all > > After being hit by some synflood waves recently I enabled syncookies on > our OBSD 6.6 i386 CARP fw pair: > > set syncookies always > > This stopped the state table from filling up. But after some hours pf > started (randomly?) dropping legitimate connection attempts, both on > external->internal (dst-natted) and on internal->internal (not natted) > connections (TCP only, afaict). > > Looking at pflog and the rule number that blocked the packet, it seems > that the preceding "pass quick" rules matching the packets were ignored. > > The packets that were dropped were the ACK ones, so the SYN-SYNACK seems > to have taken place. The client then usually retransmitted the ACK, > which kept being dropped for ca. 15-20 seconds, after which time it was > suddenly accepted and the connection established. Many times also only > the first ACK was dropped, and the first retransmit was accepted. > > So I disabled syncookies and set the relevant ~5 external->internal > rules to synproxy state. > > With that, the same behaviour happened within a few minutes. > > During that time pfctl -vsi showed the "synproxy" counter increasing by > multiple thousands per second (sic), while the state table entries > remained stable around 500 (their normal value). > > So I disabled the synproxy state again, but reloading the rules with > pfctl was not enough, I had to reboot both boxes to stop them from > dropping legitimate connections. With both syncookies and synproxy > disabled, the problem does not occur. > > Is anybody aware of anything that could trigger this behaviour? Or have > any hint where I could look further? I have all the log files if more > info is needed. > > thx /markus > > (btw. the behaviour was the same on 6.5) >
random packet drops with syncookies/synproxy
Hi all After being hit by some synflood waves recently I enabled syncookies on our OBSD 6.6 i386 CARP fw pair: set syncookies always This stopped the state table from filling up. But after some hours pf started (randomly?) dropping legitimate connection attempts, both on external->internal (dst-natted) and on internal->internal (not natted) connections (TCP only, afaict). Looking at pflog and the rule number that blocked the packet, it seems that the preceding "pass quick" rules matching the packets were ignored. The packets that were dropped were the ACK ones, so the SYN-SYNACK seems to have taken place. The client then usually retransmitted the ACK, which kept being dropped for ca. 15-20 seconds, after which time it was suddenly accepted and the connection established. Many times also only the first ACK was dropped, and the first retransmit was accepted. So I disabled syncookies and set the relevant ~5 external->internal rules to synproxy state. With that, the same behaviour happened within a few minutes. During that time pfctl -vsi showed the "synproxy" counter increasing by multiple thousands per second (sic), while the state table entries remained stable around 500 (their normal value). So I disabled the synproxy state again, but reloading the rules with pfctl was not enough, I had to reboot both boxes to stop them from dropping legitimate connections. With both syncookies and synproxy disabled, the problem does not occur. Is anybody aware of anything that could trigger this behaviour? Or have any hint where I could look further? I have all the log files if more info is needed. thx /markus (btw. the behaviour was the same on 6.5)
pf dropping fragmented UDP despite of scrub no-df
Hi all I have this at the beginning of pf.conf: match all scrub (reassemble tcp no-df ) match out all scrub (random-id) Behind that FW is a (OpenIndiana) DNS server that fragments those of its UDP replies that are too large for the local MTU (1500). (Log below is from a DNSKEY query, the failure of which results in DNSSEC validation failing.) The server also sets the DF bit on the fragmented packets ... The external IP dns1-external.domain.tld is natted on the firewall to dns1-internal.domain.tld. The fragmented replies reach the internal firewall interface, but never go out again. There is a log entry for both fragments of the reply packets (even though the rule is set to not log), and no further notice. I thought that with the no-df scrub option this should no longer happen ... I must be missing something, but what? I've bumped my head into this too long now, maybe somebody spots what I can't. (FWIW: The same query over IPv6 (no nat - the server is dual-stack) works, but then the requesting client has issues with reassembling the packets :-[) tcpdump on internal interface: 13:23:09.374991 72.13.58.105.44267 > dns1-internal.domain.tld.domain: [udp sum ok] 47368 [1au] DNSKEY? domain.tld. ar: . OPT UDPsize=4096 DO (36) (ttl 46, id 38692, len 64) 13:23:09.376370 dns1-internal.domain.tld.domain > 72.13.58.105.44267: 47368*- q: DNSKEY? domain.tld. 5/0/1 domain.tld. DNSKEY[|domain] (frag 7478:1480@0+) (DF) (ttl 255, len 1500) 13:23:09.376377 dns1-internal.domain.tld > 72.13.58.105: (frag 7478:110@1480) (DF) (ttl 255, len 130) 13:23:14.380440 72.13.58.105.44267 > dns1-internal.domain.tld.domain: [udp sum ok] 47368 [1au] DNSKEY? domain.tld. ar: . OPT UDPsize=4096 DO (36) (ttl 46, id 53971, len 64) ... tcpdump on pflog0 (the matching rule is set to not log): Dec 04 13:23:09.376397 rule def/(fragment) [uid 0, pid 0] pass in on vlan210: [uid 4294967295, pid 10] dns1-internal.domain.tld.domain > 72.13.58.105.44267: 47368*- q: DNSKEY? domain.tld. 5/0/1 domain.tld.[|domain] (frag 7478:1480@0+) (DF) (ttl 255, len 1500) Dec 04 13:23:09.376413 rule def/(fragment) [uid 0, pid 0] pass in on vlan210: [uid 4294967295, pid 10] dns1-internal.domain.tld > 72.13.58.105: (frag 7478:110@1480) (DF) (ttl 255, len 130) Dec 04 13:23:14.381860 rule def/(fragment) [uid 0, pid 0] pass in on vlan210: [uid 4294967295, pid 10] dns1-internal.domain.tld.domain > 72.13.58.105.44267: 47368*- q: DNSKEY? domain.tld. 5/0/1 domain.tld.[|domain] (frag 7491:1480@0+) (DF) (ttl 255, len 1500) ... tcpdump on external interface: 13:23:09.374546 72.13.58.105.44267 > dns1-external.domain.tld.domain: [udp sum ok] 47368 [1au] DNSKEY? domain.tld. ar: . OPT UDPsize=4096 DO (36) (ttl 46, id 38692, len 64) 13:23:14.380013 72.13.58.105.44267 > dns1-external.domain.tld.domain: [udp sum ok] 47368 [1au] DNSKEY? domain.tld. ar: . OPT UDPsize=4096 DO (36) (ttl 46, id 53971, len 64) ... Thx /markus
Re: Does pf's Sources table ever get cleared?
On 03.08.2017 06:42, Emille Blanc wrote: > 005: RELIABILITY FIX: May 6, 2017 > Expired pf source tracking entries never got removed, leading to memory > exhaustion. > ref: https://www.openbsd.org/errata61.html Thanks for the pointer! Problem gone after running syspatch (such a cool tool!). /m
Re: Does pf's Sources table ever get cleared?
On 02.08.2017 16:07, Steve Williams wrote: > pfctl -t Sources -T flush Thanks for the hints. The above yields an error here: # pfctl -t Sources -T flush pfctl: Table does not exist. pfctl(8) is rather clear on the topic: ... -F modifier Flush the filter parameters specified by modifier (may be abbreviated): ... -F SourcesFlush the source tracking table. The problem appears to be not so much with dynamic tables, but with the way src-nodes are expired (but not flushed). best /markus
Re: Does pf's Sources table ever get cleared?
There does seem to be a timer that is set to expire, but it does not
seem to work:
# pfctl -s Sources -vv
...
a.b.c.d ( states 0, connections 0, rate 0.0/0s )
age 11:41:50, expires in 00:00:00, 33 pkts, 11524 bytes, rule 582
e.f.g.h ( states 0, connections 0, rate 0.0/0s )
age 12:24:25, expires in 00:00:00, 320 pkts, 110512 bytes, rule 582
i.j.k.l ( states 0, connections 0, rate 0.0/0s )
age 10:03:11, expires in 00:00:00, 2 pkts, 80 bytes, rule 591
m.n.o.p ( states 0, connections 0, rate 0.0/0s )
age 10:55:49, expires in 00:00:00, 2 pkts, 80 bytes, rule 591
Could this be a bug?
best markus
On 01.08.2017 17:34, Markus Wernig wrote:
> Hi all
>
> I have a pair of OBSD 6.1 firewalls, on which some rules require source
> tracking, i.e. have a max-src-conn or similar statement as in:
>
> pass log quick on { em0 vlan1 } inet proto tcp from any to
> port { 80, 443 } modulate state ( max-src-conn 50,
> max-src-conn-rate 25/5, overload flush global )
>
> This works perfectly, any hosts that surpass that limit get blocked.
>
> But on the other hand, the Sources table (as seen with pfctl -s Sources)
> keeps growing. With every allowed connection, there are two new entries.
> And it seems that the Sources table expands in one direction only. I.e.
> even long after the relative connection has been flushed from the state
> table, there are still the entries in the Sources table.
>
> No matter what happens, the Sources keep expanding until the src-nodes
> hard limit is reached. At which point only a reboot will help.
>
> I've tried to flush them with pfctl -F Sources, but without success:
>
> wall0101 # pfctl -s Sources | wc -l
> 512
> wall0101 # pfctl -F Sources
> source tracking entries cleared
> wall0101 # pfctl -s Sources | wc -l
> 514
>
> Is there any reason (presumably in my ruleset, but didn't find it) that
> would keep entries in the Sources table from being cleared?
> Shouldn't the tracking entries be removed when the corresponding states
> are flushed and shouldn't pfctl -F Sources clear the Sources table?
>
> Thx /markus
>
Does pf's Sources table ever get cleared?
Hi all
I have a pair of OBSD 6.1 firewalls, on which some rules require source
tracking, i.e. have a max-src-conn or similar statement as in:
pass log quick on { em0 vlan1 } inet proto tcp from any to
port { 80, 443 } modulate state ( max-src-conn 50,
max-src-conn-rate 25/5, overload flush global )
This works perfectly, any hosts that surpass that limit get blocked.
But on the other hand, the Sources table (as seen with pfctl -s Sources)
keeps growing. With every allowed connection, there are two new entries.
And it seems that the Sources table expands in one direction only. I.e.
even long after the relative connection has been flushed from the state
table, there are still the entries in the Sources table.
No matter what happens, the Sources keep expanding until the src-nodes
hard limit is reached. At which point only a reboot will help.
I've tried to flush them with pfctl -F Sources, but without success:
wall0101 # pfctl -s Sources | wc -l
512
wall0101 # pfctl -F Sources
source tracking entries cleared
wall0101 # pfctl -s Sources | wc -l
514
Is there any reason (presumably in my ruleset, but didn't find it) that
would keep entries in the Sources table from being cleared?
Shouldn't the tracking entries be removed when the corresponding states
are flushed and shouldn't pfctl -F Sources clear the Sources table?
Thx /markus
Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)
On 06/09/2016 08:03 PM, Bryan Vyhmeister wrote: > On Thu, Jun 9, 2016, at 10:48 AM, Markus Wernig wrote: >> Short question: >> How do I prevent pf from changing the source port of outgoing natted udp >> packets? > > Did you look at static-port in pf.conf(5)? Argh! I had overlooked that. Shame. Works now. Thanks! /m
pf changes port on udp nat-to and rdr-to reply packets (RTP stream)
Hi all
I have a strange behaviour in pf on 5.9-stable:
A system (asterisk) behind the gateway is receiving and replying to udp
streams (RTP). The connection parameters (src/dst ip/port) are set up
before (STUN and SIP), so both systems "know" where to send to.
The gateway does NAT (rdr-to in, nat-to out) for the system. But while
incoming packets are forwarded with source and destination port
unchanged, the source port on the outgoing packets is changed (to
something in the >5 range). This breaks the connection, as the
external system (resp. the firewall it is behind) expects the packets to
have the original dst port as src port.
The same happens when the system starts a udp stream on its own - the
source port gets rewritten. Also the UDP checksum appears to be wrong
after the NAT.
Short question:
How do I prevent pf from changing the source port of outgoing natted udp
packets?
Long question:
tcpdump:
$int_if:
18:40:21.392468 $int_server_ip.10442 > $external_system.5012: [udp sum
ok] udp 32 (DF) (ttl 64, id 64912, len 60)
18:40:21.396091 $external_system.5012 > $int_server_ip.10442: [bad udp
cksum a9e7! -> 316d] udp 32 (ttl 115, id 9052, len 60)
18:40:21.413332 $int_server_ip.10442 > $external_system.5012: [udp sum
ok] udp 32 (DF) (ttl 64, id 64916, len 60)
18:40:21.415143 $external_system.5012 > $int_server_ip.10442: [bad udp
cksum a9e7! -> 7036] udp 32 (ttl 115, id 9053, len 60)
...
$ext_if:
18:40:21.392510 $sext_server_ip.51049 > $external_system.5012: [bad udp
cksum 528b! -> e3da] udp 32 (ttl 63, id 16487, len 60)
18:40:21.395975 $external_system.5012 > $sext_server_ip.10442: [udp sum
ok] udp 32 (ttl 116, id 9052, len 60) <--This is a "new" incoming stream
18:40:21.413377 $sext_server_ip.51049 > $external_system.5012: [bad udp
cksum 528b! -> 53d8] udp 32 (ttl 63, id 30449, len 60)
18:40:21.415089 $external_system.5012 > $sext_server_ip.10442: [udp sum
ok] udp 32 (ttl 116, id 9053, len 60)
...
The problem seems to be that the internal system tells the external one
about the source port (10442) it should connect to (via SIP), and as
last step sends a packet from that port (plus in-protocol info, I
assume). But pf changes that source port on that outgoing packet (to
51049), and keeps doing so for all following packets, while the external
system sticks to the protocol and sends its traffic to 10442.
So it looks like pf can't distinguish between what it sees as "follow
up" packets to the first outgoing packet (18:40:21.392468) and the reply
packets to the "incoming" stream.
The connection breaks because the firewall the $external_system is
behind expects replies to the packets send to 10442 to come back from
that port.
All of this wouldn't happen if the source port hadn't been changed to 51049.
So: is there any way of preventing this behaviour? I didn't find
anything in pf.conf(5) or elsewhere ...
Thx for any insight, folks
/markus
PS:
These are the rules in question:
match in from any to $ext_server_ip rdr-to $int_server_ip
match out from $int_server_ip to any nat-to $ext_server_ip
pass log quick on { $ext_if, $int_if } inet proto udp from any to
$int_server_ip port { >< 11001 } label "RTP IN -- ACCEPT "
pass log quick on { $ext_if, $int_if } inet proto udp from
$int_server_ip to any port { >= 1024 } label "UDP HIGH OUT -- ACCEPT "
ntpd not setting time under kvm-qemu
Hi all I have 5.5 i386 running under kvm-qemu, using ntpd to sync time. But the system keeps constantly loosing time, at a rate of about two seconds per minute (which of course makes it unusable). When starting ntpd with the "-s" flag, it successfully sets the system time and initializes /var/db/ntp.drift. But after that it does no longer set the system time, even if it says so in syslog: Sep 21 13:12:37 secure ntpd[26259]: adjusting local clock by 53.514878s Sep 21 13:14:47 secure ntpd[26259]: adjusting local clock by 52.869489s Sep 21 13:16:27 secure ntpd[26259]: adjusting local clock by 54.363131s The offest is correct, by the time it writes that message, the system clock is really that much off the real ntp time. Only that the local clock never does get adjusted. The clock frequency is also never adjusted, and ntp.drift remains untouched. In order to run the system at all under qemu I had to disable mpbios in the kernel. Could this have caused that effect? Or is anyone aware of this being a problem under kvm-qemu and i386 (no such problems with 5.5 or -current amd64)? Thanks /markus
Re: how to debug iked failures?
Hi all To finish off this ancient thread, I've written up what it took to get StrongSwan to play nicely with iked and to build a GRE tunnel over the IPSec link: http://markus.wernig.net/en/it/ip6tunnel.phtml Any feedback is of course very welcome. krgds /markus On 08/13/2014 06:05 AM, Markus Wernig wrote: > Finally found a rather awkward workaround: > > 1) On the VPN GW, set an ip alias from a different subnet > (192.168.100.1/24) on the primary interface > 2) Set up iked.conf with > ikev2 ... > from 0.0.0.0/0 to 192.168.100.0/24 > config address 192.168.100.0/24 > config address 192.168.100.2 > (yes, both ...) > 3) On the client, configure tunnel mode instead of transport mode, > configure remote subnet to be 192.168.100.0/24, but still request ip > configuration from IKEv2.
Re: how to debug iked failures?
Finally found a rather awkward workaround: 1) On the VPN GW, set an ip alias from a different subnet (192.168.100.1/24) on the primary interface 2) Set up iked.conf with ikev2 ... from 0.0.0.0/0 to 192.168.100.0/24 config address 192.168.100.0/24 config address 192.168.100.2 (yes, both ...) 3) On the client, configure tunnel mode instead of transport mode, configure remote subnet to be 192.168.100.0/24, but still request ip configuration from IKEv2. When this comes up, the client gets two IP addresses (192.168.100.2 and a random one from the same subnet, but strongswan fails if it is sent the static one alone ...) So now I can connect from the client (from its 192.168.100.2 address) to the VPN GW (on its 192.168.100.1 alias) - which is what this was all about (hence the transport mode). As a by-note: It seems that iked, after authenticating the peer, always sends the "to" address from iked.conf as TSi and the "from" address as TSr in the IKE_AUTH response. In my understanding, this should be the other way round. Thanks for bearing with me :-) krgds /markus
Re: how to debug iked failures?
On 08/12/2014 07:19 PM, Reyk Floeter wrote: > Another reason for AF 0 could be the use of the keyword "any" in your > iked.conf. I thought we fixed that before to inherit the AF from the > peer, but try to use "0.0.0.0/0" instead of "any" for IPv4 and > something like "::/0" for IPv6. > > Reyk > Yes, that was indeed the cause. Replacing every occurance of "any" with 0.0.0.0/0 finally allowed the flow to be set up! Thank you very much !!! But still, no joy ... :-[ iked now authenticates the ufqdn and sends it its assigned ip address. Then it sends TSi and TSr, but chooses its own internal address as TSi: Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: type REPLY length 8 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length 44 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4 xforms 3 spi 0x18f70837 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 192.168.10.Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: type REPLY length 8 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length 44 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4 xforms 3 spi 0x18f70837 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 0.0.0.0 end 255.255.255.255 Aug 12 20:40:52 tunnel iked[6305]: ikev2_msg_send: IKE_AUTH response from 192.168.10.30:4500 to 80.219.68.219:4500 msgid 1, 1980 bytes, NAT-T 30 end 192.168.10.30 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 24 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: count 1 length 16 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 20:40:52 tunnel iked[6305]: ikev2_pld_ts: start 0.0.0.0 end 255.255.255.255 Aug 12 20:40:52 tunnel iked[6305]: ikev2_msg_send: IKE_AUTH response from 10.x.y.z:4500 to A.B.C.D:4500 msgid 1, 1980 bytes, NAT-T Again, is not the TSi the client's address? Why would iked send its own private address? Is the problem that I am trying to assign addresses from the same internal network that the VPN GW is in? The strongswan logs seem to match this: Aug 12 20:40:52 slimtoo charon: 10[IKE] IKE_SA xfertunnel[1] state change: CONNECTING => ESTABLISHED Aug 12 20:40:52 slimtoo charon: 10[IKE] scheduling reauthentication in 86110s Aug 12 20:40:52 slimtoo charon: 10[IKE] maximum IKE_SA lifetime 86290s Aug 12 20:40:52 slimtoo charon: 10[IKE] processing INTERNAL_IP4_ADDRESS attribute Aug 12 20:40:52 slimtoo charon: 10[KNL] 192.168.1.x is on interface wlan0 Aug 12 20:40:52 slimtoo charon: 10[IKE] installing new virtual IP 10.a.b.c Aug 12 20:40:52 slimtoo charon: 10[KNL] virtual IP 10.a.b.c installed on wlan0 Aug 12 20:40:52 slimtoo charon: 10[CFG] selecting proposal: Aug 12 20:40:52 slimtoo charon: 10[CFG] proposal matches Aug 12 20:40:52 slimtoo charon: 10[CFG] recei
Re: how to debug iked failures?
On 08/12/2014 05:39 PM, Markus Wernig wrote: > But really, I think this is the problem: > Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: loaded CHILD > SA spi 0xcb320247 > Aug 12 16:56:18 tunnel iked[22215]: pfkey_flow: unsupported address family 0 > Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: failed to load > flow > Aug 12 16:56:18 tunnel iked[22215]: ikev2_dispatch_cert: failed to send > ike auth > > It seems that the flow that comes from &sa->sa_flows in > ikev2.c::ikev2_childsa_enable does not have its AF set. How could this > happen? > Could this be the reason? Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: count 1 length 16 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 8 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: count 1 length 0 Aug 12 18:38:09 tunnel iked[3574]: ikev2_pld_ts: type protoid 0 length 0 startport 0 endport 65535 Should not the TSi contain the IP of the Client? In the log above it appears that it contains the IP of the VPN GW. And then TSr is of an unknown type? Is strongswan sending something wrong here? thx /markus
Re: how to debug iked failures?
On 08/12/2014 12:33 PM, Markus Wernig wrote: > sadb_getspi: satype esp vers 2 len 10 seq 19 pid 25389 > address_src: A.B.C.D > address_dst: 10.x.y.z > spirange: min 0x0100 max 0x > sadb_getspi: satype esp vers 2 len 10 seq 19 pid 25389 > sa: spi 0xfe52d794 auth none enc none > state mature replay 0 flags 0<> > address_src: A.B.C.D > address_dst: 10.x.y.z > sadb_update: satype esp vers 2 len 41 seq 20 pid 25389 > sa: spi 0xfe52d794 auth hmac-sha1 enc aes > state mature replay 64 flags 0x204 > lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 > lifetime_soft: alloc 0 bytes 493384368 add 9925 first 0 > address_src: A.B.C.D > address_dst: 10.x.y.z > key_auth: bits 160: ... > key_encrypt: bits 128: ... > identity_src: type ufqdn id 0: UFQDN/j...@doe.com > identity_dst: type fqdn id 0: FQDN/vpn.doe.com > udpencap: udpencap port 4500 > tag: ipsec-UFQDN/j...@doe.com > sadb_update: satype esp vers 2 len 34 seq 20 pid 25389 > sa: spi 0xfe52d794 auth hmac-sha1 enc aes > state mature replay 64 flags 0x204 > lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 > lifetime_soft: alloc 0 bytes 493384368 add 9925 first 0 > address_src: A.B.C.D > address_dst: 10.x.y.z > identity_src: type ufqdn id 0: UFQDN/j...@doe.com > identity_dst: type fqdn id 0: FQDN/vpn.doe.com > udpencap: udpencap port 4500 > tag: ipsec-UFQDN/j...@doe.com > sadb_add: satype esp vers 2 len 41 seq 21 pid 25389 > sa: spi 0xc06ab6b8 auth hmac-sha1 enc aes > state mature replay 64 flags 0x204 > lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 > lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0 > address_src: 10.x.y.z > address_dst: A.B.C.D > key_auth: bits 160: ... > key_encrypt: bits 128: ... > identity_src: type fqdn id 0: FQDN/vpn.doe.com > identity_dst: type ufqdn id 0: UFQDN/j...@doe.com > udpencap: udpencap port 4500 > tag: ipsec-UFQDN/j...@doe.com > sadb_add: satype esp vers 2 len 34 seq 21 pid 25389 > sa: spi 0xc06ab6b8 auth hmac-sha1 enc aes > state mature replay 64 flags 0x204 > lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 > lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0 > address_src: 10.x.y.z > address_dst: A.B.C.D > identity_src: type fqdn id 0: FQDN/vpn.doe.com > identity_dst: type ufqdn id 0: UFQDN/j...@doe.com > udpencap: udpencap port 4500 > tag: ipsec-UFQDN/j...@doe.com But really, I think this is the problem: Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: loaded CHILD SA spi 0xcb320247 Aug 12 16:56:18 tunnel iked[22215]: pfkey_flow: unsupported address family 0 Aug 12 16:56:18 tunnel iked[22215]: ikev2_childsa_enable: failed to load flow Aug 12 16:56:18 tunnel iked[22215]: ikev2_dispatch_cert: failed to send ike auth It seems that the flow that comes from &sa->sa_flows in ikev2.c::ikev2_childsa_enable does not have its AF set. How could this happen?
Re: how to debug iked failures?
On 08/12/2014 11:58 AM, Reyk Floeter wrote: > Operation not supported is from the kernel returning "EOPNOTSUPP". > > If any of the following sysctls are turned off and it is requested via > the PFKEYv2 socket, the kernel will return EOPNOTSUPP: > > net.inet.esp.enable=1 > net.inet.ah.enable=1 > net.inet.ipcomp.enable=0 > All three are set to 1. But strangely, now the "Operation not supported" message does not occur anymore. > You can also monitor the pfkey messages with "ipsectl -m" [add one or > more -v for packet dumps] to see what message returns EOPNOTSUPP. Here's the output - I don't see any obvious errors ... sadb_getspi: satype esp vers 2 len 10 seq 19 pid 25389 address_src: A.B.C.D address_dst: 10.x.y.z spirange: min 0x0100 max 0x sadb_getspi: satype esp vers 2 len 10 seq 19 pid 25389 sa: spi 0xfe52d794 auth none enc none state mature replay 0 flags 0<> address_src: A.B.C.D address_dst: 10.x.y.z sadb_update: satype esp vers 2 len 41 seq 20 pid 25389 sa: spi 0xfe52d794 auth hmac-sha1 enc aes state mature replay 64 flags 0x204 lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 lifetime_soft: alloc 0 bytes 493384368 add 9925 first 0 address_src: A.B.C.D address_dst: 10.x.y.z key_auth: bits 160: ... key_encrypt: bits 128: ... identity_src: type ufqdn id 0: UFQDN/j...@doe.com identity_dst: type fqdn id 0: FQDN/vpn.doe.com udpencap: udpencap port 4500 tag: ipsec-UFQDN/j...@doe.com sadb_update: satype esp vers 2 len 34 seq 20 pid 25389 sa: spi 0xfe52d794 auth hmac-sha1 enc aes state mature replay 64 flags 0x204 lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 lifetime_soft: alloc 0 bytes 493384368 add 9925 first 0 address_src: A.B.C.D address_dst: 10.x.y.z identity_src: type ufqdn id 0: UFQDN/j...@doe.com identity_dst: type fqdn id 0: FQDN/vpn.doe.com udpencap: udpencap port 4500 tag: ipsec-UFQDN/j...@doe.com sadb_add: satype esp vers 2 len 41 seq 21 pid 25389 sa: spi 0xc06ab6b8 auth hmac-sha1 enc aes state mature replay 64 flags 0x204 lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0 address_src: 10.x.y.z address_dst: A.B.C.D key_auth: bits 160: ... key_encrypt: bits 128: ... identity_src: type fqdn id 0: FQDN/vpn.doe.com identity_dst: type ufqdn id 0: UFQDN/j...@doe.com udpencap: udpencap port 4500 tag: ipsec-UFQDN/j...@doe.com sadb_add: satype esp vers 2 len 34 seq 21 pid 25389 sa: spi 0xc06ab6b8 auth hmac-sha1 enc aes state mature replay 64 flags 0x204 lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0 address_src: 10.x.y.z address_dst: A.B.C.D identity_src: type fqdn id 0: FQDN/vpn.doe.com identity_dst: type ufqdn id 0: UFQDN/j...@doe.com udpencap: udpencap port 4500 tag: ipsec-UFQDN/j...@doe.com I was wondering wether client sending EAP options would have anything to do with it: >> sending end entity cert >> establishing CHILD_SA xfertunnel >> generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr >> AUTH CPRQ(ADDR DNS DNS) N(USE_TRANSP) SA TSi TSr N(MOBIKE_SUP) >> N(NO_ADD_ADDR) N(EAP_ONLY) ] Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_payloads: decrypted payload NOTIFY nextpayload NOTIFY critical 0x00 length 8 Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_notify: protoid NONE spisize 0 type MOBIKE_SUPPORTED Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_payloads: decrypted payload NOTIFY nextpayload NOTIFY critical 0x00 length 8 Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_notify: protoid NONE spisize 0 type NO_ADDITIONAL_ADDRESSES Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_payloads: decrypted payload NOTIFY nextpayload NONE critical 0x00 length 8 Aug 12 12:23:20 tunnel iked[25389]: ikev2_pld_notify: protoid NONE spisize 0 type EAP_ONLY_AUTHENTICATION thx /markus
Re: how to debug iked failures?
On 08/10/2014 03:09 PM, Reyk Floeter wrote: > Just try to increase the number of "v"s to get more info, for example, > iked -dvv or iked -dvvv to get packet dumps. Thanks for the hint. That brought some progress. I've now switched back to -current and changed the client setup (I had been using the NetworkManager backend of the charon keying daemon, which caused the crashes, also on -current). Now iked does not crash anymore - I will still do the recompiling and backtracing, as this clearly should not happen. But I think it would make sense to first get a working setup. That said, the connection does still not succeed. After SA_INIT and IKE_AUTH everything seems fine, certificate gets authenticated, but then iked says it can't send the ike_auth packet back. Aug 12 11:02:47 tunnel iked[26844]: sa_stateok: VALID flags 0x1f, require 0x1f cert,certvalid,auth,authvalid,sa ug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 22 nextpayload CERT Aug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 1520 nextpayload AUTH Aug 12 11:02:47 tunnel iked[26844]: ikev2_next_payload: length 264 nextpayload CP Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_getspi: message: Operation not supported ... Strange ... what is not supported? ... Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length 24 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: count 1 length 16 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport 65535 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: start 10.x.y.z end 10.x.y.z Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 length 8 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: count 1 length 0 Aug 12 11:02:47 tunnel iked[26844]: ikev2_pld_ts: type protoid 0 length 0 startport 0 endport 65535 Aug 12 11:02:47 tunnel iked[26844]: ikev2_msg_send: IKE_AUTH response from 10.x.y.z:4500 to A.B.C.D:4500 msgid 1, 1996 bytes, NAT-T Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_add: update spi 0xf82bfb58 Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa: udpencap port 4500 Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: loaded CHILD SA spi 0xf82bfb58 Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa_add: add spi 0xcdac6edf Aug 12 11:02:47 tunnel iked[26844]: pfkey_sa: udpencap port 4500 Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: loaded CHILD SA spi 0xcdac6edf Aug 12 11:02:47 tunnel iked[26844]: pfkey_flow: unsupported address family 0 Aug 12 11:02:47 tunnel iked[26844]: ikev2_childsa_enable: failed to load flow Aug 12 11:02:47 tunnel iked[26844]: ikev2_dispatch_cert: failed to send ike auth Does anybody see what's going wrong here? It does then send out a packet, but on the client side this triggers an error: initiating IKE_SA xfertunnel[1] to E.F.G.H generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] sending packet: from 192.168.1.x[500] to E.F.G.H[500] (1204 bytes) received packet: from E.F.G.H[500] to 192.168.1.x[500] (457 bytes) parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ] local host is behind NAT, sending keep alives remote host is behind NAT received cert request for sending cert request for authentication of 'j...@doe.com' (myself) with RSA signature successful sending end entity cert establishing CHILD_SA xfertunnel generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR DNS DNS) N(USE_TRANSP) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(EAP_ONLY) ] sending packet: from 192.168.1.x[4500] to E.F.G.H[4500] (2236 bytes) received packet: from E.F.G.H[4500] to 192.168.1.x[4500] (1996 bytes) TS_RESPONDER verification failed could not decrypt payloads message verification failed IKE_AUTH response with message ID 1 processing failed Any more ideas? Thx /markus
how to debug iked failures?
Hi all I am trying to set up a ipsec tunnel with iked in a double NAT scenario: Client --> NAT GW 1 --> Inet --> NAT GW 2 --> VPN GW Client has 192.168.1.x, User is j...@doe.com VPN GW has 10.x.y.z, hostname vpn.doe.com NAT GW 1 does hide NAT to A.B.C.D NAT GW 2 does static NAT for public GW IP, forwards to VPN GW The client runs Strongswan on Linux. VPN GW is running 5.5 GENERIC#271 on amd64. I'm trying to set up RSA authentication with X.509 certificates, so I've configured Strongswan to use Key and Cert with subjectAltname=email:j...@doe.com, and to ask for IP address. Copied the client cert and the issuing CA cert to /etc/iked/certs on the VPN GW. PF is disabled. Configured iked on the VPN GW in iked.conf: ikev2 johndoevpn \ quick esp inet \ from any to 10.x.y.z \ peer any local any \ srcid vpn.doe.com dstid j...@doe.com \ config address 10.x.y.A \ config netmask 255.255.255.0 \ config name-server 10.x.y.B \ (valid IP of DNS at VPN site) tag johndoevpn VPNGW# sysctl -a | grep esp net.inet.esp.enable=1 net.inet.esp.udpencap=1 net.inet.esp.udpencap_port=4500 But the client is unable to connect to the VPN GW, and I just can't find out what's going wrong. Unfortunately there are two ways it is failing: 1) Client sends IKEv2 msg IKE_SA_INIT on Port 500, VPN GW replies with IKE_SA_INIT and CertReq, then client sends IKE_AUTH. But to this packet the VPN GW never replies, and the client resends until it times out. I see in the client log that it is selecting and sending the j...@doe.com certificate. In the VPN GW logs I get: Aug 9 08:40:35 tunnel iked[18255]: ikev2_recv: IKE_SA_INIT from initiator A.B.C.D:34276 to 10.x.y.z:500 policy 'johndoevpn' id 0, 1048 bytes Aug 9 08:40:35 tunnel iked[18255]: ikev2_msg_send: IKE_SA_INIT from 10.x.y.z:500 to A.B.C.D:34276, 457 bytes Aug 9 08:40:35 tunnel iked[18255]: ikev2_recv: IKE_AUTH from initiator A.B.C.D:4500 to 10.x.y.z:4500 policy 'johndoevpn' id 1, 2320 bytes Aug 9 08:40:39 tunnel iked[18255]: ikev2_recv: IKE_AUTH from initiator A.B.C.D:4500 to 10.x.y.z:4500 policy 'johndoevpn' id 1, 2320 bytes Aug 9 08:40:46 tunnel iked[18255]: ikev2_recv: IKE_AUTH from initiator A.B.C.D:4500 to 10.x.y.z:4500 policy 'johndoevpn' id 1, 2320 bytes Aug 9 08:40:59 tunnel iked[18255]: ikev2_recv: IKE_AUTH from initiator A.B.C.D:4500 to 10.x.y.z:4500 policy 'johndoevpn' id 1, 2320 bytes 2) Client sends IKEv2 msg IKE_SA_INIT on Port 500, and iked terminates immediately. If this happens, only a reboot will ever again get it to at least answer the SA_INIT. If iked is simply restarted, it will only crash again when the next packet arrives. Aug 9 14:31:56 tunnel iked[32658]: ikev2_recv: IKE_SA_INIT from initiator A.B.C.D:36858 to 10.x.y.z:500 policy 'johndoevpn' id 0, 1048 bytes Aug 9 14:31:56 tunnel iked[4493]: lost child: ikev2 terminated; signal 11 Aug 9 14:31:56 tunnel iked[27717]: ikev1 exiting Aug 9 14:31:56 tunnel iked[20802]: ca exiting Aug 9 14:31:56 tunnel iked[4493]: parent terminating In both cases, there are no other logs anywhere on the VPN GW. I've started iked with "-DA=99 -v" and sent an "ikectl log verbose", but no change. ikectl monitor shows nothing. So I was wondering if anybody saw what I am doing wrong - probably I got the config wrong. Especially I'm not quite sure if the files containing the certs need to have special names. If not: How does one debug iked? Why is it not answering, and, above all, why is it crashing? Are there really no logs? I've also tried the following, with identical results: - 5.6 current-amd64 from Aug 8 - create a new RSA keypair and X.509 cert for VPN GW (extracted pubkey from cert to /etc/iked/local.pub, privkey to /etc/iked/private/local.key, and copied the cert (with subjectAltname=DNS:vpn.doe.com) to /etc/iked/certs) Would be very glad if anyone could share a pointer ... Thx /markus
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On 06/17/2014 11:10 AM, Brad Smith wrote: >>> boot -c >>> disable mpbios > Because ACPI is in use which takes higher precedence over MP BIOS. You > have to disable acpimadt. THANKS GUYS!! This just "resolved" a blocker that had for 2 years prevented me from upgrading my OpenBSD kvm guests to anything beyond 5.1! /m
Re: Oddity with httpd/mod_ssl: missing HTTPS environment variable on non _default_ vhosts
Not sure about the ported httpd, but usually you have to enable the generation of those environment vars with SSLOptions +StdEnvVars as they are off by default. krgds /m On Tue, 18 Feb 2014, Olivier Mehani wrote: (Almost) everything works fine, and I do indeed manage to successfully access all sites over HTTPS as expected. However, the HTTPS environment variable, which should be set to 'on' for HTTPS sessions, is missing for all but the first VHost.
ipsec with smartcard?
Hi all I need to build an OpenBSD IPsec gateway that uses keys/certificates from a hardware device (external smartcard, presumably via pkcs#11) for authenticating itself to other gateways when establishing a connection with them (active). In the ipsec/isakmpd man pages I found no references to pksc11 or smart cards - is there a way to do this at all? If so, what would be the right place to look for the documentation? Thx /markus
Re: vpn isakmpd ipsec, one side with only one interface
Hi I'm not sure if this will work, but you could try creating a loopback interface (lo2) on FWC with the IP address that the FTP server should be reachable on and then set up a regular VPN between FWA and FWC just for that one IP address: ike esp from 172.17.2.21/32 to 192.168.0.0/24 peer ip_fwA ... Then tell the FTP server to listen on the IP of the lo2 interface (172.17.2.21?) /m On 02/13/12 14:43, Wesley M. wrote: > o;?Hi, > > I was using ipsec vpn between 2 OpenBSD Gateway. It worked very > well. > > Here : > > ---rl0---[fwA]---rl1(internet)-sis1---[fwB > with ftpd]---sis0--- > > Now we remove ftp services from fwB and put it on an > other machine fwC with an internet connection (only one network card). is > it possible to keep a vpn online from fwA and fwC, and so computersA can > reach again ftp using vpn (provided by fwC). Perhaps i need to use vether > on fwC so briged pf ? > > Here the old ipsec.conf from fwB: > ike esp from > 172.17.2.0/24 to 192.168.0.0/24 peer ip_fwA > main auth hmac-sha1 enc > aes-256 group modp1024 > quick auth hmac-sha1 enc aes-256 group modp1024 > > psk "demopassword" > > My idea on fwC : > > add verther0 with : "inet > 172.17.2.21 255.255.255.0"
Re: CARP strangeness after 5.0 upgrade
On 01/25/12 18:23, Matt Hamilton wrote: > > pass in quick on $ext_if proto carp from $fw_ext_ips to 224.0.0.18 > queue carp_out > pass in quick on $int_if proto carp from $fw_int_ips to 224.0.0.18 > queue carp_in > pass out quick on $ext_if proto carp from $fw_ext_ips to 224.0.0.18 > queue carp_out > pass out quick on $int_if proto carp from $fw_ext_ips to 224.0.0.18 > queue carp_in And $fw_ext_ips/$fw_int_ips do really contain the ip addresses of BOTH boxes? > > I don't understand why the master is the one with the highest > advskew. This is the same on the inside carp interface too. You said you saw carp advertisments on the net. Who is sending those? Can you set sysctl net.inet.carp.log=7 and see if any carp-related errors appear in the syslog? /m
Solved: /bsd: carpN: ip_output failed: 65
Hi all Disbling ipv6 on the ifs didn't help. It turned out pf was blocking the outgoing carp advertisements on 2 out of 4 interfaces without logging. Adding "keep state (no-sync)" to the carp rules, activating them, and then flushing states on both firewalls finally brought the cluster back to normal. Thanks to cd for the help. lg /markus On 01/15/12 16:18, Markus Wernig wrote: > Hi all > > After upgrading to 5.0 (and also on -current) I keep getting those > errors for 2 out of 4 carp'd interfaces in a fw cluster pair: > > /bsd: carp2: ip_output failed: 65 > /bsd: carp3: ip_output failed: 65 > > And effectively, no CARP traffic is seen on those two interfaces, > neither in nor out. Both boxes assume master status on the if. > > I got a gut feeling that this has something to do with ipv6, which I do > not use at all on the boxes. My pf ruleset is actually ipv4 only. I do > see ipv6 addresses on the phyif and carpif though (which I have not > configured). > > Could it be that I need to add something to my ruleset? > > Any way to totally disable ipv6 for a test? > > krgds /markus
/bsd: carpN: ip_output failed: 65
Hi all After upgrading to 5.0 (and also on -current) I keep getting those errors for 2 out of 4 carp'd interfaces in a fw cluster pair: /bsd: carp2: ip_output failed: 65 /bsd: carp3: ip_output failed: 65 And effectively, no CARP traffic is seen on those two interfaces, neither in nor out. Both boxes assume master status on the if. I got a gut feeling that this has something to do with ipv6, which I do not use at all on the boxes. My pf ruleset is actually ipv4 only. I do see ipv6 addresses on the phyif and carpif though (which I have not configured). Could it be that I need to add something to my ruleset? Any way to totally disable ipv6 for a test? krgds /markus
Re: CARP strangeness after 5.0 upgrade
On 01/12/12 00:05, Markus Wernig wrote: > If I set net.inet.carp.log=7, I get lots of the following on both fws, > only for carp1 and carp2, never for carp0 and carp3: > carp2: ip_output failed: 65 > carp1: ip_output failed: 65 > carp2: ip_output failed: 65 > carp1: ip_output failed: 65 > carp2: ip_output failed: 65 > carp1: ip_output failed: 65 Hi all After another round of reboots (no config changed) this has now shifted to carp2 and carp3: Jan 12 08:33:17 fw1 /bsd: carp2: ip_output failed: 65 Jan 12 08:33:17 fw1 /bsd: carp3: ip_output failed: 65 Jan 12 08:33:18 fw1 /bsd: carp2: ip_output failed: 65 Jan 12 08:33:18 fw1 /bsd: carp3: ip_output failed: 65 And consequently tcpdump shows outgoing carp traffic on em0 and em1 only. Does anybody have an idea where to search further? krgds /markus
CARP strangeness after 5.0 upgrade
Hello all
I have recently upgraded a pair of CARPed firewalls from 4.6 to 5.0
(late, I know ...) after almost 2 years of absolutely flawless operation
(ipv4 interfaces only).
I have changed all the nat/rdr rules in pf.conf to the new syntax, not
changed any other fw/nw setting (at least to my knowledge - I used
sysmerge in the process, carefully, and haven't noticed any fw/nw
related changes in any file. The boxes are rather straight forwardly
configured "plain" firewalls and very close to the default settings).
They have 4 interfaces each, the external (egress, carp0 on em0) one
being connected to the provider's switches (professional gear, Cisco or
the like), the dmz (internal, carp1-3 on em1-3) ones being connected to
a pair of levelone gsw-1641 ("web smart switch", the cheap stuff).
The two fw (fw1=master, and fw2=backup) and switches have been rebooted
multiple times by now.
The problem now is that the CARP master selection leads to weird
results. After rebooting both, I get the following picture:
fw1 (master, advbase 1 advskew 1):
carp0: BACKUP
carp1: MASTER
carp2: MASTER
carp3: BACKUP
ifconfig -g carp
carp: carp demote count 3
fw2 (backup, advbase 1 advskew 10)
carp0: MASTER
carp1: MASTER
carp2: MASTER
carp3: MASTER
ifconfig -g carp
carp: carp demote count 2
I get the following in dmesg on fw1:
carp: carp0 demoted group carp by 1 to 129 (carpdev)
carp: carp1 demoted group carp by 1 to 130 (carpdev)
carp: carp2 demoted group carp by 1 to 131 (carpdev)
carp: carp3 demoted group carp by 1 to 132 (carpdev)
carp: carp2 demoted group carp by -1 to 131 (carpdev)
carp: carp2 demoted group xfer by -1 to 0 (carpdev)
carp: carp0 demoted group carp by -1 to 130 (carpdev)
carp: pfsync0 demoted group carp by 1 to 131 (pfsync bulk start)
carp: pfsync0 demoted group pfsync by 1 to 1 (pfsync bulk start)
carp: carp3 demoted group carp by -1 to 130 (carpdev)
carp: carp3 demoted group mgmt by -1 to 0 (carpdev)
carp: carp1 demoted group carp by -1 to 129 (carpdev)
carp: carp1 demoted group coca by -1 to 0 (carpdev)
carp2: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp: pfsync0 demoted group carp by -1 to 128 (pfsync bulk done)
carp: pfsync0 demoted group pfsync by -1 to 0 (pfsync bulk done)
carp: carp2 demoted group carp by 1 to 129 (> snderrors)
carp: carp1 demoted group carp by 1 to 130 (> snderrors)
carp: carp1 demoted group coca by 1 to 1 (> snderrors)
carp: carp2 demoted group xfer by 1 to 1 (> snderrors)
carp0: state transition: BACKUP -> MASTER
carp3: state transition: BACKUP -> MASTER
carp: carp3 demoted group carp by 1 to 3 (> snderrors)
carp: carp3 demoted group mgmt by 1 to 1 (> snderrors)
carp0: state transition: MASTER -> BACKUP
nd6_na_input: duplicate IP6 address fe80:0008::0200:5eff:fe00:01c8
carp3: state transition: MASTER -> BACKUP
dmesg on fw2 gives this:
carp: carp0 demoted group carp by 1 to 129 (carpdev)
carp: carp1 demoted group carp by 1 to 130 (carpdev)
carp: carp2 demoted group carp by 1 to 131 (carpdev)
carp: carp3 demoted group carp by 1 to 132 (carpdev)
carp: pfsync0 demoted group carp by 1 to 133 (pfsync bulk start)
carp: pfsync0 demoted group pfsync by 1 to 1 (pfsync bulk start)
carp: carp2 demoted group carp by -1 to 132 (carpdev)
carp: carp2 demoted group xfer by -1 to 0 (carpdev)
carp: carp1 demoted group carp by -1 to 131 (carpdev)
carp: carp1 demoted group coca by -1 to 0 (carpdev)
carp: carp0 demoted group carp by -1 to 130 (carpdev)
carp: carp3 demoted group carp by -1 to 129 (carpdev)
carp: carp3 demoted group mgmt by -1 to 0 (carpdev)
carp: pfsync0 demoted group carp by -1 to 128 (pfsync bulk done)
carp: pfsync0 demoted group pfsync by -1 to 0 (pfsync bulk done)
carp2: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp: carp2 demoted group carp by 1 to 129 (> snderrors)
carp: carp1 demoted group carp by 1 to 130 (> snderrors)
carp: carp1 demoted group coca by 1 to 1 (> snderrors)
carp: carp2 demoted group xfer by 1 to 1 (> snderrors)
carp0: state transition: BACKUP -> MASTER
carp3: state transition: BACKUP -> MASTER
carp: carp3 demoted group carp by 1 to 3 (> snderrors)
carp: carp3 demoted group mgmt by 1 to 1 (> snderrors)
carp0: state transition: MASTER -> BACKUP
nd6_na_input: duplicate IP6 address fe80:0008::0200:5eff:fe00:01c8
arp info overwritten for 10.10.10.100 by 00:1e:68:9a:e4:4f on em2
nd6_na_input: duplicate IP6 address fe80:0009::0200:5eff:fe00:01c9
carp3: state transition: MASTER -> BACKUP
nd6_na_input: duplicate IP6 address fe80:000b::0200:5eff:fe00:01ff
nd6_na_input: duplicate IP6 address fe80:000a::0200:5eff:fe00:01d2
carp0: state transition: BACKUP -> MASTER
carp3: state transition: BACKUP -> MASTER
carp: carp3 demoted group carp by -1 to 2 (< snderrors)
carp: carp3 demoted group mgmt by -1 to 0 (< snderrors)
nd6_na_input: duplicate IP6 address fe80:000a::0200:5eff:fe00:01d2
nd6_na_input: duplicate IP6 address fe80:0009::0200:5eff:fe00:01c9
carp0: state transition: MASTER -> BACKUP
nd6_na
Re: sasyncd syncs only newly created sad's
Hi Mihajlo Yes, this feature (re-sychronization after master failure) has been missing from the day sasyncd came out (http://archives.neohapsis.com/archives/openbsd/2005-09/0818.html). When I gave that speech in Switzerland (the one you found the PDF of), I was confident that it would be implemented within a couple of months or so ... the whole thing being a sponsored development, I figured that the sponsor would want this program to be usable. But, alas, it wasn't. Pity, really. With a little more time at my hands and a little more wit in my brains I would love to pick this up. It would be SUCH a killer application. Hakan Olsson, the original developper, did once say he would look into it, butI haven't heard of him since. krgds & sorrynohelphere /markus Mihajlo Manojlov wrote: > Hi again, > > there is no feedback.. could someone who runs sasyncd check this for me? > Please, just restart sasyncd on slave(or master), and see if it syncs the > SAD's? > > This behaviour renders my redundant routers - non redundant. If I reboot > master, when it comes back and become master again, all VPN tunnels are down > because no SAD's are synced. > > Thank you very much. > > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of > Mihajlo Manojlov > Sent: Wednesday, January 06, 2010 11:10 PM > To: misc@openbsd.org > Subject: sasyncd syncs only newly created sad's > > Hi to all, > > I have two carped boxes and I want to use sasyncd for vpn redundancy, but > only > newly created sad's get synced. For example, I reboot the slave box, and when > it comes up again, sasyncd only sets flows, not the sad's. Maybe this is > normal behaviour? > > log from master: > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net: peer "10.23.6.2" connected > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net_ctl: peer "10.23.6.2" state > change to SLAVE > Jan 6 21:59:25 openbsd1 sasyncd[25895]: monitor_get_pfkey_snap: got 2016 > bytes SADB, 1392 bytes SPD > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_send_flush: sending FLUSH to > peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SADB data > 020a00023f000200010088f180d710010303040004000200 > 15f7444b04000400 > 380404000300 > b00403000500100259d44c6d > 03000600100259d45bb205000a00 > 010038392e3231322e37362e3130392f3332 > 05000b00010038392e3231322e39312e3137382f3332 > 04000800a0009884229af8684722ecf09bfe79c0d8eef96b3cfb > 04000900c000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 > 0101010013000300150010020a00 > 030011001002ff00030016001002 > 0a070800030012001002ff00 > 0200210008007465737476706e00 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca800 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca9f8 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccabf0 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccade8 > len 504 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SPD data > 02121d0003000600100259d44c6d > 010014000101010013000300150010020a00 > 030011001002ff0003001600 > 10020a070800030012001002ff00 > 05000a00010038392e3231322e39312e3137 > 382f333205000b00010038392e3231322e37 > 362e3130392f333202121d0003000600 > 100259d44c6d01001400030201001300 > 0300150010020a070800030011001002 > ff000300160010020a00 > 030012001002ff0005000a000100 > 38392e3231322e39312e3137382f333205000b000100 > 38392e3231322e37362e3130392f33320212 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca000 > len 232 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca0e8 > len 232 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca1d0 > len 232 to peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0
Re: mod_perl script is failing to work under SSL
Chris Bennett wrote: > I now wanted to improve security a bit, so when I tried accessing script > with https, I get this error in log file: > Can't locate object method "request" via package "Apache" Hi Compare the httpd.conf of your ssl and non-ssl virtual hosts. Both must have something like PerlModule Apache::Registry SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI krgds /markus
Re: how to set gnome-terminal default encoding
23e7 wrote: > Hi, > my openbsd is 4.5, gnome-terminal default encoding is ascii, I cannot > find how to set to utf-8. Which version? Normally, it's under Terminal->Set Character Encoding (Alt-T C) /m [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: dealing with incoming mail your own domain
Hi Jose The MX is the host destined for receiving mail for a domain. There is no indication that it should also be the only one sending mail from a domain. At the moment most domains use SPF records to mark their preferred relay, so you might want to check that instead of/in addition to the MX record. Be careful to look at the EnvFrom only, because evaluating the HdrFrom will block all kind of incoming mail (forwarded, mailing lists ...) Do you have mobile users who regularly use webmail or provider-owned relays with their @example.com addresses? Your MX will also have to be your outgoing relay or the outoing relay is whitelisted somehow, else people @example.com canB4t mail among each other. regards /markus Jose Fragoso wrote: > Bsically, if my network has de MX servers for domain > @example.com, and a host tries to send a mail saying > 'mail from:', I will trap him. > > So I would like to hear opinions from the more experienced > users about the pros and cons of this idea.
Re: Solved: sendmail: restrict sender domain for authenticated users
Hi Dan, thanks for the pointer Custom rules are the equivalent of having your head spin through a tumble-dryer ... but they work: SLocal_check_rcpt # check if sender is in local domains # if yes, accept # if not, recipient has to be local, else reject R$* $: $1 $| $>3 $&f R$* $| <> $@ OK <> is always ok R$* $| $*<@$=w.>$@ OK u...@local-host-name is ok R$* $| $* $: $1 any other user gets checked R$* $: $>3 $1 check recipient R$+<@$=w.> $@ OK recipient local? ok. this seems to be incoming R$+<@$+>$#error $@ 5.1.8 $: "551 Invalid sender domain" thx /markus Dan Harnett wrote: > On Sun, Jun 21, 2009 at 05:42:22PM +0200, Markus Wernig wrote: >> I have sendmail on 4.4 as MX and relay for outgoing mail using smtp >> auth. Now some users started using arbitrary from: addresses in their >> mail clients. I would like to restrict those sender addresses to the >> local domains, i.e. allow them to send mail from u...@my.domain or >> u...@my.other.domain, and reject their mails from u...@foreign.domain, >> preferably during the smtp dialog between MUA and sendmail. >> >> I've searched the sendmail docs and google, but can't find how to do >> this. Is it possible at all? > > Without modifying rulesets or running multiple instances of sendmail, I > think the simplest way is to use milter-regex. You can even match the > authenticated username against specific envelope senders rather than any > local domain. Otherwise, you're probably looking at implementing > something similar to this[1] in your configuration file. > > [1] http://www.sendmail.org/~ca/email/restrict.html
Re: Solved: sendmail: restrict sender domain for authenticated users
Hi Dan, thanks for the pointer Custom rules are the equivalent of having your head spin through a tumble-dryer ... but they work: SLocal_check_rcpt # check if sender is in local domains # if yes, accept # if not, recipient has to be local, else reject R$* $: $1 $| $>3 $&f R$* $| <> $@ OK <> is always ok R$* $| $*<@$=w.>$@ OK u...@local-host-name is ok R$* $| $* $: $1 any other user gets checked R$* $: $>3 $1 check recipient R$+<@$=w.> $@ OK recipient local? ok. this seems to be incoming R$+<@$+>$#error $@ 5.1.8 $: "551 Invalid sender domain" thx /markus Dan Harnett wrote: > On Sun, Jun 21, 2009 at 05:42:22PM +0200, Markus Wernig wrote: >> I have sendmail on 4.4 as MX and relay for outgoing mail using smtp >> auth. Now some users started using arbitrary from: addresses in their >> mail clients. I would like to restrict those sender addresses to the >> local domains, i.e. allow them to send mail from u...@my.domain or >> u...@my.other.domain, and reject their mails from u...@foreign.domain, >> preferably during the smtp dialog between MUA and sendmail. >> >> I've searched the sendmail docs and google, but can't find how to do >> this. Is it possible at all? > > Without modifying rulesets or running multiple instances of sendmail, I > think the simplest way is to use milter-regex. You can even match the > authenticated username against specific envelope senders rather than any > local domain. Otherwise, you're probably looking at implementing > something similar to this[1] in your configuration file. > > [1] http://www.sendmail.org/~ca/email/restrict.html [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
sendmail: restrict sender domain for authenticated users
Hi all I have sendmail on 4.4 as MX and relay for outgoing mail using smtp auth. Now some users started using arbitrary from: addresses in their mail clients. I would like to restrict those sender addresses to the local domains, i.e. allow them to send mail from u...@my.domain or u...@my.other.domain, and reject their mails from u...@foreign.domain, preferably during the smtp dialog between MUA and sendmail. I've searched the sendmail docs and google, but can't find how to do this. Is it possible at all? thx /markus
Re: cpu not configured??
OK, for the record: boot -c disable pcibios0 disable acpi0 disable apm0 will boot the machine (after waiting ca. 2 minutes after wsmouse0)! But, alas, the harddisks are not recognized by the kernel, which is - as far as I can tell - a rather final statement. Looking forward to 4.6. krgds /markus Markus Wernig wrote: > I'm trying to install OBSD on a FJ-Siemens Amilo xi 3650, without > success so far.
cpu not configured??
Hi all I'm trying to install OBSD on a FJ-Siemens Amilo xi 3650, without success so far. The kernel stops booting after some lines of output. I've tried 4.4 and 4.5. On 4.4 it stops right after the first lines. The last line of output is: acpi0: tables DSDT FACP HPET MCFG SLIC APIC BOOT SSDT SSDT SSDT SSDT No error, it just hangs On 4.5 there are some lines more of output (including the above one), it tells about wakeup devices and different timers, then comes to: cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 265MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0,version 20,24 pins And stops right there. Still, no errors, nothing. I don't ever get to a point where I can run a meaningful dmesg. The processor is a Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz with the following flags (as seen from linux, though): fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority I remember other machines and other operating systems where I had to pass special kernel boot parameters at the boot prompt in order to have the kernel ignore or treat differently certain hardware (one favourite was to disable acpi and the local apic). Here I'd use boot -c. But which parameters should I disable or modify? Unfortunately I'm not that familiar with the OBSD kernel, so I'd be grateful for any hints. I realize that this is going to take a lot of poking around in the dark. Thx /markus
Re: Flapping VPN under load on Soekris
Mikolaj Kucharski wrote: Another scenario. When all VPNs are up and stable (traffic is low) and one of the clients is rebooted at boot time when ipsecctl -f /etc/ipsec.conf is executed it's tunell is setup and _all_ other tunnels are immediately dropped. Am I right to assume that only those tunnels from behind the same NAT device are dropped? There was what I consider a bug in isakmpd that only looked ad IP pairs when matching packets to existing SAs. So any new connection from the same IP would break the existing ones. I don't know if it's actually fixed. See http://kerneltrap.org/index.php?q=mailarchive/openbsd-misc/2008/2/3/704644 krgds /markus
Re: PF/Carp/Pfsync
Hi Georg I think I remember something like this ... could it be that carp takes over the interface before pfsync has finished updating the booted machine's connection table? TCP (and many other protocols) takes care of such situations by simply retransmitting, so any TCP connections should recover within seconds. When using UDP I suppose, recovery depends on the application. Another reason could be the interfaces not coming back up together. You should set net.inet.carp.preempt=1 hth /markus Georg Kahest wrote: [...] but when the prefered master comes up again and starts to act as carp master, then client who has carp as its gateway loses some packets on the moment of failover, [...]
Re: CARP not leaving backup state
If you tcpdump do you see any carp traffic at all (ip proto 112)? Upon reboot? And you did enable carp preemption on both hosts (sysctl net.inet.carp.preempt=1)?
Re: CARP not leaving backup state
Hi Are you sure that all the interfaces you have configured carp on have link and can connect to each other? (I've seen similar behaviour caused by defective NICs: receive buffer not receiving while send buffer still sending - try ping on all interfaces) Is lo up? Is there any other router on the same network segment that propagates the same VHID with a better metric (i suppose that a VRRP router on the same net could cause trouble if it uses the same VHIDs). no answers, just questions, I know ... hth /markus
isakmpd times out on rolled-over client certificate
Hi all I have an OBSD4.3 VPN gateway that authenticates users based on their certificate and an isakmpd.policy, which works just fine. Now a user had to renew his certificate: same CA, same CA certificate, same Subject DN, same EVERYTHING. I'd have expected that he'd just need to close the VPN tunnel, install the new certificate, authenticate again and that'd be it. But not so. isakmpd logs and sends back: isakmpd[26674]: dropped message from aaa.bbb.ccc.ddd port 500 due to notification type INVALID_ID_INFORMATION On one machine, I had to restart isakmpd to get it to accept the new certificate, on the other one I can't because I connect to it through the same VPN ... Obviously some part of the certificate gets cached somewhere in memory (isakmpd? kernel?). Tearing down old SAs for the user's IP (echo "t aaa.bbb.ccc.ddd" > /var/run/isakmpd.fifo) doen't help. Is there any way (apart from bouncing isakmpd) to force (isakmpd? kernel?) to forget the old and use the new certificate? On one occasion I had to reboot a box ... which I consider a rather drastic measure for the occasion of a user certificate renewal. tx /markus
Re: IPSec tunnel problem
Alexey Vatchenko wrote: It's because of: ike passive esp from 192.168.0.0/24 to any local egress dstid [EMAIL PROTECTED] psk xxx Yes, it's because of that. But I'm convinced that you don't need that at all. From what I understand, you just need to give access from some remote network(s) to your office net. Please correct me if you are trying to achieve something else. Again (see last post): Home gateway: ike dynamic esp from HOME_NET to 192.168.0.0/24 peer OFFICE_EXTERNAL_IP psk xxx Office gateway: ike passive esp from HOME_NET to 192.168.0.0/24 psk xxx (if you have more than one external networks, you can put "any" instead of "HOME_NET" or repeat the stanza for each network.) krgds /markus
Re: IPSec tunnel problem
Hi From my point of view the problem is that you use the same network range 192.168.0/24 in your home and office. Off the top of my head I'd say that this should not work. The routing entries look a bit scary, actually. If I had the same setup, I'd try one of the following: - change the home network to something else than 192.168.0/24 - nat all traffic from the home network on the office gateway to its own internal address And I'd start out with the simplest of configurations and build from that: Home gateway: ike dynamic esp from HOME_NET to 192.168.0.0/24 peer OFFICE_EXTERNAL_IP psk xxx Office gateway: ike passive esp from HOME_NET to 192.168.0.0/24 psk xxx krgds /markus Alexey Vatchenko wrote: flow esp from 192.168.0.0/24 to 192.168.0.0/24 type bypass Coming to the office this morning i found out that all office's outgoing traffic goes through my home gateway. It looks like IPSec created default route for hosts in local network.
Re: IPSec tunnel problem
Hi What does the ipsec.conf entry on the Office gateway for the Home gateway look like? IP range of Home network? Are you trying to use the Home gateway as a relay to get into the Office net from other locations than from Home network? Do you have any NAT rules involved? "ipsecctl -s all" on Office and Home gateways before and after connection is established could shed some light. /m Alexey Vatchenko wrote: The problem is when home gateway establishes IPSec tunnel with office gateway, computers from office network cannot connect to office gateway (but they still can get Internet through the gateway). Here is what i do: Office network: 192.168.0.0/24 ipsec.conf: ike passive esp from 192.168.0.0/24 to any local egress dstid [EMAIL PROTECTED] psk xxx Home ipsec.conf: ike dynamic esp from any to 192.168.0.0/24 peer OFFICE_EXTERNAL_IP srcid [EMAIL PROTECTED] psk xxx So, please, shed some light on what i do wrong.
Re: multiple ipsec-nat-t clients behind same ip address
Rephrasing: Is it possible to have multiple nat-t clients behind the same NAT address connect to the same OBSD ipsec gateway? How? thx /markus Markus Wernig wrote: Hi all I'm having some trouble with VPN clients (workstations) connecting to an OBSD 4.2 VPN gateway. All clients sit behind one natting gateway, and are natted to the same egress ip address. They try to connect to another network behind the VPN gateway. The first connect succeeds, and the client gets its connection (i can track this with ipsecctl -s all on the VPN gateway). Traffic uses nat-t (udp 4500) as destination, yet the connection gets source-natted and the source port is changed to some unique value. This works well. But as soon as the second client connects, the first one is disconnected! The second connection is source-natted to the same IP, but uses a different source port. ipsecctl shows that both tuples for flows and sa get replaced by new ones the moment the second client connects. tcpdump on the gateway shows normal ipsec traffic during the first connection until the new one is initiated. After this, no packet for the first connection is sent by the gateway, but all belong to the second one (different SPIs and different source port) . Now i'm a bit unsure. From my understanding, it should be possible to have multiple nat-t clients use the same external ip address. Is there any limitation that i'm not aware of? Do i need to configure something on the gateway? It's set up for roadwarriors. Here's ipsec.conf: ike passive esp tunnel \ from any to a.b.c.d/24 \ srcid vpn.gate.way with a.b.c.d being the network the clients want to connect to and vpn.gate.way the fqdn of the gateway, as it appears in its certificate. Thx for any hint /markus
multiple ipsec-nat-t clients behind same ip address
Hi all I'm having some trouble with VPN clients (workstations) connecting to an OBSD 4.2 VPN gateway. All clients sit behind one natting gateway, and are natted to the same egress ip address. They try to connect to another network behind the VPN gateway. The first connect succeeds, and the client gets its connection (i can track this with ipsecctl -s all on the VPN gateway). Traffic uses nat-t (udp 4500) as destination, yet the connection gets source-natted and the source port is changed to some unique value. This works well. But as soon as the second client connects, the first one is disconnected! The second connection is source-natted to the same IP, but uses a different source port. ipsecctl shows that both tuples for flows and sa get replaced by new ones the moment the second client connects. tcpdump on the gateway shows normal ipsec traffic during the first connection until the new one is initiated. After this, no packet for the first connection is sent by the gateway, but all belong to the second one (different SPIs and different source port) . Now i'm a bit unsure. From my understanding, it should be possible to have multiple nat-t clients use the same external ip address. Is there any limitation that i'm not aware of? Do i need to configure something on the gateway? It's set up for roadwarriors. Here's ipsec.conf: ike passive esp tunnel \ from any to a.b.c.d/24 \ srcid vpn.gate.way with a.b.c.d being the network the clients want to connect to and vpn.gate.way the fqdn of the gateway, as it appears in its certificate. Thx for any hint /markus
syslog-ng and isakmpd
Hi all
I have replaced syslogd with syslog-ng on my OBSD4.2 boxes (needed tcp,
encryption and fifos). I have managed to mimick all traditional log
behaviour (as per the default syslogd config) with one exception:
isakmpd will not log a single bit into any facility. afaik isakmpd uses
the daemon facility (as does ntpd), so I have the following in
syslog-ng.conf:
source src {
unix-dgram("/dev/log");
internal();
};
[...]
filter f_daemon { facility(daemon); };
[...]
destination d_daemon { file("/var/log/daemon"); };
[...]
log { source src; filter f_daemon; destination d_daemon; };
[...]
Which works fine for ntpd. But no word from isakmpd in any file, not
even the catchall, not even with logging turned up to the maximum.
I've tried every which way but just can't see what to change.
Has anyone seen this before?
Thx /markus
deploy openssl patch
Dear list I have a couple of 4.1 firewalls that I would like to upgrade to 4.2. Before taking them online again I'd like to deploy the openssl patch from ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.2/common/002_openssl.patch Being perimeter firewalls, those systems don't have compile tools installed. I would thus need to pre-compile libssl on a 4.2 buildhost and deploy it onto the firewalls. I've been looking through the documentation but did not find a "good" way to do this, because openssl is not a package, but part of the base system. Is there any way other than tar - scp - untar after compiling libssl? thx for any pointers /markus
Re: ipsec with carp
Hi
The one time I remember getting that error was when I _thought_ I was
using certificates from /etc/isakmpd/{certsB&private}, but still had a
local.pub and local.key from the installation lying around that got used
instead. Some more debug info (/var/log/daemon) would be helpful indeed.
krgds /m
Patrick Hemmen wrote:
> Hello all,
>
> I have two OpenBSD machines for a redundancy VPN-Gateway. They use
> carp to share one IP-Address and sasyncd to synchronize SAs and SPDs.
> I setup a ipsec-tunnel in /etc/ipsec.conf. The tunnel isn't
> established and the error "PAYLOAD_MALFORMED" appears in the logs.
> With tcpdump I can see that the initial packet (isakmp v1.0 exchange
> ID_PROT) to establish the tunnel come from the host IP-Address and not
> from the carp address.
Re: carp devices master/backup behavior
Hi If the problem is intermittent, this is probably correct, but have you checked that you _really_ have different vhids for all devices? You might also want to set different passwords for each carp device, just to go sure they don't interfere with each other. krgds /markus Erich wrote: the backup system is in a state where the carp devices are in a mixed state. carp3 and carp4 for example are still MASTER and the rest of the interfaces has gone back to BACKUP state like they should. they are all in the same carp group. ideas what to check?
Re: IPSec VPN gateway with only one interface
For the record: The problem was not with with the single interface, but with my misreading the documentation. The error was in specifying the tunnel twice. The working ipsec directives are of course: ipsec.conf on A: ike esp from to peer srcid dstid ipsec.conf on B: ike passive esp tunnel from any to srcid Markus Wernig wrote: Hi all I'v looked through what documentation I could find, but didn't find this case mentioned, so I assumed it would work (which it doesn't): I have an OBSD 4.1 vpn gateway (A) with only one interface, over which the default route points out and over which the packets to forward through the tunnel arrive. The other gateway is a "regular" 2-interface OBSD 4.1 gateway (B). Here's the layout: Internal Net -- -- VPN gateway A & Internet & & VPN gateway B & Destination Net The tunnel seemingly does get created without any errors, but when packets pass through the tunnel, the remote gateway sends them right back. Also, on both gateways, 4 flows and 4 SADs get created, instead of 2 each, as I'd expect: # ipsecctl -s all FLOWS: flow esp in from to peer B> srcid dstid type use flow esp out from to peer B> srcid dstid type require flow esp in from to peer B> srcid dstid type use flow esp out from to peer B> srcid dstid type require SAD: esp tunnel from to spi 0xADEADBEEF auth hmac-sha2-256 enc aes esp tunnel from to spi 0xBDEADBEEF auth hmac-sha2-256 enc aes esp tunnel from to spi 0xCDEADBEEF auth hmac-sha2-256 enc aes esp tunnel from to spi 0xDDEADBEEF auth hmac-sha2-256 enc aes Thus, contradicting routes get added to the kernel routing tables: gateway B: Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 0 0 0 NAT router A/esp/use/in 0 0 0 NAT router A/esp/require/out 0 0 0 NAT router A/esp/use/in 0 0 0 NAT router A/esp/require/out ipsec.conf on A: ike esp from to peer srcid ike esp from to peer srcid ipsec.conf on B: ike passive esp tunnel from any to srcid ike passive esp tunnel from to any srcid A tcpdump on enc0 of both gateways shows the packets looping between the two gateways until ttl == 1. Can anybody tell me if this is supposed to work at all? Does anyone see an obvious flaw? I'm really lost at why the gateways add flows and routes in both directions... thx /markus
pf tag from ipsec in nat rules
Hi all Can tags from ipsec (defined in ipsec.conf) be referenced in pf nat rules (OBSD 4.1)? The idea is: ipsec.conf: ike esp from A to B tag "mytag" pf.conf: nat on $int_if tagged "mytag" -> ($int_if:1) nat on $int_if from !($int_if) -> ($int_if:0) If I use the "tagged" keyword, the second nat rule is used even for packets coming out of the ipsec tunnel. Replacing the "tagged" keyword with the actual IPs works: nat on $int_if from A to B -> ($int_if:1) Shouldn't this be possible with tags? thx for any pointer /markus
IPSec VPN gateway with only one interface
Hi all I'v looked through what documentation I could find, but didn't find this case mentioned, so I assumed it would work (which it doesn't): I have an OBSD 4.1 vpn gateway (A) with only one interface, over which the default route points out and over which the packets to forward through the tunnel arrive. The other gateway is a "regular" 2-interface OBSD 4.1 gateway (B). Here's the layout: Internal Net -- -- VPN gateway A & Internet & & VPN gateway B & Destination Net The tunnel seemingly does get created without any errors, but when packets pass through the tunnel, the remote gateway sends them right back. Also, on both gateways, 4 flows and 4 SADs get created, instead of 2 each, as I'd expect: # ipsecctl -s all FLOWS: flow esp in from to peer B> srcid dstid type use flow esp out from to peer B> srcid dstid type require flow esp in from to peer B> srcid dstid type use flow esp out from to peer B> srcid dstid type require SAD: esp tunnel from to spi 0xADEADBEEF auth hmac-sha2-256 enc aes esp tunnel from to spi 0xBDEADBEEF auth hmac-sha2-256 enc aes esp tunnel from to spi 0xCDEADBEEF auth hmac-sha2-256 enc aes esp tunnel from to spi 0xDDEADBEEF auth hmac-sha2-256 enc aes Thus, contradicting routes get added to the kernel routing tables: gateway B: Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 0 0 0 NAT router A/esp/use/in 0 0 0 NAT router A/esp/require/out 0 0 0 NAT router A/esp/use/in 0 0 0 NAT router A/esp/require/out ipsec.conf on A: ike esp from to peer srcid ike esp from to peer srcid ipsec.conf on B: ike passive esp tunnel from any to srcid ike passive esp tunnel from to any srcid A tcpdump on enc0 of both gateways shows the packets looping between the two gateways until ttl == 1. Can anybody tell me if this is supposed to work at all? Does anyone see an obvious flaw? I'm really lost at why the gateways add flows and routes in both directions... thx /markus
Re: isakmpd.policy not getting evaluated? SOLVED
Hi all For the archives: isakmpd.policy for authenticating users by their certificates' subjects (ASN1 DNs): KeyNote-Version: 2 Authenticator: "POLICY" Licensees: "DN:/C=CH/O=My Org/CN=My Org's CA Cert Subject" Conditions: app_domain == "IPsec policy" && doi == "ipsec" && esp_present =="yes" && esp_enc_alg !="null" && remote_id_type =="ASN1 DN" && ( remote_id=="/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org" || remote_id=="/C=CH/CN=Jane Doe/[EMAIL PROTECTED]/O=My Org" ) -> "true"; KeyNote-Version: 2 Authenticator: "POLICY" Licensees: "DN:/CN=Some other CA Cert Subject" Conditions: app_domain == "IPsec policy" && doi == "ipsec" && esp_present =="yes" && esp_enc_alg !="null" && remote_id_type =="ASN1 DN" && ( remote_id=="/CN=Some Body/[EMAIL PROTECTED]" || remote_id=="/CN=Any One/[EMAIL PROTECTED]" ) -> "true"; Don't put anything (comments, blank lines ...) before the first line. It will silently just not work. enjoy /markus
isakmpd.policy not getting evaluated? (was: Use certificate subjec/ASN1 t in ipsec.conf ?)
Hi again! I need to authenticate users in isakmpd by the subject DN of their x509 certificates. For this, I wrote isakmpd.policy as follows: KeyNote-Version: 2 Authenticator: "POLICY" Licensees: "DN:/C=CH/O=My Org/CN=My Org's CA Cert Subject" Conditions: app_domain == "IPsec policy" && doi == "ipsec" -> "true"; KeyNote-Version: 2 Authenticator: "DN:/C=CH/O=My Org/CN=My Org's CA Cert Subject" Licensees: "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org" Conditions: remote_id_type =="ASN1 DN" && remote_id == "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org" -> "true"; The accompanying ipsec.conf looks like: ike passive esp tunnel from any to 192.168.0/24 srcid gate.my.domain ike passive esp tunnel from 192.168.0/24 to any srcid gate.my.domain I can now establish an IPSec connection with any certificate issued by the CAs whose certificates lie in /etc/isakmpd/ca. But the restrictions I put in isakmpd.policy do not seem to get enforced, i.e. any certificate gets accepted, not only the configured one (/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org). So either my isakmpd.policy is wrong or it does not get evaluated. Does anybody have a pointer on how to restrict access to just the certificates I specify in isakmpd.policy? thx /markus Hans-Joerg Hoexer wrote: Hi, the Subject Alternative Name of your certificate will be used as phase 2 IDs, ie. that's what is sent. If you want to use the Subject Canonical Name, you have to additionlly provide an isakmpd.policy file and you have to run isakmpd without the "-K" option. See isakpmd.policy(5).
Re: Use certificate subjec/ASN1 t in ipsec.conf ?
s/isakmpd.conf/isakmpd.policy/g typo /m Markus Wernig wrote: > Hello & thanx for the swift reply > > Now i've read through the isakmpd.conf and keynote manpages, but, > honestly, I still don't know how to get this working. > > Here's the isakmpd.conf I came up with: > > KeyNote-Version: 2 > Authenticator: "POLICY" > Licensees: "DN:/C=CH/O=My Org/CN=My Org's CA Cert Subject" > Conditions: app_domain == "IPsec policy" && > doi == "ipsec" -> "true"; > > KeyNote-Version: 2 > Authenticator: "DN:/C=CH/O=My Org/CN=My Org's CA Cert Subject" > Licensees: "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org" > Conditions: remote_id_type =="ASN1 DN" && > remote_id == "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org" -> "true"; > > The last assertion is to be repeated for every allowed client with the > according subject. > > Additionally, I removed the reference to the client in ipsec.conf: > > ike passive esp tunnel from any to 192.168.0/24 srcid gate.my.domain > ike passive esp tunnel from 192.168.0/24 to any srcid gate.my.domain > > But still, no joy. > > Just to make sure that I don't head off in the wrong direction: Is this > basically how it's supposed to work? And could I additionally still use > the dstid USER_FQDN in ipsec.conf? Because I'd very much like to tag the > packets from each user-session and have user-based rules in pf.conf. > > thx /markus > > Hans-Joerg Hoexer wrote: >> Hi, >> >> the Subject Alternative Name of your certificate will be used as phase 2 >> IDs, ie. that's what is sent. If you want to use the Subject Canonical >> Name, you have to additionlly provide an isakmpd.policy file and you have >> to run isakmpd without the "-K" option. See isakpmd.policy(5). >> >> On Fri, Jul 20, 2007 at 07:09:18PM +0200, Markus Wernig wrote: >>> Hi all >>> >>> I'm setting up a OBSD 4.1 ipsec gateway, against which users will >>> authenticate using x509 certificates. They all use personal certificates >>> (key usage: digSig), which contains their user name and Email in the >>> subject. I need to authenticate them by the whole subject, but can't >>> seem to find out how.
Re: Use certificate subjec/ASN1 t in ipsec.conf ?
Hello & thanx for the swift reply Now i've read through the isakmpd.conf and keynote manpages, but, honestly, I still don't know how to get this working. Here's the isakmpd.conf I came up with: KeyNote-Version: 2 Authenticator: "POLICY" Licensees: "DN:/C=CH/O=My Org/CN=My Org's CA Cert Subject" Conditions: app_domain == "IPsec policy" && doi == "ipsec" -> "true"; KeyNote-Version: 2 Authenticator: "DN:/C=CH/O=My Org/CN=My Org's CA Cert Subject" Licensees: "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org" Conditions: remote_id_type =="ASN1 DN" && remote_id == "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org" -> "true"; The last assertion is to be repeated for every allowed client with the according subject. Additionally, I removed the reference to the client in ipsec.conf: ike passive esp tunnel from any to 192.168.0/24 srcid gate.my.domain ike passive esp tunnel from 192.168.0/24 to any srcid gate.my.domain But still, no joy. Just to make sure that I don't head off in the wrong direction: Is this basically how it's supposed to work? And could I additionally still use the dstid USER_FQDN in ipsec.conf? Because I'd very much like to tag the packets from each user-session and have user-based rules in pf.conf. thx /markus Hans-Joerg Hoexer wrote: > Hi, > > the Subject Alternative Name of your certificate will be used as phase 2 > IDs, ie. that's what is sent. If you want to use the Subject Canonical > Name, you have to additionlly provide an isakmpd.policy file and you have > to run isakmpd without the "-K" option. See isakpmd.policy(5). > > On Fri, Jul 20, 2007 at 07:09:18PM +0200, Markus Wernig wrote: >> Hi all >> >> I'm setting up a OBSD 4.1 ipsec gateway, against which users will >> authenticate using x509 certificates. They all use personal certificates >> (key usage: digSig), which contains their user name and Email in the >> subject. I need to authenticate them by the whole subject, but can't >> seem to find out how.
Use certificate subjec/ASN1 t in ipsec.conf ?
Hi all I'm setting up a OBSD 4.1 ipsec gateway, against which users will authenticate using x509 certificates. They all use personal certificates (key usage: digSig), which contains their user name and Email in the subject. I need to authenticate them by the whole subject, but can't seem to find out how. I can authenticate them (i.e. it works) if I just use the email address from the certificate as a filter in ipsec.conf along the lines: ike passive esp tunnel from any to 192.168.0/24 srcid gate.my.domain dstid [EMAIL PROTECTED] ike passive esp tunnel from 192.168.0/24 to any srcid gate.my.domain dstid [EMAIL PROTECTED] But what I need would look something like: ike passive esp tunnel from any to 192.168.0/24 srcid gate.my.domain dstid "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org" ike passive esp tunnel from 192.168.0/24 to any srcid gate.my.domain dstid "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org" When I configure this, with all possible variations of quoting and backslashes, isakmpd tells me in the log file: Jul 20 18:52:15 gate isakmpd[8707]: ipsec_validate_id_information: dubious ID information accepted Jul 20 18:52:15 gate isakmpd[8707]: ike_phase_1_recv_ID: received remote ID other than expected /C=CH/CN=John Apropos the subjectAltName: openssl tells me about the certificate: [...] X509v3 Subject Alternative Name: email:[EMAIL PROTECTED] [...] Is there a way to see what is getting sent? isakmpd does not seem to like the spaces in the /CN, is there a way to quote this for him? Is this possible at all? thx for any hint /markus
pckbc, pmsi_* errors, mouse not working on 4.1
Hi all I've upgraded OBSD on my notebook (hp-compaq nc7xxx series) from 3.8 to 4.1. All went well, except that when I start X, neither mouse nor keyboard are responding any more. Instead I get repeating error messages in syslog and on console: pmsi_enable: command error pckbc: command timeout pmsi_disable: command error Google suggested that I try to enable ACPI, which I did via UKC. But as soon as I quit UKC, the machine hard resets and starts over. The same happens when I edit a kernel with config and boot from it: immediate reset and reboot. Is there any other approach to solving the mouse problem? If no: is there any way to find out what is killing the kernel with acpi enabled? thx /markus
encap routes
Hi all Does anybody know what the status of the problem described here is? http://archives.neohapsis.com/archives/openbsd/2005-12/0327.html The problem is that OBSD IPSec gateways will reject packets they have an SA for if they don't have an IP route to the destination (any route, default gw will suffice). Is it planned to be change the default behaviour? thx /markus
Re: host to host ipsec link
Stuart Henderson wrote:
> On 2007/04/16 15:06, Markus Wernig wrote:
> ...
>
> the error message does come from sasyncd.
>
>> sharedkey [32byte RSA key]
>
> the other config lines are ok, the error must be here.
>
aarrgg ... and indeed it was. I had produced that
string with # openssl rand 32 | perl -pe 's/./unpack("H1",$&)/ges' - as
I always do - but must have botched something on the way ... thx
/m
Re: CARP access outside a subnet
Hi I'm not sure about carp supporting addresses in other subnets than the physical one. But to debug this further: - what does tcpdump -e -n -i xennet1 show on the routers when you ping the virtual interface from outside the lan? - is the route for the egress path the same as for the ingress path (i.e. does the route back to the accessing device point out over the same interface (xennet1) that the packets come in on)? - maybe your next hop router does not receive the virtual mac address. check the arp table on the next hop router. - what is the error message when pinging from the outside and who generates it? krgds /markus david l goodrich wrote: > I'm sorry to bring this up again, since it didn't get any responses the > first time. > > But I haven't had any luck on my own, and was hoping someone might have an > idea. > > > On 4/9/07, david l goodrich <[EMAIL PROTECTED]> wrote: >> I have two hosts in a CARP group. >> >> on router-meus-cd1, i have the following network configuration: >> >> router-meus-cd1# ifconfig xennet1 >> xennet1: >> flags=8963 mtu >> 1500 >> capabilities=2800 >> enabled=0 >> address: 00:16:3e:71:ef:6f >> inet 10.10.10.2 netmask 0xff00 broadcast 10.10.10.255 >> inet6 fe80::216:3eff:fe71:ef6f%xennet1 prefixlen 64 scopeid 0x4 >> router-meus-cd1# ifconfig carp216 >> carp216: flags=8843 mtu 1500 >> carp: MASTER carpdev xennet1 vhid 216 advbase 1 advskew 0 >> address: 00:00:5e:00:01:d8 >> inet 216.51.247.30 netmask 0xfff8 broadcast 216.51.247.31 >> router-meus-cd1# >> >> on router-meus-cn1, i have a similar configuration: >> >> router-meus-cn1# ifconfig xennet1 >> xennet1: >> flags=8963 mtu >> 1500 >> capabilities=2800 >> enabled=0 >> address: 00:16:3e:04:d3:e0 >> inet 10.10.10.1 netmask 0xff00 broadcast 10.10.10.255 >> inet6 fe80::216:3eff:fe04:d3e0%xennet1 prefixlen 64 scopeid 0x4 >> router-meus-cn1# ifconfig carp216 >> carp216: flags=8843 mtu 1500 >> carp: BACKUP carpdev xennet1 vhid 216 advbase 1 advskew >> 0216.51.247.30 >> >> address: 00:00:5e:00:01:d8 >> inet 216.51.247.30 netmask 0xfff8 broadcast 216.51.247.31 >> router-meus-cn1# >> >> >> The default route, nameservers, etc are all set correctly. >> >> CARP works great on the 216.51.247.24/29 subnet, from any machine on that >> subnet I can ping 216.51.247.30. >> >> When I get outside the subnet, I can't ping the address or ssh to it. >> >> Does anyone have some insight into why this is happening? >> >> Thanks >> --david
Re: host to host ipsec link
Mathieu Sauve-Frankel wrote: > Currently the order in which isakmpd, ipsecctl and sasyncd need to be > invoked in order for everything to work is pretty rigid. > > # isakmpd -KS > # ipsecctl -f /etc/ipsec.conf > # sasyncd > > First start isakmpd with -KS, this brings up isakmpd in passive mode, > isakmpd won't initiate any IKE traffic until an sasyncd process sets > isakmpd to "active" mode through the fifo, you can do this by hand by > issuing "M active" into the fifo with echo. Don't forget to load your rules > before you issue this command. > > If you are not going to use sasyncd, don't use -S. > Hi & thx for the insight. I now realize that the problem is caused by sasyncd not starting. It terminates immediately with the message "config: syntax error". Unfortunately it's not a syntax error in the sasyncd.conf file, but the error really seems to stem from the program "config" that seems to get called in the process of invoking sasyncd ... between stat-ing the config file and parsing it, as I would suppose, because sasyncd will not complain about real, intentional syntax errors in the file or an empty file, but will bail out on wrong file permissions. I have copied over sasyncd.conf from a working installation and changed the sharedkey and peer parameters. But config: syntax error hits me even if I empty the file (which should produce errors about missing sharedkeys and the like) Just to go sure, here's the file: # cat /etc/sasyncd.conf interface carp1 flushmode sync listen on xl0 port 5000 sharedkey [32byte RSA key] peer 10.111.1.2 Plus, "syntax error" does not appear in the sasyncd binary with strings or source code. Sorry again if I'm missing something obvious. /markus
Re: host to host ipsec link
Hello! Renaud Allard wrote: > Markus Wernig wrote: >> Renaud Allard wrote: >> >>> Did you verify that isakmpd is running? >> Yes. It runs as follows: >> >> 11967 ?? Is 0:00.05 isakmpd: monitor [priv] (isakmpd) >> 18753 ?? I 0:01.40 isakmpd -S -K -f /var/run/isakmpd.fifo >> >> > -S is used for redundant setups. Did you try without that flag? Infact, this resolves the problem! Thanks a lot. Yet, it brings me to the next problem that I didn't set the -S flag, but /etc/rc does so automatically because of sasyncd, which will be used on those boxes in a further step. (The far goal being two firewall clusters encrypting traffic between the networks behind them, and encrypting traffic between the two members respectively.) krgds /markus
Re: host to host ipsec link
Renaud Allard wrote: > Maybe also try on both firewalls: > > cd /etc/isakmpd && ln -s private/local.pub . > > Then restart isakmpd and reload the rules. > Hi Tried that as well ... still no go. I have disabled pf for setting the enc up. I suppose, that doesn't matter, does it? krgds /markus
Re: host to host ipsec link
Renaud Allard wrote: > Did you verify that isakmpd is running? Yes. It runs as follows: 11967 ?? Is 0:00.05 isakmpd: monitor [priv] (isakmpd) 18753 ?? I 0:01.40 isakmpd -S -K -f /var/run/isakmpd.fifo
Re: host to host ipsec link
Renaud Allard wrote: > It seems you just forgot to load your rules. > Just add "ipsecctl -f /etc/ipsec.conf" in the rc.local of both your > firewalls and everything should just work fine. Hi I've tried to load the rules by hand with "ipsecctl -f /etc/ipsec.conf" - to no avail. On the other hand I seemed to understand that with "ipsec=YES" in /etc/rc.conf.local this was done automatically. I've tried it nevertheless, unfortunately no joy ;-) thx /markus
host to host ipsec link
Hello all I am trying a - what I think is - simple ipsec setup. The point is to ipsec-encrypt all traffic between a pair of firewalls (gateA and gateB, both OBSD 4.0), in order to send pfsync traffic over the encrypted link. Although having read through ipsec, ipsec.conf, isakmpd and friend's manpages, I get stuck on the same point. Obviously I'm missing some important point. gateA:/etc/ipsec.conf: ike esp from 10.111.1.1 to 10.111.1.2 gateB:/etc/ipsec.conf: ike esp from 10.111.1.2 to 10.111.1.1 private and public key created by rc on initial boot in /etc/isakmpd/private on both machines. copied gateA's /etc/isakmpd/private/local.pub to gateB:/etc/isakmpd/pubkeys/ipv4/10.111.1.1 and gateB's /etc/isakmpd/private/local.pub to gateA:/etc/isakmpd/pubkeys/ipv4/10.111.1.2 /etc/rc.conf.local ipsec=YES isakmpd_flags="-K -f /var/run/isakmpd.fifo" I thought that with this, automatic keying would setup a tunnel between 10.111.1.1 and 10.111.1.2 on system start. But nothing of the like happens, not even a single IKE package is exchanged between the two hosts. Consequently, when pinging from 10.111.1.1 to 10.111.1.2 or vice versa, the packets go over the wire in the clear. I'm sorry, but I just can't see what I'm missing. Would anybody have a pointer for a lost soul? thx /markus
health check for members of round-robin group
Hi everybody! I am looking at implementing a round-robin load-balanced group of servers behind an OBSD firewall. The pf commands would run along the lines [...] table persist file /etc/pf.serverlist rdr on $ext_if proto tcp from any to $virtual_ip port 80 \ -> round-robin [...] Now the question is, what happens if one of the servers in /etc/pf.serverlist goes down? I suppose, each nth connection is still forwarded to it. Apparently, I need to do some sort of health check periodically (say, every 60 seconds) and remove the faulty server from and from /etc/pf.serverlist (in case the fw gets reloaded while the server is still down). Now just before I go and hack away at that health check crontab script: Is anybody aware if such a check mechanism already has been implemented, maybe in some other form? thx /markus
Re: Carp on trunk is working since 3.9
Reyk Floeter wrote: > > retry with 3.9 OK, thanks and sorry for the noise. Works now, but now another thing keeps popping up: I've set the trunkproto to failover on both boxes. Now when I pull the master nic's cable, the time it takes for the other one to take over varies from around 5 to 8 seconds on failover and between 1 and around 8 seconds on failback (reinsertion). Is this expected behaviour? Or could there be one of the dumb switches interfering? What would the "normal" failover time in this scenario be? The layout would be as follows (NIC 1 set to master): |NIC 1 |-| |- Test Host | BOX A| | Switch A | |NIC 2 | | | \ / \ / | \ /| \ / | X | / \ | / \| / \ |NIC 1 |/ \| | | BOX B| | Switch B | |NIC 2 |-| | Test host is pinging trunk0 (NIC 1, NIC 2) on each box. If the cable into NIC 1 is pulled, I get the above timeouts before failover. If I do # ifconfig NIC1 down, traffic stops alltogether and no failover occurs, regardless of what switch the test host is plugged into. The status of trunk0 changes to "no carrier", while trunkport NIC1 drops to "master" and NIC2 remains as "active". Is this also expected? thx /markus
