louis.scaringella

Aruba Clearpass and Juniper Switch Integration for 802.1X Authentication and Access List Mapping

This article from Juniper does a fantastic job of explaining Clearpass and Juniper Switch integration so I won’t recreate the wheel here, but I wanted to share one caveat that I experienced with this:

https://www.juniper.net/documentation/en_US/release-independent/nce/information-products/pathway-pages/nce/nce-157-aruba-dot1x-mac-configuring.pdf

Here is an example of the Juniper switch filters or Access Control Lists. Notice that the “IT-Admin” name is just the role that Clearpass sends over to the switch once Clearpass completes the role mapping process for a user authentication.

set firewall family ethernet-switching filter IT-Admin term Block_Internal_Server from destination-address 198.18.255.75/32

set firewall family ethernet-switching filter IT-Admin term Block_Internal_Server then discard

set firewall family ethernet-switching filter IT-Admin term Allow_All then accept

set firewall family ethernet-switching filter SonyLaptop term Block_Internal_Server from destination-address 8.8.4.4/32

set firewall family ethernet-switching filter SonyLaptop term Block_Internal_Server then discard

set firewall family ethernet-switching filter SonyLaptop term Allow_All then accept

The only issue I saw was when testing this was when I had created my service, role mappings, etc in Clearpass with a new role, but had not yet created this matching filter/ACL on the Juniper switch side. So, what would happen is Clearpass would show the user authentication and the correct role mapped, but the user wouldn’t have access. I wrongly assumed that the Juniper would assign a default role so that essentially no filter/ACL would match and the user would simply be allowed full access, but that was not the case. Without a specific filter/ACL for that role sent from Clearpass, the user will not have access.

Use Palo Alto Networks Remote Access VPN on Mobile Devices Without Global Protect License or App

It is possible to use the remote access VPN capabilities of a Palo Alto firewall without having a Global Protect license or Global Protect agent (app) on your mobile device. I do want to mention that you get additional capabilities by having the Global Protect license and app such as TAC support, detailed information about the endpoint connecting to the VPN, split tunneling, NAC-type functionality by profiling and enforcing compliance profiles, and more.

This is helpful if you have just a handful of mobile devices where you want the ability to have remote access VPN.

Here is what the configuration looks like to enable this. First you must enable IPSec along with X-Auth support under the Gateway Client Configuration. You set the Group Name and Password and configure the rest of GlobalProtect like you normally would.

On the iOS or Mobile VPN client settings, create a new VPN configuration and use the IPsec/Cisco tab to configure the necessary settings. IPsec and X-Auth must be enabled. The group password field in the Palo Alto is the equivalent of the “secret” field on the iOS VPN client configuration.

This will also work with the native VPN agent on macOS.

Initial Setup Script for FortiAnalyzer/FortiManager

The FortiAnalyzer and FortiManager Admin Guides provides great information, but one thing i’ve found it lacking is a concise, quick method of giving a VM a new management IP address through the console so you can manage it through the GUI.

Admin Guide: https://docs.fortinet.com/document/fortianalyzer/6.2.0/administration-guide/

Here is a quick script you can use for the initial setup after the VM is deployed to get a new management IP setup, default route set, and management protocols enabled:

config system interface
edit port1
set ip 10.10.10.10 255.255.255.0
set allowaccess https ssh
end
config system route
edit 1
set dst 0.0.0.0 0.0.0.0
set device port1
set gateway 10.10.10.1
end

Now you should be able to access FortiAnalyzer or Manager using the GUI with https://10.10.10.10

Cisco vPC Setup and Caveats

This was my first time setting up Cisco vPC between two Nexus 3K switches and I wanted to document some findings the deviated from their documentation a bit.

NXOS: version 7.0(3)I7(6) was used in this environment.

Here is the topology:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/layer2/503_U2_1/b_Cisco_n3k_layer2_config_guide_503_U2_1/b_Cisco_n3k_layer2_config_gd_503_U2_1_chapter_01000.html#concept_692519898AC94234AAE63D401054816A

The above link does a great job explaining the requirements for vPC and what is involved including using LACP. The only real caveat is when creating the Etherchannel for the vPC peer or downstream port-channels I had to follow this order specifically or it would say that the ports were not compatible when I tried to add them to a port-channel using the channel group command. Cisco’s documentation for Etherchannel suggests adding the port-channel interface first then adding the individual ports to the port-channel.

First add the ports to the port-channel then create the port-channel interface:

conf t
int e 1/49
switchport mode trunk
channel-group 100 mode active

int e 1/50
switchport mode trunk
channel-group 100 mode active

exit

int port-channel 100
switchport mode trunk

Here is a full snippet relevant to the vPC config:

Nexus A:

vrf context management
   ip route 0.0.0.0/0 10.10.10.1
 
 vpc domain 1
   peer-keepalive destination 10.10.10.20 source 10.10.10.10
   auto-recovery

 interface port-channel1
   switchport mode trunk
   vpc 1

 interface port-channel100
   switchport mode trunk
   spanning-tree port type network
   vpc peer-link

 interface Ethernet1/48
   switchport mode trunk
   channel-group 1 mode active

 interface Ethernet1/49
   switchport mode trunk
   channel-group 100 mode active

 interface Ethernet1/50
   switchport mode trunk
   channel-group 100 mode active

 interface mgmt0
   vrf member management
   ip address 10.10.10.10/24
 line console

Nexus B:

vrf context management
   ip route 0.0.0.0/0 10.10.10.1
 
 vpc domain 1
   peer-keepalive destination 10.10.10.10 source 10.10.10.20
   auto-recovery

 interface port-channel1
   switchport mode trunk
   vpc 1

 interface port-channel100
   switchport mode trunk
   spanning-tree port type network
   vpc peer-link

 interface Ethernet1/48
   switchport mode trunk
   channel-group 1 mode active

 interface Ethernet1/49
   switchport mode trunk
   channel-group 100 mode active

 interface Ethernet1/50
   switchport mode trunk
   channel-group 100 mode active

 interface mgmt0
   vrf member management
   ip address 10.10.10.20/24
 line console

Nexus C:

vrf context management
   ip route 0.0.0.0/0 10.10.10.1

 interface port-channel1
   switchport mode trunk

 interface Ethernet1/49
   switchport mode trunk
   channel-group 1 mode active

 interface Ethernet1/50
   switchport mode trunk
   channel-group 1 mode active

 interface mgmt0
   vrf member management
   ip address 10.10.10.30/24
 line console

Use OpenSSL to Convert a PEM Certificate File and a Private Key to PKCS#12 (.pfx .p12) Format

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

* Note: In this case, the certificate file after “-in” is the actual server certificate and the cert file after “-certfile” is the bundled file that you would get from a CA.

* If this is a self-signed cert, leave out the “-certfile” section since there will not be an intermediary or root CA.

Connect To Individual Stack Node with ExtremeXOS Switches

When you have a stack of ExtremeXOS switches, you manage the entire stack with a single IP address, but to connect to an individual node in the stack you can use the following:

“telnet slot [2,3,4,etc]”

Fortigate VIP Configured and Deny Policy Not Functioning

In a situation where you have a VIP configured to perform Destination NAT for traffic incoming from the Internet to an internal server, and you have a policy “above” the allow policy to the VIP in precedence, you will notice that by default the “above” policy isn’t functioning as expected when traffic is destined to the VIP.

This is extremely frustrating and isn’t how any other firewall i’ve worked on functions, but what happens is that the VIP translation is hit earlier on in the packet processing on the Fortigate so the policy that references the VIP gets used even if it is farther down in precedence than say a geo-filtering policy blocking all incoming traffic (allegedly to all hosts) from China.

That means that even though you think you have policies denying traffic above your VIP rules that it won’t matter. This is very concerning and probably needs to be addressed by Fortinet. Unless you really investigate logs to confirm that the deny rule above your VIP rule is getting used, this may go missed for a while.

The below link from Fortinet describes the problem in more detail and discusses possible solutions.

https://kb.fortinet.com/kb/documentLink.do?externalID=FD36750

The key is that you can add the “set match-vip enable” line to the “above” policy config to make sure that even if a VIP is a destination, that this deny rule gets used instead of the permit rules that the VIP is associated with. Alternatively, you can use the VIP in the “above” deny rule explicitly as the destination.

 config firewall policy 
 edit 36 
 set match-vip enable

Fortigate LDAP Authentication or FSSO Over VPN

When trying to setup a FSSO fabric connector for Active Directory polling or when using LDAP for authentication with Forticlient or firewall administration, and when the AD controller is across a site to site VPN, the fabric connector and LDAP profile will attempt to use the public IP of the firewall for the source IP.

If you only need to send LDAP authentication requests across a VPN, you can simple set the source-IP option when configuring the LDAP profile in the CLI.

In this case, the source IP of 10.255.255.1 resides on the internal interface of the firewall itself and will source all requests to the DC at 10.10.10.100 using 10.255.255.1. You must ensure that 10.255.255.1 is allowed across the VPN and permitted by policy on the other side.

Here is the snippet of the config to use for the LDAP Profile:

config user ldap
    edit "AD Profile"
        set server "10.10.10.100"
        set source-ip 10.255.255.1
        set cnid "sAMAccountName"
        set dn "dc=test,dc=com"
        set type regular
        set username "cn=Administrator,cn=Users,dc=test,dc=com"
    next
end

If you are using FSSO across a VPN, there is an addition consideration that is explained well in the below document. Using the source-IP in the LDAP profile isn’t sufficient and isn’t taken into consideration.

Basically, when using a FSSO Fabric Connector, you must configure an IP address on the tunnel interfaces themselves which forces the Fabric Connector to use that IP address to source the Fabric Connector requests. There isn’t an option to source the Fabric Connector traffic from a specific IP address in the GUI or CLI like you can with the LDAP profile.

Link to Fortinet reference: https://kb.fortinet.com/kb/documentLink.do?externalID=FD41468

Fortigate and SIP Troubles – Disable ALG

The SIP Application Layer Gateway (ALG) is enabled by default on Fortigate firewalls. I have seen a number of phone systems have troubles with phones registering when this is enabled so the following steps can be used to disable the ALG. This is typically for hosted cloud-based phone systems where the phones have to register to a server hosted by a service provider and must traverse the firewall and NAT.

Backup the configuration before making these changes.

Run following commands from Fortigate firewall CLI:

config system settings 
set sip-helper disable 
set sip-nat-trace disable 
set default-voip-alg-mode kernel-helper-based 
end

Next, we need to locate SIP entry in session helper list and delete it

config system session-helper
show

Scroll down until you see an entry for SIP. In most cases I have seen this listed as 13.

delete 13 
end

Here is the original configuration for this block if you have to restore it:

edit 13 set name sip set protocol 17 set port 5060

Finally, we disable the RTP protocol processing on the firewall:

config voip profile 
edit default 
config sip 
set rtp disable 
end 
end

A reboot was required to make this all go into affect. Without the reboot, tests showed the ALG disabled, but calls were not working and phones did not register. This was a Fortigate running 6.0.4. Other times with 6.0.5 I have noticed that the rebooted was not required.