This network is used just as a convenience with OSPF setup and will never be associated with a real
physical network.
3. Define an OSPF Interface for the tunnel
Define an NetDefendOS OSPF Interface object which has the IPsec tunnel for the Interface
parameter. Specify the Type parameter to be point-to-point and the Network parameter to be the
network chosen in the previous step, 192.168.55.0/24.
This OSPF Interface tells NetDefendOS that any OPSF related connections to addresses within the
network 192.168.55.0/24 should be routed into the IPsec tunnel.
4. Define an OSPF Neighbor
Next, we must explicitly tell OSPF how to find the neighbouring OSPF router. Do this by defining a
NetDefendOS OSPF Neighbor object. This consists of a pairing of the IPsec tunnel (which is treated
like an interface) and the IP address of the router at the other end of the tunnel.
For the IP address of the router, we simply use any single IP address from the network
192.168.55.0/24. For example, 192.168.55.1.
When NetDefendOS sets up OSPF, it will look at this OSPF Neighbor object and will try to send
OSPF messages to the IP address 192.168.55.1. The OSPF Interface object defined in the previous
step tells NetDefendOS that OSPF related traffic to this IP address should be routed into the IPsec
tunnel.
5. Set the Local IP of the tunnel endpoint
To finish the setup for firewall A there needs to be two changes made to the IPsec tunnel setup on
firewall B. These are:
i.
In the IPsec tunnel properties, the Local Network for the tunnel needs to be set to all-nets.
This setting acts as a filter for what traffic is allowed into the tunnel and all-nets will allow all
traffic into the tunnel.
ii.
In the routing section of the IPsec properties, the Specify address manually option needs to be
enabled and the IP address in this example of 192.168.55.1 needs to be entered. This sets the
tunnel endpoint IP to be 192.168.55.1 so that all OSPF traffic will be sent to firewall A with
this source IP.
The result of doing this is to "core route" OSPF traffic coming from firewall A. In other words the
traffic is destined for NetDefendOS.
6. Repeat the steps for the other firewall
What we have done so far is allow OSPF traffic to flow from A to B. The steps above need to be
repeated as a mirror image for firewall B using the same IPsec tunnel but using a different random
internal IP network for OSPF setup.
Tip: Non-OSPF traffic can also use the tunnel
A VPN tunnel can carry both OSPF traffic as well as other types of traffic. There is no
requirement to dedicate a tunnel to OSPF traffic.
4.5.6. An OSPF Example
This section shows the actual interface commands to implement the simple scenario described above
in Section 4.5.5, “Setting Up OSPF”. The VPN IPsec scenario is not included.
4.5.6. An OSPF Example
Chapter 4. Routing
196
Summary of Contents for NetDefend DFL-260E
Page 27: ...1 3 NetDefendOS State Engine Packet Flow Chapter 1 NetDefendOS Overview 27...
Page 79: ...2 7 3 Restore to Factory Defaults Chapter 2 Management and Maintenance 79...
Page 146: ...3 9 DNS Chapter 3 Fundamentals 146...
Page 227: ...4 7 5 Advanced Settings for Transparent Mode Chapter 4 Routing 227...
Page 241: ...5 4 IP Pools Chapter 5 DHCP Services 241...
Page 339: ...6 7 Blacklisting Hosts and Networks Chapter 6 Security Mechanisms 339...
Page 360: ...7 4 7 SAT and FwdFast Rules Chapter 7 Address Translation 360...
Page 382: ...8 3 Customizing HTML Pages Chapter 8 User Authentication 382...
Page 386: ...The TLS ALG 9 1 5 The TLS Alternative for VPN Chapter 9 VPN 386...
Page 439: ...Figure 9 3 PPTP Client Usage 9 5 4 PPTP L2TP Clients Chapter 9 VPN 439...
Page 450: ...9 7 6 Specific Symptoms Chapter 9 VPN 450...
Page 488: ...10 4 6 Setting Up SLB_SAT Rules Chapter 10 Traffic Management 488...
Page 503: ...11 6 HA Advanced Settings Chapter 11 High Availability 503...
Page 510: ...12 3 5 Limitations Chapter 12 ZoneDefense 510...
Page 533: ...13 9 Miscellaneous Settings Chapter 13 Advanced Settings 533...