f5 ise coa issue

[eni-co24192]

I am trying to setup a f5 configuration for ise services following the guide : "How To: Cisco & F5 Deployment Guide: ISE Load Balancing Using BIG-IP"

I am actually facing an issue with Coa. I configured an outbound snat vip on udp port 1700 as suggested in your guide.

When One of PSN mode sends coa request, this is snatted correctly with vip address from the f5. The wlc, in my case, responds with a coa reply but f5, instead of forwarding the reply to PSN node, sends back and ICMP PORT UNREACHABLE to the wlc. So on ise logs the coa is marked As failed.

Have you any suggestions about how ti solve the issue?

Thank you in Advance for the support.

Simone

[paul]

Can you post a screen shot of your CoA SNAT VIP?

[eni-co24192]

Hi Paul,

here the config :

ltm snatpool /Common/ise_radius_coa_wifi_snatpool {

members {

/Common/10.103.195.206

}

}

ltm virtual /Common/ise_radius_coa_wifi {

destination /Common/0.0.0.0:1700

ip-protocol udp

mask any

profiles {

/Common/udp { }

}

source 10.102.179.248/29

source-address-translation {

pool /Common/ise_radius_coa_wifi_snatpool

type snat

}

translate-address disabled

translate-port enabled

vlans {

/Common/Ise_PSN_2653

}

vlans-enabled

}

[Craig Hyps · Accepted solution]

Check the source IP in the WLC's CoA response.  Make sure it is the same as target IP in CoA request coming from PSN.  There are settings in WLC to set the RADIUS interface which can override default interfaces--somewhat akin to the source-interface option in wired switches.  If the response is not the same as that in target CoA request, then LTM will not see reply as part of existing flow.  A similar message will be triggered by WLC when Direct Server Return is attempted on LB whereby the RADIUS reply comes from a different IP (real RADIUS server IP) rather than VIP.

/Craig

[eni-co24192]

Below the dump wlc side :

10.103.195.206 VIP F5

10.129.127.254 WLC

Below the ISE SIDE

As you see not default interface overide nor the Direct Server Return occurs.

[Arne Bier]

Hi Simone.   Did you resolve this issue?  I ran into the same thing today.

I can see from the F5 tcpdump that the CoA is coming from the WLC IP address (correct), but the F5 just ignores it.  It's just the CoA-ACK that doesn't make it back to the PSN.

Your previous posting mentions some dump - but I don't see it in your posting.

[Craig Hyps]

Verify that the source/dest IP that exists F5 is same as those in return packet (in reverse order, of course).  Also verify that the session timer is > 0 and long enough to account for delays in CoA Ack response.  Although UDP is not flow-based, the LTM tracks session flows and will drop packet if it does not see the response as part of a valid outbound connection from PSN in time allotted.

/Craig

[Rahul Govindan]

@Arne Bier Did you ever figure this out? I am running into the same thing in 2019 with all the latest ISE, F5 and WLC versions. Wondering if you ever got an answer to this? 

[Arne Bier]

Hi Rahul

honest answer ... this was a while back and I cannot remember what happened in the end. I have moved off of that project and it was resolved - I just cannot remember what the fix was.

Perhaps it was related to an iRule that was not scripted correctly. I think the COA-ACK looked like new traffic to the Virtual Server, and it didn't know what to do with it (the iRule was perhaps not expecting UDP/1700 ). It was beyond my understanding of the F5. 

Sorry :(

[Rahul Govindan]

Thanks @Arne Bier . I was discussing this with @Damien Miller just today and his lab setup settings seem to work correctly. I'll try to match what he has and post an update on what I find.