RSSO Agent working for one interface, but not another

[andimorris]

I'm having a bit of trouble getting RSSO to work for all of my wireless users.

I have it working for one interface on a single firewall with no issues.

Another firewall, I have it working on one network interface, but I can't get it to work from another, despite it using the same RSSO Agent.

I can see the radius accounting packets leaving the WLC, to my NAC appliance, where it's forwarded to the Fortigate. The error on the NAC is:

ERROR: [mac:78:9f:70:2d:c2:c9] Timeout waiting for a reply from 172.16.64.1 on port 1813

Doing some packet sniffing on the fortigate I can see the traffic arriving on port 1813, but given the message above, it's not processing it, and therefore not sending a reply.

Digging further into the packet sniffing I have the following:

This is a capture from a network interface that ISN'T working with RSSO

2016-11-24 15:34:52.355514 port18 in 192.168.101.73.52958 -> 172.16.64.1.1813: udp 110 0x0000 0000 0000 0001 0008 e3ff fd90 0800 4500 ..............E. 0x0010 008a 4977 4000 3f11 dfe8 c0a8 6549 ac10 ..Iw@.?.....eI.. 0x0020 4001 cede 0715 0076 03ac 04a1 006e 17c1 @......v.....n.. 0x0030 8b19 0d85 b035 ff64 2a2d a1b7 c895 0118 .....5.d*-...... 0x0040 3134 3035 3733 3236 4062 726f 6f6b 6573 14057326@brookes 0x0050 2e61 632e 756b 2806 0000 0001 0806 ac10 .ac.uk(......... 0x0060 400b 1910 7669 7369 7469 6e67 5f75 7365 @...visiting_use 0x0070 7273 1f13 6330 3a31 613a 6461 3a32 323a rs..c0:1a:da:22: 0x0080 3366 3a39 641e 1330 303a 3131 3a32 323a 3f:9d..00:11:22: 0x0090 3333 3a34 343a 3535 33:44:55

This is a capture from the same firewall, but IS working with RSSO (note the different CLASS id)

2016-11-24 15:43:34.434467 port33 in 192.168.101.17.59485 -> 172.18.16.1.1813: udp 143 0x0000 0000 0000 0001 0008 e3ff fd90 0800 4500 ..............E. 0x0010 00ab e92b 4000 3f11 7049 c0a8 6511 ac12 ...+@.?.pI..e... 0x0020 1001 e85d 0715 0097 d222 04b3 008f 0985 ...]....."...... 0x0030 7f45 cf3e 1b26 8d54 e85c cbbe a744 0117 .E.>.&.T.\...D.. 0x0040 616e 6469 2e6d 6f72 7269 7340 676d 6169 andi.morris@gmai 0x0050 6c2e 636f 6d2c 1b61 6363 745f 7066 2d33 l.com,.acct_pf-3 0x0060 303a 3130 3a62 333a 3133 3a62 653a 3337 0:10:b3:13:be:37 0x0070 2806 0000 0002 0806 ac12 1010 1917 4e6f (.............No 0x0080 6e2d 6564 7563 6174 696f 6e61 6c5f 4775 n-educational_Gu 0x0090 6573 741f 1333 303a 3130 3a62 333a 3133 est..30:10:b3:13 0x00a0 3a62 653a 3337 1e13 3030 3a31 313a 3232 :be:37..00:11:22 0x00b0 3a33 333a 3434 3a35 35 :33:44:55

This is a capture from the other firewall, which is working with RSSO:

2016-11-24 15:39:32.819422 port17 in 192.168.36.116.35675 -> 10.1.254.151.1813: udp 111 0x0000 0000 0000 0001 000e d693 6d4a 0800 4500 ..........mJ..E. 0x0010 008b 0844 4000 3e11 4669 c0a8 2474 0a01 ...D@.>.Fi..$t.. 0x0020 fe97 8b5b 0715 0077 197c 0477 006f 92c3 ...[...w.|.w.o.. 0x0030 9cad a512 8b97 7f59 0a15 d9f9 cc95 011d .......Y........ 0x0040 7374 3230 3037 3739 3236 4063 6172 6469 st20077926@cardi 0x0050 6666 6d65 742e 6163 2e75 6b28 0600 0000 ffmet.ac.uk(.... 0x0060 0108 060a 0681 ba19 0c68 6f6d 655f 7573 .........home_us 0x0070 6572 731f 1361 633a 3239 3a33 613a 3336 ers..ac:29:3a:36 0x0080 3a38 363a 6532 1e13 3030 3a31 313a 3232 :86:e2..00:11:22 0x0090 3a33 333a 3434 3a35 35 :33:44:55

The only thing I can see that could be an issue is that the one that isn't working seems to have a spurious @ before the class is declared. If that is the issue, I've no idea where it's coming from. The user group config is as follows:

(visiting_users) # get name : visiting_users group-type : rsso authtimeout : 0 sso-attribute-value : visiting_users

Anyone have any ideas? It's driving me crazy.

For reference I'm running 1200D on version 5.2.7

[andimorris]

Those packet captures haven't displayed particularly well, I'll try to amend with better formatting tomorrow.

EDIT: The bad display was on my phone. Seems ok on the PC so will leave the original post as is.

[xsilver_FTNT]

Hi

I'm a bit lost in who-is-who.

Who is RADIUS and who are clients.

Network diagram would be fine. Basically said reply to RADIUS Accounting packet is not mandatory. FortiGate can be set to do reply.

If sniffer seems incomplete, attach sniffer as text or pcap next time.

"I have it working on one network interface, but I can't get it to work from another" .. config interface  and allowaccess radius-acct missing ?

Regarding the Class and "@" .. I'm not sure.

First, keep in mind that whole RSSO is a full string comparison between content in sso-attribute AVP from received Accounting packet and rsso-type group sso-attribute-value string. If those two match then user rsso-endpoint-attribute is considered a member of that group.

Second, mentioned @ seems to be transcript of hex data (40) which in place like "0x0060 400b 1910 7669 7369 7469 6e67 5f75 7365 @...visiting_use" seems to be second last octet of Framed-IP-Address 172.16.64.11 .. in this case x40 = d64 = @ (see Alt.codes table for example). For details check packet bytes in Wireshark or see my first packet transcript attached.

Best regards,

Tomas