Disable CLI by default in fortigate switch module

[fdurand]

Description

In Fortigate radius request the nasporttype is defined as Virtual and it changes the connection type to CLI-Access. Disabled by default CLI for fortigate switch and also disable it when Connect-Info is equals to web-auth.

Impacts

Fortigate connection type detection

Issue

fixes #7402

Delete branch after merge

YES

Checklist

• [ ] Document the feature
• [ ] Add unit tests
• [ ] Add acceptance tests (TestLink)

NEWS file entries

Bug Fixes

• Captive-Portal with FortiGate does not work #7402

[julsemaan]

The code looks good but it doesn't look retro-compatible for the maintenance. We will get this only in 12.2 and not cherry-pick in maintenance?

[heiko-ma]

I've tested this code in my local environment, unfortunately, it doesn't work like expected. I still encounter the original error mentioned in #7402

Adding a unconditional return $TRUE to isSwitchSupported() in radius.pm does fix the error in the meantime. This needs a little more digging I'm afraid...

[rdamji27]

I have the same issue ... could someone post the code for the radius.pm where the unconditional $TRUE is sent

[heiko-ma]

I have the same issue ... could someone post the code for the radius.pm where the unconditional $TRUE is sent

In radius.pm there is the following method: `sub isSwitchSupported { my ($self, $args) = @; my $logger = $self->logger;

if ($args->{'connection_type'} == $WIRED_MAC_AUTH) {
    return $args->{'switch'}->supportsWiredMacAuth();
} elsif ($args->{'connection_type'} == $WIRED_802_1X) {
    return $args->{'switch'}->supportsWiredDot1x();
} elsif ($args->{'connection_type'} == $WIRELESS_MAC_AUTH) {
    # TODO implement supportsWirelessMacAuth (or supportsWireless)
    $logger->trace("Wireless doesn't have a supports...() call for now, always say it's supported");
    return $TRUE;
} elsif ($args->{'connection_type'} == $WIRELESS_802_1X) {
    # TODO implement supportsWirelessMacAuth (or supportsWireless)
    $logger->trace("Wireless doesn't have a supports...() call for now, always say it's supported");
    return $TRUE;
}

}`

Append a "return $TRUE;" before the last parenthesis and it should work. Note that you are disabling any connection type verification with that.

You also need to change /usr/local/pf/sbin/httpd.aaa-docker-wrapper: Replace the second args variable with this: args="$args -v/usr/local/pf/lib/:/usr/local/pf/lib/ -v/usr/local/pf/conf/:/usr/local/pf/conf/ -/usr/local/pf/var/conf/:/usr/local/pf/var/conf/ -p 100.64.0.1:7070:7070 -p 127.0.0.1:7070:7070"

On another note I think this should get checked again because disabling the connection type check completely is not the way to do this. I'll happily assist with that because I have all the hardware to test the behavior.

[rdamji27]

Thank You Rahim On Friday, April 19, 2024 at 10:23:04 AM EDT, heiko-ma @.***> wrote:

I have the same issue ... could someone post the code for the radius.pm where the unconditional $TRUE is sent

In radius.pm there is the following method: `sub isSwitchSupported { my ($self, $args) = @; my $logger = $self->logger; if ($args->{'connection_type'} == $WIRED_MAC_AUTH) { return $args->{'switch'}->supportsWiredMacAuth(); } elsif ($args->{'connection_type'} == $WIRED_802_1X) { return $args->{'switch'}->supportsWiredDot1x(); } elsif ($args->{'connection_type'} == $WIRELESS_MAC_AUTH) { # TODO implement supportsWirelessMacAuth (or supportsWireless) $logger->trace("Wireless doesn't have a supports...() call for now, always say it's supported"); return $TRUE; } elsif ($args->{'connection_type'} == $WIRELESS_802_1X) { # TODO implement supportsWirelessMacAuth (or supportsWireless) $logger->trace("Wireless doesn't have a supports...() call for now, always say it's supported"); return $TRUE; }

}`

Append a "return $TRUE;" before the last parenthesis and it should work. Note that you are disabling any connection type verification with that.

You also need to change /usr/local/pf/sbin/httpd.aaa-docker-wrapper: Replace the second args variable with this: args="$args -v/usr/local/pf/lib/:/usr/local/pf/lib/ -v/usr/local/pf/conf/:/usr/local/pf/conf/ -/usr/local/pf/var/conf/:/usr/local/pf/var/conf/ -p 100.64.0.1:7070:7070 -p 127.0.0.1:7070:7070"

On another note I think this should get checked again because disabling the connection type check completely is not the way to do this. I'll happily assist with that because I have all the hardware to test the behavior.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[heiko-ma]

After looking at the traced radius packets again and consulting the fortinet documentation I can say that the radius authentication is the MAC-Address as a username and a password. For the mechanism, some kind of CHAP is used. Would it be the right approach to catch the Connect-Info "web-auth" and pretend its a normal MAB Request? Or does it have to be some kind of EAP-Mechanism?

[fdurand]

I have made some changes and with the radius request in #7402 i am able to have a radius answer.

[heiko-ma]

I have made some changes and with the radius request in #7402 i am able to have a radius answer.

Thank you for the fixes, I will try it out in my lab today and report back to you.

Edit: Looks great, we even can process the accounting messages now. Thanks a lot!

[heiko-ma]

I tested this out a little more, Wireless-Authentication works like a charm, but with Wired-Authentication (FortiGate is a captive portal for wired traffic) there are some issues:

• Another clause is needed as the current one requires the "Fortinet-SSID" VSA to be populated:

elsif ( (@require == @found) && $radius_request->{'Connect-Info'} =~ /^(web-auth)$/i) {
        $connection->isVPN($FALSE);
        $connection->isCLI($FALSE);
        $connection->isWebAuth($TRUE);
        $connection->transport("Wired");
}

• With the above clause in place, the authentication works, but when trying to disconnect the client, there is no CoA request sent to the FortiGate. The strange thing is, when i change the last line to "Wireless", it works, so there must be some piece of code which I'm missing.

[fdurand]

I did a change and tried to mimic the radius request (for wire and wireless) , i am able to authenticate/disconnect on both. I also added the Frames-Ip-Address in the disconnect request. Please try and let me know.

[jmrubio2007]

Hi fdurand and all

I was following up this issue because I'm now starting an implementation of packetfence with Fortigates, Fortiswitches and FortiAps and I've been fighting with several issues the last weeks, one of them with this related to CLI-Access Connection-type from Fortigate Captive Portal. My environment is complex (now just a PoC but will be quite large with more than 70 packetfence, 120 Fortigates, and many many FortiAPs and Fortiswitches).

I'm really interested in help you and get your help too with different solutions rleated to Forti ecosystem. One of them this issue related to captive portal configured in a Fortilink VLAN interface with attached FortiAps SSID in bridge mode. In my case the packetfence cannot be in inline enforcement mode and also cannot get the DHCP relaying info to be used as external full captive portal (that is other issue but out of this thread, and I know I cannot get solution for now as incompatible with some NDR appliances that we use).

So, sorry to ask you this simple question but, how could I try the patches you have done for the CLI-Access issue in a simple way in order to check how it works? I cannot wait for 13.2.0 and the patches. I should deploy this solution in the next 30 days in several hospitals, and it is not totally clear for me the way to apply the changes inside the dockers and how to mantain then if not released in next packetfence version.

Also, let me know if I can help you with any tests in a Forti ecosystem. I'm very interested to deepthly exploit the Forti and Packetfence features.

Many thanks. Best regard Jesus

[hst-tutorials]

Hi fdurand and all

I was following up this issue because I'm now starting an implementation of packetfence with Fortigates, Fortiswitches and FortiAps and I've been fighting with several issues the last weeks, one of them with this related to CLI-Access Connection-type from Fortigate Captive Portal. My environment is complex (now just a PoC but will be quite large with more than 70 packetfence, 120 Fortigates, and many many FortiAPs and Fortiswitches).

I'm really interested in help you and get your help too with different solutions rleated to Forti ecosystem. One of them this issue related to captive portal configured in a Fortilink VLAN interface with attached FortiAps SSID in bridge mode. In my case the packetfence cannot be in inline enforcement mode and also cannot get the DHCP relaying info to be used as external full captive portal (that is other issue but out of this thread, and I know I cannot get solution for now as incompatible with some NDR appliances that we use).

So, sorry to ask you this simple question but, how could I try the patches you have done for the CLI-Access issue in a simple way in order to check how it works? I cannot wait for 13.2.0 and the patches. I should deploy this solution in the next 30 days in several hospitals, and it is not totally clear for me the way to apply the changes inside the dockers and how to mantain then if not released in next packetfence version.

Also, let me know if I can help you with any tests in a Forti ecosystem. I'm very interested to deepthly exploit the Forti and Packetfence features.

Many thanks. Best regard Jesus

You can edit the files manually (the ones which where changed are listed in the pull request) and then edit the wrapper file as stated below:

You also need to change /usr/local/pf/sbin/httpd.aaa-docker-wrapper: Replace the second args variable with this: args="$args -v/usr/local/pf/lib/:/usr/local/pf/lib/ -v/usr/local/pf/conf/:/usr/local/pf/conf/ -/usr/local/pf/var/conf/:/usr/local/pf/var/conf/ -p 100.64.0.1:7070:7070 -p 127.0.0.1:7070:7070"

Please note that if you are deploying a cluster you need to change the files on every node and after updating the nodes, the changes will be gone. If you need those files to stay persistent, its best to lock the apt/yum packages to prevent them from updating.

If you need some more insights in regard to FortiGate and Packetfence, you can DM me, I happen to have some expertise on this subject.

[jmrubio2007]

I did a change and tried to mimic the radius request (for wire and wireless) , i am able to authenticate/disconnect on both. I also added the Frames-Ip-Address in the disconnect request. Please try and let me know.

Hi fdurand. Last change for 'Framed-IP-Address' => $ipAddress doesn't work as $ipAddress is not declared before in the sub deauthenticateMacDefault, branch 9ec0c29

Apr 23 08:35:47 srvpacketfp1 httpd.aaa-docker-wrapper[4244]: httpd.aaa(7) WARN: [mac:[undef]] Couldn't require pf::Switch::Fortinet::FortiGate : Global symbol "$ipAddress" requires explicit package name (did you forget to declare "my $ipAddress"?) at /usr/local/pf/lib/pf/Switch/Fortinet/FortiGate.pm line 210.

Thx

[fdurand]

My bad, it should be ok now.

[satkunas]

@jmrubio2007 @heiko-ma we're looking to merge this ASAP, please provide feedback so we can decide to go/no-go for v13.2. Thanks!

[heiko-ma]

The authentication looks good so far, i've only been able to test this on a packetfence 12.1 (its the one we use in production) though. The only thing that doesnt work is the deauthentication because it gets the values for the username from the acct-session-id and my fortigate does not seem to send accounting messages for guest wifi. I'm going to replicate this in my lab and get back to you. But as far as I can see the code should be correct and can be merged.

Edit: Accounting does indeed work on 13.1 (FortiGate-Config is the same) but not on 12.1. This is strange because normal 802.1x Wifi-Authentication gets accounted just fine.