D-Link DFL-800-AV-12 User Manual - Page 213

Translation of Multiple IP Addresses (M:N), 3.2. Translation of Multiple IP, Addresses M:N

Page 213 highlights

7.3.2. Translation of Multiple IP Addresses (M:N) Chapter 7. Address Translation • NetDefendOS translates the address in accordance with rule 1 and forwards the packet in accordance with rule 2: 10.0.0.3:1038 => 10.0.0.2:80 • wwwsrv processes the packet and replies: 10.0.0.2:80 => 10.0.0.3:1038 This reply arrives directly to PC1 without passing through the D-Link Firewall. This causes problems. The reason this will not work is because PC1 expects a reply from 195.55.66.77:80, not 10.0.0.2:80. The unexpected reply is discarded and PC1 continues to wait for a response from 195.55.66.77:80, which will never arrive. Making a minor change to the rule set in the same way as described above, will solve the problem. In this example, for no particular reason, we choose to use option 2: # Action Src Iface 1 SAT any 2 NAT lan 3 Allow any Src Net all-nets lannet all-nets Dest Iface core any core Dest Net wan_ip all-nets wan_ip Parameters http SETDEST wwwsrv 80 All http • PC1 sends a packet to wan_ip to reach "www.ourcompany.com": 10.0.0.3:1038 => 195.55.66.77:80 • NetDefendOS address translates this statically in accordance with rule 1 and dynamically in accordance with rule 2: 10.0.0.1:32789 => 10.0.0.2:80 • wwwsrv processes the packet and replies: 10.0.0.2:80 => 10.0.0.1:32789 • The reply arrives and both address translations are restored: 195.55.66.77:80 => 10.0.0.3:1038 This way, the reply arrives at PC1 from the expected address. Another possible solution to this problem is to allow internal clients to speak directly to 10.0.0.2, which would completely avoid all the problems associated with address translation. However, this is not always practical. 7.3.2. Translation of Multiple IP Addresses (M:N) A single SAT rule can be used to translate an entire range of IP addresses. In this case, the result is a transposition where the first original IP address will be translated to the first IP address in the translation list and so on. For instance, a SAT policy specifying that connections to the 194.1.2.16/29 network should be translated to 192.168.0.50 will result in transpositions as per the table below: Original Address 194.1.2.16 194.1.2.17 194.1.2.18 194.1.2.19 194.1.2.20 194.1.2.21 194.1.2.22 194.1.2.23 Translated Address 192.168.0.50 192.168.0.51 192.168.0.52 192.168.0.53 192.168.0.54 192.168.0.55 192.168.0.56 192.168.0.57 In other words: • Attempts to communicate with 194.1.2.16 will result in a connection to 192.168.0.50. • Attempts to communicate with 194.1.2.22 will result in a connection to 192.168.0.56. 213

  • 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
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310
  • 311
  • 312
  • 313
  • 314
  • 315
  • 316
  • 317
  • 318
  • 319
  • 320
  • 321
  • 322
  • 323
  • 324
  • 325
  • 326
  • 327
  • 328
  • 329
  • 330
  • 331
  • 332
  • 333
  • 334
  • 335
  • 336
  • 337
  • 338
  • 339
  • 340
  • 341
  • 342
  • 343
  • 344
  • 345
  • 346
  • 347
  • 348
  • 349
  • 350
  • 351
  • 352
  • 353
  • 354
  • 355

NetDefendOS translates the address in accordance with rule 1 and forwards the packet in accordance with
rule 2:
10.0.0.3:1038
=>
10.0.0.2:80
wwwsrv processes the packet and replies:
10.0.0.2:80
=>
10.0.0.3:1038
This reply arrives directly to PC1 without passing through the D-Link Firewall. This causes problems. The reason
this will not work is because PC1 expects a reply from 195.55.66.77:80, not 10.0.0.2:80. The unexpected reply is
discarded and PC1 continues to wait for a response from 195.55.66.77:80, which will never arrive.
Making a minor change to the rule set in the same way as described above, will solve the problem. In this
example, for no particular reason, we choose to use option 2:
#
Action
Src Iface
Src Net
Dest Iface
Dest Net
Parameters
1
SAT
any
all-nets
core
wan_ip
http SETDEST wwwsrv 80
2
NAT
lan
lannet
any
all-nets
All
3
Allow
any
all-nets
core
wan_ip
http
PC1 sends a packet to wan_ip to reach "www.ourcompany.com":
10.0.0.3:1038
=>
195.55.66.77:80
NetDefendOS address translates this statically in accordance with rule 1 and dynamically in accordance with
rule 2:
10.0.0.1:32789
=>
10.0.0.2:80
wwwsrv processes the packet and replies:
10.0.0.2:80
=>
10.0.0.1:32789
The reply arrives and both address translations are restored:
195.55.66.77:80
=>
10.0.0.3:1038
This way, the reply arrives at PC1 from the expected address.
Another possible solution to this problem is to allow internal clients to speak directly to 10.0.0.2, which would
completely avoid all the problems associated with address translation. However, this is not always practical.
7.3.2. Translation of Multiple IP Addresses (M:N)
A single SAT rule can be used to translate an entire range of IP addresses. In this case, the result is a
transposition where the first original IP address will be translated to the first IP address in the
translation list and so on.
For instance, a SAT policy specifying that connections to the 194.1.2.16/29 network should be
translated to 192.168.0.50 will result in transpositions as per the table below:
Original Address
Translated Address
194.1.2.16
192.168.0.50
194.1.2.17
192.168.0.51
194.1.2.18
192.168.0.52
194.1.2.19
192.168.0.53
194.1.2.20
192.168.0.54
194.1.2.21
192.168.0.55
194.1.2.22
192.168.0.56
194.1.2.23
192.168.0.57
In other words:
Attempts to communicate with 194.1.2.16 will result in a connection to 192.168.0.50.
Attempts to communicate with 194.1.2.22 will result in a connection to 192.168.0.56.
7.3.2. Translation of Multiple IP
Addresses (M:N)
Chapter 7. Address Translation
213