Category Archives: FortiOS 5.4 Handbook

The complete handbook for FortiOS 5.4

DCE-RPC session helper (dcerpc)

Leave a reply

DCE–RPC session helper (dcerpc)

Distributed Computing Environment Remote Procedure Call (DCE-RPC) provides a way for a program running on one host to call procedures in a program running on another host. DCE-RPC (also called MS RPC for Microsoft RPC) is similar to ONC-RPC. Because of the large number of RPC services, for example, MAPI, the transport address of an RPC service is dynamically negotiated based on the service program’s universal unique identifier (UUID). The Endpoint Mapper (EPM) binding protocol in FortiOS maps the specific UUID to a transport address.

To accept DCE-RPC sessions you must add a security policy with service set to any or to the DEC-RPC pre- defined service (which listens on TCP and UDP ports 135). The dcerpc session helper also listens on TCP and UDP ports 135.

The session allows FortiOS to handle DCE-RPC dynamic transport address negotiation and to ensure UUID- based security policy enforcement. You can define a security policy to permit all RPC requests or to permit by specific UUID number.

In addition, because a TCP segment in a DCE-RPC stream might be fragmented, it might not include an intact RPC PDU. This fragmentation occurs in the RPC layer; so FortiOS does not support parsing fragmented packets.

Changing the session helper configuration

Leave a reply

Changing the session helper configuration

Normally you will not need to change the configuration of the session helpers. However in some cases you may need to change the protocol or port the session helper listens on.

 

Changing the protocol or port that a session helper listens on

Most session helpers are configured to listen for their sessions on the port and protocol that they typically use. If your FortiGate unit receives sessions that should be handled by a session helper on a non-standard port or protocol you can use the following procedure to change the port and protocol used by a session helper. The following example shows how to change the port that the pmap session helper listens on for Sun RPC portmapper TCP sessions. By default pmap listens on TCP port 111.

 

To change the port that the pmap session helper listens on to TCP port 112

1. Confirm that the TCP pmap session helper entry is 11 in the session-helper list:

show system session-helper 11 config system session-helper

edit 11

set name pmap set port 111 set protocol 6

next end

2. Enter the following command to change the TCP port to 112.

config system session-helper edit 11

set port 112 end

3. The pmap session helper also listens on UDP port 111. Confirm that the UDP pmap session helper entry is 12 in the session-helper list:

show system session-helper 12 config system session-helper

edit 12

set name pmap set port 111

set protocol 17 next

end

4. Enter the following command to change the UDP port to 112.

config system session-helper edit 12

set port 112 end

Use the following command to set the h323 session helper to listen for ports on the UDP protocol.

 

To change the protocol that the h323 session helper listens on

1. Confirm that the h323 session helper entry is 2 in the session-helper list:

show system session-helper 2 config system session-helper

edit 2

set name h323 set port 1720 set protocol 6

next end

2. Enter the following command to change the protocol to UDP.

config system session-helper edit 2

set protocol 17 end

 

If a session helper listens on more than one port or protocol, then multiple entries for the session helper must be added to the session helper list, one for each port and protocol combination. For example, the rtsp session helper listens on TCP ports 554, 7070, and 8554 so there are three rtsp entries in the session-helper list. If your FortiGate unit receives rtsp packets on a different TCP port (for example, 6677) you can use the following command to configure the rtsp session helper to listen on TCP port 6677.

 

To configure a session helper to listen on a new port and protocol

config system session-helper edit 0

set name rtsp set port 6677 set protocol 6 end

 

Disabling a session helper

In some cases you may need to disable a session helper. Disabling a session helper just means removing it from the session-helper list so that the session helper is not listening on a port. You can completely disable a session helper by deleting all of its entries from the session helper list. If there are multiple entries for a session helper on the list you can delete one of the entries to prevent the session helper from listening on that port.

 

To disable the mgcp session helper from listening on UDP port 2427

1. Enter the following command to find the mgcp session helper entry that listens on UDP port 2427:

show system session-helper

.

.

. edit 19

set name mgcp set port 2427 set protocol 17

next

.

.

.

 

2. Enter the following command to delete session-helper list entry number 19 to disable the mgcp session helper from listening on UDP port 2427:

config system session-helper delete 19

By default the mgcp session helper listens on UDP ports 2427 and 2727. The previous procedure shows how to disable the mgcp protocol from listening on port 2427. The following procedure completely disables the mgcp session helper by also disabling it from listening on UDP port 2727.

 

To completely disable the mgcp session helper

1. Enter the following command to find the mgcp session helper entry that listens on UDP port 2727:

show system session-helper

.

.

. edit 20

set name mgcp set port 2727 set protocol 17

next

.

.

.

2. Enter the following command to delete session-helper list entry number 20 to disable the mgcp session helper from listening on UDP port 2727:

config system session-helper delete 20

Session helpers

Leave a reply

Session helpers

The FortiOS firewall can analyze most TCP/IP protocol traffic by comparing packet header information to security policies. This comparison determines whether to accept or deny the packet and the session that the packet belongs to.

Some protocols include information in the packet body (or payload) that must be analyzed to successfully process sessions for this protocol. For example, the SIP VoIP protocol uses TCP control packets with a standard destination port to set up SIP calls. But the packets that carry the actual conversation can use a variety of UDP protocols with a variety of source and destination port numbers. The information about the protocols and port numbers used for a SIP call is contained in the body of the SIP TCP control packets. To successfully process SIP VoIP calls, FortiOS must be able to extract information from the body of the SIP packet and use this information to allow the voice-carrying packets through the firewall.

FortiOS uses session helpers to analyze the data in the packet bodies of some protocols and adjust the firewall to allow those protocols to send packets through the firewall.

 

This section includes the topics:

  • Viewing the session helper configuration
  • Changing the session helper configuration
  • DCE-RPC session helper (dcerpc)
  • DNS session helpers (dns-tcp and dns-udp)
  • File transfer protocol (FTP) session helper (ftp)
  • H.245 session helpers (h245I and h245O)
  • H.323 and RAS session helpers (h323 and ras)
  • Media Gateway Controller Protocol (MGCP) session helper (mgcp)
  • ONC-RPC portmapper session helper (pmap)
  • PPTP session helper for PPTP traffic (pptp)
  • Remote shell session helper (rsh)
  • Real-Time Streaming Protocol (RTSP) session helper (rtsp)
  • Session Initiation Protocol (SIP) session helper (sip)
  • Trivial File Transfer Protocol (TFTP) session helper (tftp)
  • Oracle TNS listener session helper (tns)

 

Viewing the session helper configuration

You can view the session helpers enabled on your FortiGate unit in the CLI using the commands below. The following output shows the first two session helpers. The number of session helpers can vary to around 20.

show system session-helper config system session-helper

edit 1

set name pptp

set port 1723 set protocol 6

next

set name h323 set port 1720 set protocol 6

end

.

.

 

The configuration for each session helper includes the name of the session helper and the port and protocol number on which the session helper listens for sessions. Session helpers listed on protocol number 6 (TCP) or 17 (UDP). For a complete list of protocol numbers see Assigned Internet Protocol Numbers.

For example, the output above shows that FortiOS listens for PPTP packets on TCP port 1723 and H.323 packets on port TCP port 1720.

If a session helper listens on more than one port or protocol the more than one entry for the session helper appears in the config system session-helper list. For example, the pmap session helper appears twice because it listens on TCP port 111 and UDP port 111. The rsh session helper appears twice because it listens on TCP ports 514 and 512.

L2TP configuration overview

Leave a reply

L2TP configuration overview

To configure a FortiGate unit to act as an LNS, you perform the following tasks:

  • Create an L2TP user group containing one user for each remote client.
  • Enable L2TP on the FortiGate unit and specify the range of addresses that can be assigned to remote clients when they connect.
  • Define firewall source and destination addresses to indicate where packets transported through the L2TP tunnel will originate and be delivered.
  • Create the security policy and define the scope of permitted services between the source and destination addresses.
  • Configure the remote clients.

 

Authenticating L2TP clients

L2TP clients must be authenticated before a tunnel is established. The authentication process relies on FortiGate user group definitions, which can optionally use established authentication mechanisms such as RADIUS or LDAP to authenticate L2TP clients. All L2TP clients are challenged when a connection attempt is made.

To enable authentication, you must create user accounts and a user group to identify the L2TP clients that need access to the network behind the FortiGate unit.

You can choose to use a plain text password for authentication or forward authentication requests to an external RADIUS or LDAP server. If password protection will be provided through a RADIUS or LDAP server, you must configure the FortiGate unit to forward authentication requests to the authentication server.

 

Enabling L2TP and specifying an address range

The L2TP address range specifies the range of addresses reserved for remote clients. When a remote client connects to the FortiGate unit, the client is assigned an IP address from this range. Afterward, the FortiGate unit uses the assigned address to communicate with the remote client.

The address range that you reserve can be associated with private or routable IP addresses. If you specify a private address range that matches a network behind the FortiGate unit, the assigned address will make the remote client appear to be part of the internal network.

To enable L2TP and specify the L2TP address range, use the config vpn l2tp CLI command.

The following example shows how to enable L2TP and set the L2TP address range using a starting address of 192.168.10.80 and an ending address of 192.168.10.100 for an existing group of L2TP users named L2TP_users:

config vpn l2tp

set sip 192.168.10.80 set eip 192.168.10.100 set status enable

set usrgrp L2TP_users end

 

Defining firewall source and destination addresses

Before you define the security policy, you must define the source and destination addresses of packets that are to be transported through the L2TP tunnel:

  • For the source address, enter the range of addresses that you reserved for remote L2TP clients (for example 192.168.10.[80-100]).
  • For the destination address, enter the IP addresses of the computers that the L2TP clients need to access on the private network behind the FortiGate unit (for example, 172.16.5.0/24 for a subnet, or 172.16.5.1 for a server or host, or 192.168.10.[10-15] for an IP address range).

 

To define the firewall source address

1. Go to Policy & Objects > Objects > Addresses and select Create New.

2. Select a Category.

3. In the Address Name field, type a name that represents the range of addresses that you reserved for remote clients (for example, Ext_L2TPrange).

4. In Type, select IP Range.

5. In the IP Range field, type the corresponding IP address range.

6. In Interface, select the FortiGate interface that connects to the clients.

7. This is usually the interface that connects to the Internet.

8. Select OK.

 

To define the firewall destination address

1. Go to Policy & Objects > Objects > Addresses and select Create New.

2. In the Address Name field, type a name that represents a range of IP addresses on the network behind the FortiGate unit (for example, Int_L2TPaccess).

3. In Type, select IP Range.

4. In the IP Range field, type the corresponding IP address range.

5. In Interface, select the FortiGate interface that connects to the network behind the FortiGate unit.

6. Select OK.

 

Adding the security policy

The security policy specifies the source and destination addresses that can generate traffic inside the L2TP tunnel and defines the scope of services permitted through the tunnel. If a selection of services are required, define a service group.

 

To define the traffic and services permitted inside the L2TP tunnel

1. Go to Policy & Objects > Policy > IPv4 or Policy & Objects > Policy > IPv6 and select Create New.

2. Enter these settings:

Incoming Interface Select the FortiGate interface to the Internet.
Source Address Select the name that corresponds to the address range that reserved for

L2TP clients (for example, Ext_L2TPrange).
Outgoing Interface Select the FortiGate interface to the internal (private) network.
Destination Address Select the name that corresponds to the IP addresses behind the FortiGate unit (for example, Int_L2TPaccess).
Service Select ALL, or if selected services are required instead, select the service group that you defined previously.
Action ACCEPT
 

3.

  

Select OK.

 

Configuring a Linux client

This procedure outlines how to install L2TP client software and run an L2TP tunnel on a Linux computer. Obtain an L2TP client package that meets your requirements (for example, rp-l2tp). If needed to encrypt traffic, obtain L2TP client software that supports encryption using MPPE.

To establish an L2TP tunnel with a FortiGate unit that has been set up to accept L2TP connections, you can obtain and install the client software following these guidelines:

1. If encryption is required but MPPE support is not already present in the kernel, download and install an MPPE kernel module and reboot your computer.

2. Download and install the L2TP client package.

3. Configure an L2TP connection to run the L2TP program.

4. Configure routes to determine whether all or some of your network traffic will be sent through the tunnel. You must define a route to the remote network over the L2TP link and a host route to the FortiGate unit.

5. Run l2tpd to start the tunnel.

Follow the software supplier’s documentation to complete the steps.

To configure the system, you need to know the public IP address of the FortiGate unit, and the user name and password that has been set up on the FortiGate unit to authenticate L2TP clients. Contact the FortiGate administrator if required to obtain this information.

 

Monitoring L2TP sessions

You can display a list of all active sessions and view activity by port number. By default, port 1701 is used for L2TP VPN-related communications. If required, active sessions can be stopped from this view. Use the Top Sessions Dashboard Widget.

 

Testing L2TP VPN connections

To confirm that a VPN between a local network and a dialup client has been configured correctly, at the dialup client, issue a ping command to test the connection to the local network. The VPN tunnel initializes when the dialup client attempts to connect.

 

Logging L2TP VPN events

You can configure the FortiGate unit to log VPN events. For L2TP VPNs, connection events and tunnel status (up/down) are logged.

 

To log VPN events – web-based manager

1. Go to Log & Report > Log Config > Log Settings.

2. Enable the storage of log messages to one or more locations.

3. Select Enable, and then select VPN activity event.

4. Select Apply.

 

To log VPN events – CLI

config log memory setting set diskfull overwrite set status enable

end

config log eventfilter set vpn enable

end

Configuring L2TP VPNs

Leave a reply

Configuring L2TP VPNs

This section describes how to configure a FortiGate unit to establish a Layer Two Tunneling Protocol (L2TP) tunnel with a remote dialup client. The FortiGate implementation of L2TP enables a remote dialup client to establish an L2TP tunnel with the FortiGate unit directly.

According to RFC 2661, an Access Concentrator (LAC) can establish an L2TP tunnel with an L2TP Network Server (LNS). In a typical scenario, the LAC is managed by an ISP and located on the ISP premises; the LNS is the gateway to a private network. When a remote dialup client connects to the Internet through the ISP, the ISP uses a local database to establish the identity of the caller and determine whether the caller needs access to an LNS through an L2TP tunnel. If the services registered to the caller indicate that an L2TP connection to the LNS is required, the ISP LAC attempts to establish an L2TP tunnel with the LNS.

A FortiGate unit can be configured to act as an LNS. The FortiGate implementation of L2TP enables a remote dialup client to establish an L2TP tunnel with the FortiGate unit directly, bypassing any LAC managed by an ISP. The ISP must configure its network access server to forward L2TP traffic from the remote client to the FortiGate unit directly whenever the remote client requires an L2TP connection to the FortiGate unit.

When the FortiGate unit acts as an LNS, an L2TP session and tunnel is created as soon as the remote client connects to the FortiGate unit. The FortiGate unit assigns an IP address to the client from a reserved range of IP addresses. The remote client uses the assigned IP address as its source address for the duration of the connection.

More than one L2TP session can be supported on the same tunnel. FortiGate units can be configured to authenticate remote clients using a plain text user name and password, or authentication can be forwarded to an external RADIUS or LDAP server. L2TP clients are authenticated as members of a user group.

FortiGate units support L2TP with Microsoft Point-to-Point Encryption (MPPE) encryp- tion only. Later implementations of Microsoft L2TP for Windows use IPsec and require certificates for authentication and encryption. If you want to use Microsoft L2TP with IPsec to connect to a FortiGate unit, the IPsec and certificate elements must be dis- abled on the remote client.

Traffic from the remote client must be encrypted using MPPE before it is encapsulated and routed to the FortiGate unit. Packets originating at the remote client are addressed to a computer on the private network behind the FortiGate unit. Encapsulated packets are addressed to the public interface of the FortiGate unit. See the figure below.

When the FortiGate unit receives an L2TP packet, the unit disassembles the packet and forwards the packet to the correct computer on the internal network. The security policy and protection profiles on the FortiGate unit ensure that inbound traffic is screened and processed securely.

 

L2TP encapsulation

FortiGate units cannot deliver non-IP traffic such as Frame Relay or ATM frames encapsulated in L2TP packets— FortiGate units support the IPv4 and IPv6 addressing schemes only

 

Network topology

The remote client connects to an ISP that determines whether the client requires an L2TP connection to the FortiGate unit. If an L2TP connection is required, the connection request is forwarded to the FortiGate unit directly.

 

Example L2TP configuration

 

L2TP infrastructure requirements

  • The FortiGate unit must be operating in NAT mode and have a static public IP address.
  • The ISP must configure its network access server to forward L2TP traffic from remote clients to the FortiGate unit directly.
  • The remote client must not generate non-IP traffic (Frame Relay or ATM frames).
  • The remote client includes L2TP support with MPPE encryption. If the remote client includes Microsoft L2TP with IPsec, the IPsec and certificate components must be disabled.

FortiGate unit as a PPTP server

1 Reply

FortiGate unit as a PPTP server

In the most common Internet scenario, the PPTP client connects to an ISP that offers PPP connections with dynamically-assigned IP addresses. The ISP forwards PPTP packets to the Internet, where they are routed to the FortiGate unit.

 

FortiGate unit as a PPTP server

 

If the FortiGate unit will act as a PPTP server, there are a number of steps to complete:

  • Configure user authentication for PPTP clients.
  • Enable PPTP.
  • Specify the range of addresses that are assigned to PPTP clients when connecting
  • Configure the security policy.

 

Configuring user authentication for PPTP clients

To enable authentication for PPTP clients, you must create user accounts and a user group to identify the PPTP clients that need access to the network behind the FortiGate unit. Within the user group, you must add a user for each PPTP client.

You can choose to use a plain text password for authentication or forward authentication requests to an external RADIUS, LDAP, or TACACS+ server. If password protection will be provided through a RADIUS, LDAP, or TACACS+ server, you must configure the FortiGate unit to forward authentication requests to the authentication server.

This example creates a basic user/password combination.

 

Configuring a user account

 

To add a local user – web-based manager

1. Go to User & Device > User > User Definition and select Create New.

2. Select Local User

3. Enter a User Name.

4. Enter a Password for the user. The password should be at least six characters.

5. Select OK.

 

To add a local user – CLI

config user local edit <username>

set type password

set passwd <password>

end

 

Configuring a user group

To ease configuration, create user groups that contain users in similar categories or departments.

 

To create a user group – web-based manager

1. Go to User & Device > User > User Group and select Create New.

2. Enter a Name for the group.

3. Select the Type of Firewall.

4. From the Available Users list, select the required users and select the right-facing arrow to add them to the

Members list.

5. Select OK.

 

To create a user group – CLI

config user group edit <group_name>

set group-type firewall set member <user_names>

end

 

Enabling PPTP and specifying the PPTP IP address range

The PPTP address range specifies the range of addresses reserved for remote PPTP clients. When a PPTP client connects to the FortiGate unit, the client is assigned an IP address from this range. Afterward, the FortiGate unit uses the assigned address to communicate with the PPTP client.

The address range that you reserve can be associated with private or routable IP addresses. If you specify a private address range that matches a network behind the FortiGate unit, the assigned address will make the PPTP client appear to be part of the internal network.

PPTP requires two IP addresses, one for each end of the tunnel. The PPTP address range is the range of addresses reserved for remote PPTP clients. When the remote PPTP client establishes a connection, the FortiGate unit assigns an IP address from the reserved range of IP addresses to the client PPTP interface or retrieves the assigned IP address from the PPTP user group. If you use the PPTP user group, you must also define the FortiGate end of the tunnel by entering the IP address of the unit in Local IP (web-based manager) or local-ip (CLI). The PPTP client uses the assigned IP address as its source address for the duration of the connection.

PPTP configuration is only available through the CLI. In the example below, PPTP is enabled with the use of an IP range of 182.168.1.1 to 192.168.1.10 for addressing and the user group is hr_staff.

The start and end IPs in the PPTP address range must be in the same 24-bit subnet, for example, 192.168.1.1 – 192.168.1.254.

config vpn pptp

set status enable set ip-mode range

set eip 192.168.1.10 set sip 192.168.1.1 set usrgrp hr_staff

end

 

In this example, PPTP is enabled with the use of a user group for addressing, where the IP address of the PPTP server is 192.168.1.2 and the user group is hr_admin.

config vpn pptp

set status enable set ip-mode range

set local-ip 192.168.2.1 set usrgrp hr_admin

end

 

Adding the security policy

The security policy specifies the source and destination addresses that can generate traffic inside the PPTP tunnel and defines the scope of services permitted through the tunnel. If a selection of services are required, define a service group.

 

To configure the firewall for the PPTP tunnel – web-based manager

1. Go to Policy & Objects > Policy > IPv4 or Policy & Objects > Policy > IPv6 and select Create New.

2. Complete the following and select OK:

Incoming Interface                   The FortiGate interface connected to the Internet.

Source Address                        Select the name that corresponds to the range of addresses that you reserved for PPTP clients.

Outgoing Interface                   The FortiGate interface connected to the internal network.

Destination Address                 Select the name that corresponds to the IP addresses behind the FortiGate unit.

Schedule                                    always

Service                                       ALL

Action                                         ACCEPT

 

To configure the firewall for the PPTP tunnel – CLI

config firewall policy or  config firewall policy6 edit 1

set srcintf <interface to internet>

set dstintf <interface to internal network>

set srcaddr <reserved_range>

set dstaddr <internal_addresses>

set action accept set schedule always set service ALL

end

 

Configuring the FortiGate unit for PPTP VPN

To arrange for PPTP packets to pass through the FortiGate unit to an external PPTP server, perform the following tasks in the order given:

  • Configure user authentication for PPTP clients.
  • Enable PPTP on the FortiGate unit and specify the range of addresses that can be assigned to PPTP clients when they connect.
  • Configure PPTP pass through on the FortiGate unit.

 

Configuring the FortiGate unit for PPTP pass through

To forward PPTP packets to a PPTP server on the network behind the FortiGate unit, you need to perform the following configuration tasks on the FortiGate unit:

  • Define a virtual IP address that points to the PPTP server.
  • Create a security policy that allows incoming PPTP packets to pass through to the PPTP server.

The address range is the external (public) ip address range which requires access to the internal PPTP server through the FortiGate virtual port-forwarding firewall.

IP addresses used in this document are fictional and follow the technical doc- umentation guidelines specific to Fortinet. Real external IP addresses are not used.

 

Configuring a virtual IP address

The virtual IP address will be the address of the PPTP server host.

 

To define a virtual IP for PPTP pass through – web-based manager

1. Go to Policy & Objects > Objects > Virtual IPs.

2. Select Create New.

3. Choose the VIP Type.

4. Enter the name of the VIP, for example, PPTP_Server.

5. Select the External Interface where the packets will be received for the PPTP server.

6. Enter the External IP Address for the VIP.

7. Select Port Forwarding.

8. Set the Protocol to TCP.

9. Enter the External Service Port of 1723, the default for PPTP.

10. Enter the Map to Port to 1723.

11. Select OK.

 

To define a virtual IP for PPTP pass through – web-based manager

config firewall vip or  config firewall vip6 edit PPTP_Server

set extintf <interface> set extip <ip_address> set portforward enable set protocol tcp

set extport 1723

set mappedport 1723

set mappedip <destination IP address range>

end

You can also use config firewall vip46 to define a virtual IP from an IPv4 address to an IPv6 address or config firewall vip64 to define a virtual IP from an IPv6 address to an IPv4 address.

 

Configuring a port-forwarding security policy

To create a port-forwarding security policy for PPTP pass through you must first create an address range reserved for the PPTP clients.

 

To create an address range – web-based manager

1. Go to Policy & Objects > Objects > Addresses and select Create New.

2. Select a Category.

3. Enter a Name for the range, for example, External_PPTP.

4. Select a Type of Subnet/IP Range.

5. Enter the IP address range.

6. Select the Interface to the Internet.

7. Select OK.

 

To create an address range – CLI

config firewall address OR config firewall address6 edit External_PPTP

end

set type ip_range

set start-ip <ip_address>

set end-ip <ip_address>

set associated-interface <internet_interface>

With the address set, you can add the security policy.

 

To add the security policy – web-based manager

1. Go to Policy & Objects > Policy > IPv4 or Policy & Objects > Policy > IPv6 and select Create New.

2. Complete the following and select OK:

Incoming Interface                   The FortiGate interface connected to the Internet.

Source Address                        Select the address range created in the previous step.

Outgoing Interface                   The FortiGate interface connected to the PPTP server.

Destination Address                 Select the VIP address created in the previous steps.

Schedule                                    always

Service                                       PPTP

Action                                         ACCEPT

 

To add the security policy – CLI

config firewall policy or  config firewall policy6 edit <policy_number>

set srcintf <interface to internet>

set dstintf <interface to PPTP server>

set srcaddr <address_range>

set dstaddr <PPTP_server_address>

set action accept set schedule always set service PPTP

end

 

Testing PPTP VPN connections

To confirm that a PPTP VPN between a local network and a dialup client has been configured correctly, at the dialup client, issue a ping command to test the connection to the local network. The PPTP VPN tunnel initializes when the dialup client attempts to connect.

 

Logging VPN events

PPTP VPN, activity is logged when enabling VPN logging. The FortiGate unit connection events and tunnel status I thi(up/down) are logged.

 

To log VPN events

1. Go to Log & Report > Log Config > Log Settings.

2. Enable the storage of log messages to one or more locations.

3. Select VPN activity event.

4. Select Apply.

 

To view event logs

1. Go to Log & Report > Event Log > VPN.

2. If the option is available from the Log Type list, select the log file from disk or memory.

PPTP and L2TP

Leave a reply

PPTP and L2TP

A virtual private network (VPN) is a way to use a public network, such as the Internet, as a vehicle to provide remote offices or individual users with secure access to private networks. FortiOS supports the Point-to-Point Tunneling Protocol (PPTP), which enables interoperability between FortiGate units and Windows or Linux PPTP clients. Because FortiGate units support industry standard PPTP VPN technologies, you can configure a PPTP VPN between a FortiGate unit and most third-party PPTP VPN peers.

 

This section describes how to configure PPTP and L2TP VPNs as well as PPTP passthrough. This section includes the topics:

  • How PPTP VPNs work
  • FortiGate unit as a PPTP server
  • Configuring the FortiGate unit for PPTP VPN
  • Configuring the FortiGate unit for PPTP pass through
  • Testing PPTP VPN connections
  • Logging VPN events
  • Configuring L2TP VPNs
  • L2TP configuration overview

 

How PPTP VPNs work

The Point-to-Point Tunneling Protocol enables you to create a VPN between a remote client and your internal network. Because it is a Microsoft Windows standard, PPTP does not require third-party software on the client computer. As long as the ISP supports PPTP on its servers, you can create a secure connection by making relatively simple configuration changes to the client computer and the FortiGate unit.

PPTP uses Point-to-Point protocol (PPP) authentication protocols so that standard PPP software can operate on tunneled PPP links. PPTP packages data in PPP packets and then encapsulates the PPP packets within IP packets for transmission through a VPN tunnel.

When the FortiGate unit acts as a PPTP server, a PPTP session and tunnel is created as soon as the PPTP client connects to the FortiGate unit. More than one PPTP session can be supported on the same tunnel. FortiGate units support PAP, CHAP, and plain text authentication. PPTP clients are authenticated as members of a user group.

Traffic from one PPTP peer is encrypted using PPP before it is encapsulated using Generic Routing Encapsulation (GRE) and routed to the other PPTP peer through an ISP network. PPP packets from the remote client are addressed to a computer on the private network behind the FortiGate unit. PPTP packets from the remote client are addressed to the public interface of the FortiGate unit. Seethe figure below.

PPTP control channel messages are not authenticated, and their integrity is not pro- tected. Furthermore, encapsulated PPP packets are not cryptographically protected and may be read or modified unless appropriate encryption software such as Secure Shell (SSH) or Secure File Transfer Protocol (SFTP) is used to transfer data after the tunnel has been established.

As an alternative, you can use encryption software such as Microsoft Point-to-Point Encryption (MPPE) to secure the channel. MPPE is built into Microsoft Windows cli- ents and can be installed on Linux clients. FortiGate units support MPPE.

 

Packet encapsulation

Shown above, traffic from the remote client is addressed to a computer on the network behind the FortiGate unit. When the PPTP tunnel is established, packets from the remote client are encapsulated and addressed to the FortiGate unit. The FortiGate unit forwards disassembled packets to the computer on the internal network.

When the remote PPTP client connects, the FortiGate unit assigns an IP address from a reserved range of IP addresses to the client PPTP interface. The PPTP client uses the assigned IP address as its source address for the duration of the connection.

When the FortiGate unit receives a PPTP packet, the unit disassembles the PPTP packet and forwards the packet to the correct computer on the internal network. The security policy and protection profiles on the FortiGate unit ensure that inbound traffic is screened and processed securely.

PPTP clients must be authenticated before a tunnel is established. The authentication process relies on FortiGate user group definitions, which can optionally use estab- lished authentication mechanisms such as RADIUS or LDAP to authenticate PPTP cli- ents. All PPTP clients are challenged when a connection attempt is made.

Troubleshooting VLAN issues

Leave a reply

Troubleshooting VLAN issues

Several problems can occur with your VLANs. Since VLANs are interfaces with IP addresses, they behave as interfaces and can have similar problems that you can diagnose with tools such as ping, traceroute, packet sniffing, and diag debug.

 

Asymmetric routing

You might discover unexpectedly that hosts on some networks are unable to reach certain other networks. This occurs when request and response packets follow different paths. If the FortiGate unit recognizes the response packets, but not the requests, it blocks the packets as invalid. Also, if the FortiGate unit recognizes the same packets repeated on multiple interfaces, it blocks the session as a potential attack.

This is asymmetric routing. By default, the FortiGate unit blocks packets or drops the session when this happens. You can configure the FortiGate unit to permit asymmetric routing by using the following CLI commands:

config system settings set asymroute enable

end

 

If VDOMs are enabled, this command is per VDOM. You must set it for each VDOM that has the problem as following:

config vdom

edit <vdom_name>

config system settings set asymroute enable

end end

 

If this solves your blocked traffic issue, you know that asymmetric routing is the cause. But allowing asymmetric routing is not the best solution, because it reduces the security of your network.

For a long-term solution, it is better to change your routing configuration or change how your FortiGate unit connects to your network.

If you enable asymmetric routing, antivirus and intrusion prevention systems will not be effective. Your FortiGate unit will be unaware of connections and treat each packet individually. It will become a stateless firewall.

set l2forward enable end

where  <name_str> is the name of an interface.

If VDOMs are enabled, this command is per VDOM. You must set it for each VDOM that has the problem as following:

config vdom

edit <vdom_name>

config system interface edit <name_str>

set l2forward enable end

end

 

If you enable layer-2 traffic, you may experience a problem if packets are allowed to repeatedly loop through the network. This repeated looping, very similar to a broadcast storm, occurs when you have more than one layer-2 path to a destination. Traffic may overflow and bring your network to a halt. You can break the loop by enabling Spanning Tree Protocol (STP) on your network’s switches and routers. For more information, see “STP forwarding”.

 

ARP traffic

Address Resolution Protocol (ARP) packets are vital to communication on a network, and ARP support is enabled on FortiGate unit interfaces by default. Normally you want ARP packets to pass through the FortiGate unit, especially if it is sitting between a client and a server or between a client and a router.

ARP traffic can cause problems, especially in transparent mode where ARP packets arriving on one interface are sent to all other interfaces including VLAN subinterfaces. Some layer-2 switches become unstable when they detect the same MAC address originating on more than one switch interface or from more than one VLAN. This instability can occur if the layer-2 switch does not maintain separate MAC address tables for each VLAN. Unstable switches may reset and cause network traffic to slow down considerably.

The default ARP timeout value is 5 minutes (300 seconds). So usually ARP entries are removed after 5 minutes. However, some conditions can cause arp entries to remain on the list for a longer time. This is not a configurable value. Enter the  get system arp CLI command to view the ARP list.

 

Multiple VDOMs solution

By default, physical interfaces are in the root domain. If you do not configure any of your VLANs in the root VDOM, it will not matter how many interfaces are in the root VDOM.

The multiple VDOMs solution is to configure multiple VDOMs on the FortiGate unit, one for each VLAN. In this solution, you configure one inbound and one outbound VLAN interface in each VDOM. ARP packets are not forwarded between VDOMs. This configuration limits the VLANs in a VDOM and correspondingly reduces the administration needed per VDOM.

As a result of this configuration, the switches do not receive multiple ARP packets with duplicate MACs. Instead, the switches receive ARP packets with different VLAN IDs and different MACs. Your switches are stable.

 

However, you should not use the multiple VDOMs solution under any of the following conditions:

  • You have more VLANs than licensed VDOMs
  • You do not have enough physical interfaces

Instead, use one of two possible solutions, depending on which operation mode you are using:

  • In NAT mode, you can use the vlan forward CLI command.
  • In transparent mode, you can use the forward-domain CLI command. But you still need to be careful in some rare configurations.

 

Vlanforward solution

If you are using NAT mode, the solution is to use the vlanforward CLI command for the interface in question. By default, this command is enabled and will forward VLAN traffic to all VLANs on this interface. When disabled, each VLAN on this physical interface can send traffic only to the same VLAN. There is no cross-talk between VLANs, and ARP packets are forced to take one path along the network which prevents the multiple paths problem.

In the following example, vlanforward is disabled on port1. All VLANs configured on port1 will be separate and will not forward any traffic to each other.

config system interface edit port1

set vlanforward disable

end

 

Layer–2 and Arp traffic

By default, FortiGate units do not pass layer-2 traffic. If there are layer-2 protocols such as IPX, PPTP or L2TP in use on your network, you need to configure your FortiGate unit interfaces to pass these protocols without blocking. Another type of layer-2 traffic is ARP traffic.

You can allow these layer-2 protocols using the CLI command:

config system interface edit <name_str>

set l2forward enable end

where  <name_str> is the name of an interface.

 

If VDOMs are enabled, this command is per VDOM. You must set it for each VDOM that has the problem as following:

config vdom

edit <vdom_name>

config system interface edit <name_str>

set l2forward enable end

end

 

If you enable layer-2 traffic, you may experience a problem if packets are allowed to repeatedly loop through the network. This repeated looping, very similar to a broadcast storm, occurs when you have more than one layer-2 path to a destination. Traffic may overflow and bring your network to a halt. You can break the loop by enabling Spanning Tree Protocol (STP) on your network’s switches and routers. For more information, see “STP forwarding”.

 

ARP traffic

Address Resolution Protocol (ARP) packets are vital to communication on a network, and ARP support is enabled on FortiGate unit interfaces by default. Normally you want ARP packets to pass through the FortiGate unit, especially if it is sitting between a client and a server or between a client and a router.

ARP traffic can cause problems, especially in transparent mode where ARP packets arriving on one interface are sent to all other interfaces including VLAN subinterfaces. Some layer-2 switches become unstable when they detect the same MAC address originating on more than one switch interface or from more than one VLAN. This instability can occur if the layer-2 switch does not maintain separate MAC address tables for each VLAN. Unstable switches may reset and cause network traffic to slow down considerably.

The default ARP timeout value is 5 minutes (300 seconds). So usually ARP entries are removed after 5 minutes. However, some conditions can cause arp entries to remain on the list for a longer time. This is not a configurable value. Enter the  get system arp CLI command to view the ARP list.

 

Multiple VDOMs solution

By default, physical interfaces are in the root domain. If you do not configure any of your VLANs in the root VDOM, it will not matter how many interfaces are in the root VDOM.

The multiple VDOMs solution is to configure multiple VDOMs on the FortiGate unit, one for each VLAN. In this solution, you configure one inbound and one outbound VLAN interface in each VDOM. ARP packets are not

forwarded between VDOMs. This configuration limits the VLANs in a VDOM and correspondingly reduces the administration needed per VDOM.

As a result of this configuration, the switches do not receive multiple ARP packets with duplicate MACs. Instead, the switches receive ARP packets with different VLAN IDs and different MACs. Your switches are stable.

However, you should not use the multiple VDOMs solution under any of the following conditions:

  • You have more VLANs than licensed VDOMs
  • You do not have enough physical interfaces

Instead, use one of two possible solutions, depending on which operation mode you are using:

  • In NAT mode, you can use the vlan forward CLI command.
  • In transparent mode, you can use the forward-domain CLI command. But you still need to be careful in some rare configurations.

 

Vlanforward solution

If you are using NAT mode, the solution is to use the vlanforward CLI command for the interface in question. By default, this command is enabled and will forward VLAN traffic to all VLANs on this interface. When disabled, each VLAN on this physical interface can send traffic only to the same VLAN. There is no cross-talk between VLANs, and ARP packets are forced to take one path along the network which prevents the multiple paths problem.

In the following example, vlanforward is disabled on port1. All VLANs configured on port1 will be separate and will not forward any traffic to each other.

 

config system interface edit port1

set vlanforward disable

end

 

Forward–domain solution

If you are using transparent mode, the solution is to use the forward-domain CLI command. This command tags VLAN traffic as belonging to a particular collision group, and only VLANs tagged as part of that collision group receive that traffic. It is like an additional set of VLANs. By default, all interfaces and VLANs are part of forward-domain collision group 0. The many benefits of this solution include reduced administration, the need for fewer physical interfaces, and the availability of more flexible network solutions.

In the following example, forward-domain collision group 340 includes VLAN 340 traffic on port1 and untagged traffic on port 2. Forward-domain collision group 341 includes VLAN 341 traffic on port 1 and untagged traffic on port 3. All other interfaces are part of forward-domain collision group 0 by default. This configuration separates VLANs 340 and 341 from each other on port 1, and prevents the ARP packet problems from before.

 

Use these CLI commands:

config system interface edit port1

next

edit port2

set forward_domain 340 next

edit port3

set forward_domain 341 next

edit port1-340

set forward_domain 340 set interface port1

set vlanid 340 next

edit port1-341

set forward_domain 341 set interface port1

set vlanid 341

end

 

You may experience connection issues with layer-2 traffic, such as ping, if your network configuration has:

  • Packets going through the FortiGate unit in transparent mode more than once
  • More than one forwarding domain (such as incoming on one forwarding domain and outgoing on another)
  • IPS and AV enabled.

Now IPS and AV is applied the first time packets go through the FortiGate unit, but not on subsequent passes. Only applying IPS and AV to this first pass fixes the network layer-2 related connection issues.

 

NetBIOS

Computers running Microsoft Windows operating systems that are connected through a network rely on a WINS server to resolve host names to IP addresses. The hosts communicate with the WINS server by using the NetBIOS protocol.

To support this type of network, you need to enable the forwarding of NetBIOS requests to a WINS server. The following example will forward NetBIOS requests on the internal interface for the WINS server located at an IP address of 192.168.111.222.

config system interface edit internal

set netbios_forward enable set wins-ip 192.168.111.222

end

These commands apply only in NAT mode. If VDOMs are enabled, these commands are per VDOM. You must set them for each VDOM that has the problem.

 

STP forwarding

The FortiGate unit does not participate in the Spanning Tree Protocol (STP). STP is an IEEE 802.1 protocol that ensures there are no layer-2 loops on the network. Loops are created when there is more than one route for traffic to take and that traffic is broadcast back to the original switch. This loop floods the network with traffic, reducing available bandwidth to nothing.

If you use your FortiGate unit in a network topology that relies on STP for network loop protection, you need to make changes to your FortiGate configuration. Otherwise, STP recognizes your FortiGate unit as a blocked link and forwards the data to another path. By default, your FortiGate unit blocks STP as well as other non-IP protocol traffic.

Using the CLI, you can enable forwarding of STP and other layer-2 protocols through the interface. In this example, layer-2 forwarding is enabled on the external interface:

config system interface

edit external

set l2forward enable set stpforward enable

end

 

By substituting different commands for stpforward enable, you can also allow layer-2 protocols such as IPX, PPTP or L2TP to be used on the network.

 

Too many VLAN interfaces

Any virtual domain can have a maximum of 255 interfaces in transparent mode. This includes VLANs, other virtual interfaces, and physical interfaces. NAT mode supports from 255 to 8192 depending on the FortiGate model. This total number of interfaces includes VLANs, other virtual interfaces, and physical interfaces.

Your FortiGate unit may allow you to configure more interfaces than this. However, if you configure more than 255 interfaces, your system will become unstable and, over time, will not work properly. As all interfaces are used, they will overflow the routing table that stores the interface information, and connections will fail. When you try to add more interfaces, an error message will state that the maximum limit has already been reached.

If you see this error message, chances are you already have too many VLANs on your system and your routing has become unstable. To verify, delete a VLAN and try to add it back. If you have too many, you will not be able to add it back on to the system. In this case, you will need to remove enough interfaces (including VLANs) so that the total number of interfaces drops to 255 or less. After doing this, you should also reboot your FortiGate unit to clean up its memory and buffers, or you will continue to experience unstable behavior.

To configure more than 255 interfaces on your FortiGate unit in transparent mode, you have to configure multiple VDOMs, each with many VLANs. However, if you want to create more than the default 10 VDOMs (or a maximum of 2550 interfaces), you must buy a license for additional VDOMs and your FortiGate must be able to be licensed for more than 10 VDOMs.

With these extra licenses, you can configure up to 500 VDOMs, with each VDOM containing up to 255 VLANs in transparent mode. This is a theoretical maximum of over 127 500 interfaces. However, system resources will quickly get used up before reaching that theoretical maximum. To achieve the maximum number of VDOMs, you need to have top-end hardware with the most resources possible.

In NAT mode, if you have a top-end model, the maximum interfaces per VDOM can be as high as 8192, enough for all the VLANs in your configuration.

Your FortiGate unit has limited resources, such as CPU load and memory, that are divided between all configured VDOMs. When running 250 or more VDOMs, you may need to monitor the system resources to ensure there is enough to support the con- figured traffic processing.