Re: Is PFSync over IPSec still broken?
Hi, Pfsync + ipsec setup IS broken. Links: http://marc.info/?l=openbsd-misc&m=143463803906528&w=2 Patch to manual page has been applied: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/man/man4/pfsync.4.diff?r1=1.32&r2=1.33 Please remove example of this setup: "2. Use the ifconfig(8) syncpeer option (see below) so that updates are unicast directly to the peer, then configure ipsec(4) between the hosts to secure the pfsync(4) traffic." from webpage: http://www.openbsd.org/faq/pf/carp.html Thanks Lukasz W dniu 26.06.2015 o 09:45, Jason McIntyre pisze: > On Fri, Jun 26, 2015 at 09:05:08AM +0200, ??ukasz Czarniecki wrote: >> W dniu 25.06.2015 o 12:19, Jason McIntyre pisze: >> > Please fix this bug or remove this example from documentation. > For me this setup is broken since 2011. > http://marc.info/?l=openbsd-misc&m=130624207811609&w=2 > > Nobody cares or nobody uses? >>> >>> i've just committed something similar to the diff below, though i >>> commented out text rather than removing it. >>> >>> thanks for the diff, >>> jmc >> >> >> Thank you. >> Please also remove this line: >> >> 2. Use the ifconfig(8) syncpeer option (see below) so that updates are >> unicast directly to the peer, then configure ipsec(4) between the hosts >> to secure the pfsync(4) traffic. >> >> from http://www.openbsd.org/faq/pf/carp.html >> > > i'm in less well known territory here... > > cc'ing dlg again to ok, and nick to please make the change if he feels > it's right - www pages have their own logic. > > jmc
Re: Is PFSync over IPSec still broken?
W dniu 25.06.2015 o 12:19, Jason McIntyre pisze: >>> Please fix this bug or remove this example from documentation. >>> For me this setup is broken since 2011. >>> http://marc.info/?l=openbsd-misc&m=130624207811609&w=2 >>> >>> Nobody cares or nobody uses? >> > > i've just committed something similar to the diff below, though i > commented out text rather than removing it. > > thanks for the diff, > jmc Thank you. Please also remove this line: 2. Use the ifconfig(8) syncpeer option (see below) so that updates are unicast directly to the peer, then configure ipsec(4) between the hosts to secure the pfsync(4) traffic. from http://www.openbsd.org/faq/pf/carp.html
Re: Is PFSync over IPSec still broken?
On Sun, Jun 21, 2015 at 03:20:34PM +0200, ??ukasz Czarniecki wrote: > W dniu 2015-06-18 o 17:30, ??ukasz Czarniecki pisze: > >> It's still broken because as mentioned at the end of the thread you > >> linked IPsec state gets replicated to the peer and this is causing > >> the "replayed" packets you're seeing. The peer already has IPsec state > >> in memory (created by pfsync replication) which matches incoming IPsec > >> packets directed at it. So the peer's IPsec stack ends up believing it's > >> seen the incoming packet already (while it actually hasn't seen the packet, > >> it just copied the IPsec state from the sender) and drops the packet. > >> > >> No good fix is known as of yet. I've given up on it for now. > >> > > > > Please fix this bug or remove this example from documentation. > > For me this setup is broken since 2011. > > http://marc.info/?l=openbsd-misc&m=130624207811609&w=2 > > > > Nobody cares or nobody uses? > i've just committed something similar to the diff below, though i commented out text rather than removing it. thanks for the diff, jmc > # diff -u -p /usr/src/share/man/man4/pfsync.4 ./pfsync.4 > --- /usr/src/share/man/man4/pfsync.4Sun Feb 1 09:33:48 2015 > +++ ./pfsync.4 Sun Jun 21 15:14:00 2015 > @@ -112,24 +112,13 @@ An alternative destination address for > packets can be specified using the > .Ic syncpeer > keyword. > -This can be used in combination with > -.Xr ipsec 4 > -to protect the synchronisation traffic. > -In such a configuration, the syncdev should be set to the > -.Xr enc 4 > -interface, as this is where the traffic arrives when it is decapsulated, > -e.g.: > -.Bd -literal -offset indent > -# ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0 > .Ed > .Pp > It is important that the pfsync traffic be well secured > as there is no authentication on the protocol and it would > be trivial to spoof packets which create states, bypassing the pf ruleset. > -Either run the pfsync protocol on a trusted network \- ideally a network > -dedicated to pfsync messages such as a crossover cable between two > firewalls, > -or specify a peer address and protect the traffic with > -.Xr ipsec 4 . > +Run the pfsync protocol on a trusted network \- ideally a network > +dedicated to pfsync messages such as a crossover cable between two > firewalls. > .Sh EXAMPLES > .Nm > and > @@ -219,10 +208,8 @@ net.inet.carp.preempt=1 > .Sh SEE ALSO > .Xr bpf 4 , > .Xr carp 4 , > -.Xr enc 4 , > .Xr inet 4 , > .Xr inet6 4 , > -.Xr ipsec 4 , > .Xr netintro 4 , > .Xr pf 4 , > .Xr hostname.if 5 , > @@ -244,3 +231,8 @@ protocol and kernel implementation were significantly > and > .Ox 4.5 . > The two protocols are incompatible and will not interoperate. > +.Sh BUGS > +The > +.Nm > +protocol does not work over IPsec tunnels. > +
Re: Is PFSync over IPSec still broken?
W dniu 2015-06-18 o 17:30, Łukasz Czarniecki pisze: >> It's still broken because as mentioned at the end of the thread you >> linked IPsec state gets replicated to the peer and this is causing >> the "replayed" packets you're seeing. The peer already has IPsec state >> in memory (created by pfsync replication) which matches incoming IPsec >> packets directed at it. So the peer's IPsec stack ends up believing it's >> seen the incoming packet already (while it actually hasn't seen the packet, >> it just copied the IPsec state from the sender) and drops the packet. >> >> No good fix is known as of yet. I've given up on it for now. >> > > Please fix this bug or remove this example from documentation. > For me this setup is broken since 2011. > http://marc.info/?l=openbsd-misc&m=130624207811609&w=2 > > Nobody cares or nobody uses? # diff -u -p /usr/src/share/man/man4/pfsync.4 ./pfsync.4 --- /usr/src/share/man/man4/pfsync.4Sun Feb 1 09:33:48 2015 +++ ./pfsync.4 Sun Jun 21 15:14:00 2015 @@ -112,24 +112,13 @@ An alternative destination address for packets can be specified using the .Ic syncpeer keyword. -This can be used in combination with -.Xr ipsec 4 -to protect the synchronisation traffic. -In such a configuration, the syncdev should be set to the -.Xr enc 4 -interface, as this is where the traffic arrives when it is decapsulated, -e.g.: -.Bd -literal -offset indent -# ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0 .Ed .Pp It is important that the pfsync traffic be well secured as there is no authentication on the protocol and it would be trivial to spoof packets which create states, bypassing the pf ruleset. -Either run the pfsync protocol on a trusted network \- ideally a network -dedicated to pfsync messages such as a crossover cable between two firewalls, -or specify a peer address and protect the traffic with -.Xr ipsec 4 . +Run the pfsync protocol on a trusted network \- ideally a network +dedicated to pfsync messages such as a crossover cable between two firewalls. .Sh EXAMPLES .Nm and @@ -219,10 +208,8 @@ net.inet.carp.preempt=1 .Sh SEE ALSO .Xr bpf 4 , .Xr carp 4 , -.Xr enc 4 , .Xr inet 4 , .Xr inet6 4 , -.Xr ipsec 4 , .Xr netintro 4 , .Xr pf 4 , .Xr hostname.if 5 , @@ -244,3 +231,8 @@ protocol and kernel implementation were significantly and .Ox 4.5 . The two protocols are incompatible and will not interoperate. +.Sh BUGS +The +.Nm +protocol does not work over IPsec tunnels. +
Re: Is PFSync over IPSec still broken?
> It's still broken because as mentioned at the end of the thread you > linked IPsec state gets replicated to the peer and this is causing > the "replayed" packets you're seeing. The peer already has IPsec state > in memory (created by pfsync replication) which matches incoming IPsec > packets directed at it. So the peer's IPsec stack ends up believing it's > seen the incoming packet already (while it actually hasn't seen the packet, > it just copied the IPsec state from the sender) and drops the packet. > > No good fix is known as of yet. I've given up on it for now. > Please fix this bug or remove this example from documentation. For me this setup is broken since 2011. http://marc.info/?l=openbsd-misc&m=130624207811609&w=2 Nobody cares or nobody uses? http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/pfsync.4?query=pfsync This can be used in combination with ipsec(4) to protect the synchronisation traffic. In such a configuration, the syncdev should be set to the enc(4) interface, as this is where the traffic arrives when it is decapsulated, e.g.: # ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0 Lukasz
Re: Is PFSync over IPSec still broken?
On Thu, Jun 18, 2015 at 03:44:24PM +0200, Łukasz Czarniecki wrote: > Hi, > > I have the same problem described here: > > http://openbsd-archive.7691.n7.nabble.com/pfsync-over-ipsec-is-broken-td257496.html#a257681 > > My system is 5.7 i386 > > I have keep state (no-sync) on all local terminated traffic (including > ipsec udp/esp) and set skip on enc in pf.conf. > > I can see only outgoing PFSync traffic (no incoming) with increasing > replayed packets received on both firewalls. > > netstat -p esp -s | grep replay > 304 possibly replayed packets received > > Does anyone have working PFSync over IPsec Setup? > > Lukasz It's still broken because as mentioned at the end of the thread you linked IPsec state gets replicated to the peer and this is causing the "replayed" packets you're seeing. The peer already has IPsec state in memory (created by pfsync replication) which matches incoming IPsec packets directed at it. So the peer's IPsec stack ends up believing it's seen the incoming packet already (while it actually hasn't seen the packet, it just copied the IPsec state from the sender) and drops the packet. No good fix is known as of yet. I've given up on it for now.
Is PFSync over IPSec still broken?
Hi, I have the same problem described here: http://openbsd-archive.7691.n7.nabble.com/pfsync-over-ipsec-is-broken-td257496.html#a257681 My system is 5.7 i386 I have keep state (no-sync) on all local terminated traffic (including ipsec udp/esp) and set skip on enc in pf.conf. I can see only outgoing PFSync traffic (no incoming) with increasing replayed packets received on both firewalls. netstat -p esp -s | grep replay 304 possibly replayed packets received Does anyone have working PFSync over IPsec Setup? Lukasz
