Download pptx - XTM Networking Tips and Tricks Carlo Alvarez Technical Trainer - APAC

XTM Networking Tips and Tricks

Carlo AlvarezTechnical Trainer - APAC

2WatchGuard Training

Agenda

Public IP Address Subnet Behind XTM Dynamic Routing in FireCluster Enhanced Network Failover (ENF) with Remote WAN Failover Mixed Clientless SSO

PUBLIC SUBNET BEHIND XTM


Top 5 Reasons Why End Users Have Public IPs in their Network

1. They care about redundancy in terms of path going into their network

2. They care about the IP Address their hosts are going to use when they communicate on the internet

3. They demanded for Public IPs but they are not going to use it

4. They were just assigned by their ISP and they don’t care about it

5. They just make up addresses on their own


Public Subnet Behind XTM

Generally, the concern is the redundancy and the inbound path going to the Public Subnet

Works with either static or dynamic routing

Can be as simple as Single-WAN and can go as complex as Multi-WAN with Dynamic Routing


Simple Scenario : Public Subnet behind XTM

Single External Interface

Static Routing is sufficient

Works with Subnets of variable sizes


Simple Scenario : Public Subnet behind XTM

Configuration Tips

• Static route must be configured on the router before the XTM device

In this example a route to 202.101.21.0/24 with the next hop to 208.82.1.2 (XTM’s External Interface)

• Assign an IP Address from the same subnet to the XTM’s Optional Interface

• The subnet must not be included in the Dynamic NAT configuration

• Uncheck the NAT options on the Policies involving the Optional Network or any host of the Public Subnet


Simple Scenario : Public Subnet behind XTM Network Configuration


Simple Scenario : Public Subnet behind XTM Policy Example 1 - Outbound


Simple Scenario : Public Subnet behind XTM Policy Example 2 - Inbound

In this example 202.101.21.25 is the Mail Server

Destination Address is the Mail Server IP Address


Complex Scenario 1 : Public Subnet behind XTM

With Multi-WAN

Static Routing only

Works similar to the Single-WAN but with failover function using a different IP Address

Works even with subnet smaller than /24

Inbound path to the real Public IP is still on a single path



Configuration Tips

• Static route must be configured on the router before the XTM device going to XTM’s External-1 similar to the Simple Scenario example


• Add a Dynamic Nat of the Public Subnet Translating to the IP Address of External-2 for outbound purposes

• Inbound Policies will require two entries going to the same host


Complex Scenario 1 : Public Subnet behind XTM Network Configuration


Complex Scenario 1 : Public Subnet behind XTM DNAT Configuration

An entry is added for the Public IP subnet to translate to External-2 only


Complex Scenario 1 : Public Subnet behind XTM Policy Example 1 - Outbound


Complex Scenario 1 : Public Subnet behind XTM Policy Example 2 - Inbound


Destination Address has two entries

• The host as is (202.101.21.25)

• Static NAT translating the other External IP 122.22.21.2 to 202.101.21.25


Complex Scenario 1 : Public Subnet behind XTM Configure the DNS Records for inbound traffic

Example NS Records for Email Systems

company.com IN MX 5 mail1.company.com.

company.com IN MX 10 mail2.company.com.

mail1 IN A 202.101.21.25

mail2 IN A 122.22.21.2

Example NS Records for Web Service

Www1.company.com. IN A 202.101.21.80

www2.company.com. IN A 122.22.21.2



With Multi-WAN

Dynamic Routing support

Inbound path to the Public IP can be either of the WAN interfaces

Limited to subnets /24 or greater



Configuration Tips

• Configure External Interfaces


• Configure the Dynamic Routing with the Upstream Peers


Complex Scenario 2 : Public Subnet behind XTM Network Configuration


Complex Scenario 2 : Public Subnet behind XTM Dynamic Routing Configuration


Complex Scenario 2 : Public Subnet behind XTM Policy Example 1 - Outbound


Complex Scenario 2 : Public Subnet behind XTM Policy Example 2 - Inbound


Destination Address is the Mail Server IP Address

DYNAMIC ROUTING IN FIRECLUSTER


Dynamic Routing in FireCluster

Consider this…

Let’s try it out…

ENF with REMOTE WAN FAILOVER


Consider This Scenario A site can access the other through the Point-to-Point Link (PTP)

BOVPN


Consider This Scenario A site can access the other through the Point-to-Point Link (PTP) If the Point-to-Point link goes down the traffic routes through BOVPN

ENFEnhanced Network Failover


Enhanced Network Failover A site’s access to any resource on the internet goes through its WAN


Enhanced Network Failover A site’s access to any resource on the internet goes through the WAN If WAN breaks, it should be able to re-route through the PTP link


ENF with Remote WAN Failover The idea is to be able to use the remote site’s WAN for failover Remote WAN failover can be configured on either or both sites


ENF with Remote WAN Failover Configuration Network Configuration


ENF with Remote WAN Failover Configuration Dynamic NAT is only on the real WAN interface


ENF with Remote WAN Failover Configuration Dynamic Routing (OSPF)


ENF with Remote WAN Failover Configuration BOVPN Configuration


ENF with Remote WAN Failover Configuration The Policies


ENF with Remote WAN Failover Tips

The link between two sites must be Point-to-Point: with HO site set as LAN/OPT, while BO site should be set as WAN.

Multi-Hop link is also possible provided the routers used in between can do source based routing to filter the direction of the default routes

On BO site, Dynamic NAT is configured on the real WAN interface only such that traffic from one site to the other is not translated to the interface IP.

On BO, the Multi-WAN should be set as Failover .

On HO site, you must allow the remote subnet in the Global DNAT settings, and in the outbound rules for WEB access.

Ping must be allowed from the opposite end of the Point-to-Point link otherwise the External interface will fail.

This can work with Static or Dynamic routes, with classic Site-to-Site VPN.


MIXED CLIENTLESS SSO


Mixed Clientless SSO Scenario

Network is a combination of AD Joined-Hosts and Disjoined-Hosts

AD Joined-Host will do Clientless SSO

AD Disjoined Hosts such as Macs and Unix will be auto-redirected to authentication page when browsing


Helpful Hints:

Break the trusted subnet for easier policy configuration

• DHCP Address reservation for AD-Joined Hosts

• DHCP Pool for AD-Disjoined Hosts

Another option is to put the AD-Disjoined Hosts to a different subnet such as another Zone or a Wireless Guest network

WebBlocker plays a key role in this scenario since we will block the initial access of the Disjoined Hosts(IP Address Reservations) (IP Pool)


Mixed Clientless SSO Configuration

Configure ELM

ELM should be the top priority on the Clientless SSO Settings



Check the Trusted Interface configuration

Host Range should be easily segregated

In this example the lower half is for the reserved addresses of the AD-Joined Hosts

The upper half is for the Disjoined Hosts (DHCP Pool)



Add the Active Directory Domain



Enable the Single Sign-On

Add Exceptions to the SSO Clients List

Exceptions here is the host range corresponding to the IP Pool available for the Disjoined Host



Add the Policy for the AD-Joined Hosts and the Authenticated Hosts



Add the Policy for the Disjoined Hosts

The Source corresponds to the IP Pool of the Disjoined Hosts

Take note of the Proxy Action



Add and configure WebBlocker to Deny All Categories



Edit the Deny Message



Note that the Policies are in Manual Order Mode


THANK YOU!