]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/blob - share/man/man4/pfsync.4
sys/{x86,amd64}: remove one of doubled ;s
[FreeBSD/FreeBSD.git] / share / man / man4 / pfsync.4
1 .\"     $OpenBSD: pfsync.4,v 1.28 2009/02/17 10:05:18 dlg Exp $
2 .\"
3 .\" Copyright (c) 2002 Michael Shalayeff
4 .\" Copyright (c) 2003-2004 Ryan McBride
5 .\" All rights reserved.
6 .\"
7 .\" Redistribution and use in source and binary forms, with or without
8 .\" modification, are permitted provided that the following conditions
9 .\" are met:
10 .\" 1. Redistributions of source code must retain the above copyright
11 .\"    notice, this list of conditions and the following disclaimer.
12 .\" 2. Redistributions in binary form must reproduce the above copyright
13 .\"    notice, this list of conditions and the following disclaimer in the
14 .\"    documentation and/or other materials provided with the distribution.
15 .\"
16 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
17 .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
18 .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
19 .\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
20 .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
21 .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF MIND,
22 .\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
23 .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
24 .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
25 .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
26 .\"
27 .\" $FreeBSD$
28 .\"
29 .Dd December 6, 2018
30 .Dt PFSYNC 4
31 .Os
32 .Sh NAME
33 .Nm pfsync
34 .Nd packet filter state table sychronisation interface
35 .Sh SYNOPSIS
36 .Cd "device pfsync"
37 .Sh DESCRIPTION
38 The
39 .Nm
40 interface is a pseudo-device which exposes certain changes to the state
41 table used by
42 .Xr pf 4 .
43 State changes can be viewed by invoking
44 .Xr tcpdump 1
45 on the
46 .Nm
47 interface.
48 If configured with a physical synchronisation interface,
49 .Nm
50 will also send state changes out on that interface,
51 and insert state changes received on that interface from other systems
52 into the state table.
53 .Pp
54 By default, all local changes to the state table are exposed via
55 .Nm .
56 State changes from packets received by
57 .Nm
58 over the network are not rebroadcast.
59 Updates to states created by a rule marked with the
60 .Ar no-sync
61 keyword are ignored by the
62 .Nm
63 interface (see
64 .Xr pf.conf 5
65 for details).
66 .Pp
67 The
68 .Nm
69 interface will attempt to collapse multiple state updates into a single
70 packet where possible.
71 The maximum number of times a single state can be updated before a
72 .Nm
73 packet will be sent out is controlled by the
74 .Ar maxupd
75 parameter to ifconfig
76 (see
77 .Xr ifconfig 8
78 and the example below for more details).
79 The sending out of a
80 .Nm
81 packet will be delayed by a maximum of one second.
82 .Sh NETWORK SYNCHRONISATION
83 States can be synchronised between two or more firewalls using this
84 interface, by specifying a synchronisation interface using
85 .Xr ifconfig 8 .
86 For example, the following command sets fxp0 as the synchronisation
87 interface:
88 .Bd -literal -offset indent
89 # ifconfig pfsync0 syncdev fxp0
90 .Ed
91 .Pp
92 By default, state change messages are sent out on the synchronisation
93 interface using IP multicast packets to the 224.0.0.240 group address.
94 An alternative destination address for
95 .Nm
96 packets can be specified using the
97 .Ic syncpeer
98 keyword.
99 This can be used in combination with
100 .Xr ipsec 4
101 to protect the synchronisation traffic.
102 In such a configuration, the syncdev should be set to the
103 .Xr enc 4
104 interface, as this is where the traffic arrives when it is decapsulated,
105 e.g.:
106 .Bd -literal -offset indent
107 # ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0
108 .Ed
109 .Pp
110 It is important that the pfsync traffic be well secured
111 as there is no authentication on the protocol and it would
112 be trivial to spoof packets which create states, bypassing the pf ruleset.
113 Either run the pfsync protocol on a trusted network \- ideally a network
114 dedicated to pfsync messages such as a crossover cable between two firewalls,
115 or specify a peer address and protect the traffic with
116 .Xr ipsec 4 .
117 .Pp
118 .Nm
119 has the following
120 .Xr sysctl 8
121 tunables:
122 .Bl -tag -width ".Va net.pfsync"
123 .It Va net.pfsync.carp_demotion_factor
124 Value added to
125 .Va net.inet.carp.demotion
126 while
127 .Nm
128 tries to perform its bulk update.
129 See
130 .Xr carp 4
131 for more information.
132 Default value is 240.
133 .It Va net.pfsync.pfsync_buckets
134 The number of
135 .Nm
136 buckets.
137 This affects the performance and memory tradeoff.
138 Defaults to twice the number of CPUs.
139 Change only if benchmarks show this helps on your workload.
140 .El
141 .Sh EXAMPLES
142 .Nm
143 and
144 .Xr carp 4
145 can be used together to provide automatic failover of a pair of firewalls
146 configured in parallel.
147 One firewall will handle all traffic until it dies, is shut down, or is
148 manually demoted, at which point the second firewall will take over
149 automatically.
150 .Pp
151 Both firewalls in this example have three
152 .Xr sis 4
153 interfaces.
154 sis0 is the external interface, on the 10.0.0.0/24 subnet; sis1 is the
155 internal interface, on the 192.168.0.0/24 subnet; and sis2 is the
156 .Nm
157 interface, using the 192.168.254.0/24 subnet.
158 A crossover cable connects the two firewalls via their sis2 interfaces.
159 On all three interfaces, firewall A uses the .254 address, while firewall B
160 uses .253.
161 The interfaces are configured as follows (firewall A unless otherwise
162 indicated):
163 .Pp
164 Interfaces configuration in
165 .Pa /etc/rc.conf :
166 .Bd -literal -offset indent
167 network_interfaces="lo0 sis0 sis1 sis2"
168 ifconfig_sis0="10.0.0.254/24"
169 ifconfig_sis0_alias0="inet 10.0.0.1/24 vhid 1 pass foo"
170 ifconfig_sis1="192.168.0.254/24"
171 ifconfig_sis1_alias0="inet 192.168.0.1/24 vhid 2 pass bar"
172 ifconfig_sis2="192.168.254.254/24"
173 pfsync_enable="YES"
174 pfsync_syncdev="sis2"
175 .Ed
176 .Pp
177 .Xr pf 4
178 must also be configured to allow
179 .Nm
180 and
181 .Xr carp 4
182 traffic through.
183 The following should be added to the top of
184 .Pa /etc/pf.conf :
185 .Bd -literal -offset indent
186 pass quick on { sis2 } proto pfsync keep state (no-sync)
187 pass on { sis0 sis1 } proto carp keep state (no-sync)
188 .Ed
189 .Pp
190 It is preferable that one firewall handle the forwarding of all the traffic,
191 therefore the
192 .Ar advskew
193 on the backup firewall's
194 .Xr carp 4
195 vhids should be set to something higher than
196 the primary's.
197 For example, if firewall B is the backup, its
198 carp1 configuration would look like this:
199 .Bd -literal -offset indent
200 ifconfig_sis1_alias0="inet 192.168.0.1/24 vhid 2 pass bar advskew 100"
201 .Ed
202 .Pp
203 The following must also be added to
204 .Pa /etc/sysctl.conf :
205 .Bd -literal -offset indent
206 net.inet.carp.preempt=1
207 .Ed
208 .Sh SEE ALSO
209 .Xr tcpdump 1 ,
210 .Xr bpf 4 ,
211 .Xr carp 4 ,
212 .Xr enc 4 ,
213 .Xr inet 4 ,
214 .Xr inet6 4 ,
215 .Xr ipsec 4 ,
216 .Xr netintro 4 ,
217 .Xr pf 4 ,
218 .Xr pf.conf 5 ,
219 .Xr protocols 5 ,
220 .Xr rc.conf 5 ,
221 .Xr ifconfig 8
222 .Sh HISTORY
223 The
224 .Nm
225 device first appeared in
226 .Ox 3.3 .
227 It was first imported to
228 .Fx 5.3 .
229 .Pp
230 The
231 .Nm
232 protocol and kernel implementation were significantly modified in
233 .Fx 9.0 .
234 The newer protocol is not compatible with older one and will not interoperate
235 with it.