-
Notifications
You must be signed in to change notification settings - Fork 18
/
firewall.xml
246 lines (226 loc) · 9.59 KB
/
firewall.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
<?xml version="1.0" encoding="UTF-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="firewall">
<title>Firewall rules</title>
<sect1 xml:id="firewall-overview">
<title>Overview of firewall ports</title>
<para><xref linkend="firewall-rules-summary-ipv4"/> and
<xref linkend="firewall-rules-summary-ipv6"/> list each firewall rule
that is required for the test addresses described in
<xref linkend="intro-example-network"/>.</para>
<table xml:id="firewall-rules-summary-ipv4">
<title>Firewall rules summary</title>
<tgroup cols="6">
<colspec colname="c1" colnum="1" colwidth="1*" />
<colspec colname="c2" colnum="2" colwidth="0.4*" />
<colspec colname="c3" colnum="3" colwidth="0.4*" />
<colspec colname="c4" colnum="4" colwidth="0.4*" />
<colspec colname="c5" colnum="5" colwidth="1.8*" />
<colspec colname="c6" colnum="6" colwidth="0.4*" />
<thead>
<row>
<entry align="center">Purpose</entry>
<entry align="center">IP Protocol</entry>
<entry align="center">Source Addr</entry>
<entry align="center">Source Port</entry>
<entry align="center">Dest Addr</entry>
<entry align="center">Dest Port</entry>
</row>
</thead>
<tbody>
<row>
<entry>RTP media (both SIP and XMPP, audio and video)</entry>
<entry>UDP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>198.51.100.19</literal></entry>
<entry>49152 to 65535</entry>
</row>
<row>
<entry>TURN session control</entry>
<entry>UDP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>198.51.100.19</literal>, <literal>198.51.100.20</literal></entry>
<entry>3478</entry>
</row>
<row>
<entry>STUN NAT discovery (RFC 3489)</entry>
<entry>UDP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>198.51.100.19</literal>, <literal>198.51.100.20</literal></entry>
<entry>3479</entry>
</row>
<row>
<entry>SIP signalling</entry>
<entry>TCP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>198.51.100.19</literal></entry>
<entry>5061</entry>
</row>
<row>
<entry>SIP over WebSocket (TLS)</entry>
<entry>TCP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>198.51.100.19</literal></entry>
<entry>443</entry>
</row>
<row>
<entry>XMPP Server signalling</entry>
<entry>TCP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>198.51.100.19</literal></entry>
<entry>5222</entry>
</row>
<row>
<entry>XMPP Client signalling</entry>
<entry>TCP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>198.51.100.19</literal></entry>
<entry>5269</entry>
</row>
</tbody>
</tgroup>
</table>
<table xml:id="firewall-rules-summary-ipv6">
<title>Firewall rules summary (IPv6)</title>
<tgroup cols="6">
<colspec colname="c1" colnum="1" colwidth="1*" />
<colspec colname="c2" colnum="2" colwidth="0.4*" />
<colspec colname="c3" colnum="3" colwidth="0.4*" />
<colspec colname="c4" colnum="4" colwidth="0.4*" />
<colspec colname="c5" colnum="5" colwidth="1.8*" />
<colspec colname="c6" colnum="6" colwidth="0.4*" />
<thead>
<row>
<entry align="center">Purpose</entry>
<entry align="center">IP Protocol</entry>
<entry align="center">Source Addr</entry>
<entry align="center">Source Port</entry>
<entry align="center">Dest Addr</entry>
<entry align="center">Dest Port</entry>
</row>
</thead>
<tbody>
<row>
<entry>RTP media (both SIP and XMPP, audio and video)</entry>
<entry>UDP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>2001:DB8:1000:2000::19</literal></entry>
<entry>49152 to 65535</entry>
</row>
<row>
<entry>TURN session control</entry>
<entry>UDP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>2001:DB8:1000:2000::19</literal></entry>
<entry>3478</entry>
</row>
<row>
<entry>SIP signalling</entry>
<entry>TCP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>2001:DB8:1000:2000::19</literal></entry>
<entry>5061</entry>
</row>
<row>
<entry>SIP over WebSocket (TLS)</entry>
<entry>TCP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>2001:DB8:1000:2000::19</literal></entry>
<entry>443</entry>
</row>
<row>
<entry>XMPP Server signalling</entry>
<entry>TCP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>2001:DB8:1000:2000::19</literal></entry>
<entry>5222</entry>
</row>
<row>
<entry>XMPP Client signalling</entry>
<entry>TCP</entry>
<entry>Any</entry>
<entry>Any</entry>
<entry><literal>2001:DB8:1000:2000::19</literal></entry>
<entry>5269</entry>
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 xml:id="firewall-nat-considerations">
<title>NAT considerations</title>
<para>Many networks use NAT to minimize cost, conserve public IP
addresses and to avoid direct routing from the public Internet.
RTC applications can work in a NAT environment, however, there are some
points to be aware of.</para>
<para>One common technique used for web servers involves hosting the
public IP address on the firewall and creating a port forwarding rule
redirecting all incoming connections to the internal IP address of a
web server. This approach works for some types of services, such as
HTTP, but it does not work for all types of RTC traffic. In particular,
it is essential that the TURN server process runs on a host with two
public IP addresses. A SIP server may work with port forwarding, but
care needs to be taken to ensure the record-route URI matches the
external IP address. Using SIP over TLS and SIP over WebSockets with
port forwarding is more likely to work than trying to port-forward SIP
over UDP traffic.</para>
<para>The TURN server does not need to have an IP address on the
private network but it does need to be routable from the private network.
The TURN server could be hosted in a DMZ or even using an external
hosting provider.</para>
<para>If you choose to operate a SIP Session Border Controller (SBC),
it will probably need to have both a public IP address and a private
IP address.</para>
</sect1>
<sect1 xml:id="firewall-example-iptables">
<title>Setup with <code>iptables</code> on Linux</title>
<para><xref linkend="firewall-setup-iptables-example"/> provides a basic
example for Linux firewalls using <code>iptables</code>. If using a
firewall framework like <emphasis>Shorewall</emphasis> then please
consult the relevant documentation to open the same ports.</para>
<example xml:id="firewall-setup-iptables-example">
<title>Firewall setup with <code>iptables</code></title>
<programlisting format="linespecific">iptables -I INPUT -p udp -d 198.51.100.19 --dport 3478 -j ACCEPT
iptables -I INPUT -p udp -d 198.51.100.20 --dport 3478 -j ACCEPT
iptables -I INPUT -p udp -d 198.51.100.19 \
--dport 49152:65535 -j ACCEPT
iptables -A INPUT -p tcp -d 198.51.100.19 --dport 5061 -j ACCEPT
iptables -A INPUT -p tcp -d 198.51.100.19 --dport 5222 -j ACCEPT
iptables -A INPUT -p tcp -d 198.51.100.19 --dport 5269 -j ACCEPT
ip6tables -I INPUT -p udp -d 2001:DB8:1000:2000::19 \
--dport 3478 -j ACCEPT
ip6tables -I INPUT -p udp -d 2001:DB8:1000:2000::19 \
--dport 49152:65535 -j ACCEPT
ip6tables -A INPUT -p tcp -d 2001:DB8:1000:2000::19 \
--dport 5061 -j ACCEPT
ip6tables -A INPUT -p tcp -d 2001:DB8:1000:2000::19 \
--dport 5222 -j ACCEPT
ip6tables -A INPUT -p tcp -d 2001:DB8:1000:2000::19 \
--dport 5269 -j ACCEPT</programlisting>
</example>
<para>It is highly recommended that the firewall rules for RTP packets
are placed at the beginning of the chain, as these packets are time
sensitive and over 99% of the RTC traffic is carried in the RTP packets.
Putting them lower in the chain will mean that the CPU does more work
evaluating each packet before it finds the matching rule. That would
lead to wasted CPU cycles and potential latency or congestion issues for
all real-time applications on the server.</para>
<para>When you deploy additional RTC applications (such as Asterisk or
FreeSWITCH) behind the firewall, you may want to allow RTP traffic to
travel directly to those servers too while only allowing the SIP traffic
to go through the SIP proxy.</para>
</sect1>
</chapter>