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.4 Sun 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. +
