cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

1554
Views
6
Helpful
9
Replies
Highlighted
Beginner

f5 ise coa issue

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

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

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

View solution in original post

9 REPLIES 9
Highlighted
VIP Advocate

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

Highlighted

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

}

Highlighted

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

View solution in original post

Highlighted

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.

Highlighted

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.

Highlighted

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

Highlighted

@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? 

Highlighted

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 :(

 

Highlighted

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.