ISE witt F5 CoA SNAT configuration problem

[sekregie]

My customer is having problem to configure CoA SNAT when deploying F5 for load balancing. Without CoA SNAT option it can work fine, before they were using ISE for very long time without F5, now they are trying to reconfigure their solution. They tried to use deployment guide in attachment from 2014 but seems that part of configuration needed o F5 is not complete (at least according to F5 support). Can you advise where I can find configuration guide which can help my customer to deploy ISE with F5 CoA SNAT? 

[Arne Bier]

There are some snippets of best practice in the BRKSEC-3699

I doubt Cisco will have a recipe that can be applied to all customers - in some cases you made need iRules and that's when your mileage may vary.  I have seen very complex iRules and it's a topic that deserves special skill sets.  Cisco documentation goes a long way to explain the requirements and theory - but the actual customer implementation could be tricky.  You might want to share more details about your topology and F5 config so far.  The community can glance over it.  Craig Hyps has done a lot of work in that area and might be lurking here.  You never know ... I tried to add him into the conversation with @... but it didn't work for me.  It used to work on the old ISE Community Forum.

[Alex Pfeil]

It looks to me like the information you need is in the guide. I would make sure that they are not getting F5 SNAT address and source NAT confused.

Thanks,

Alex

[sekregie]

Thanks, I have already provided this guide to customer. They will check and feedback to me.

[Craig Hyps]

On the landing page of the guide, there is a healthy discussion and comments from field and customers on some items from guide which may or may not work as originally documented based on F5 LTM version or special deployment setup. The CoA SNAT config was complete as per the versions and environment tested at the time, but in later releases customers found that they needed to change the virtual server type from 'Standard' to 'Forwarding (IP)'.

[rajczmic]

Hi Craig;

I just did a quick test after switching from Standard type to Forwarding type. Unfortunately, no changes :-(

Regards

[rajczmic]

Hello;

I am a client mentioned by the Sebastian (sekregie).The problem concerns communication for radius CoA initiated by one of the PSNs. Communication enters the F5 from the PSN side and I do not know what's happening with it. I can only see that there is no assignment to any of the Virtual Servers. The topology in the lab is very simple: NAD (switch)> F5> PSN1 / PSN2

I will mention that my knowledge of F5 is not high, I rely entirely on a document written by Craig Hyps.

My addressing table:

10.16.36.211 & 212 - PSN1/2 adddress

 10.16.36.210 -ISE_INTERNAL interface

10.16.36.186 - ISE_EXTERNAL interface

10.16.36.187 - VIP F5

10.31.69.90 - NAD IP Address

　

A fragment of the CoA communication log that appears on F5 from the PSN side (ISE_INTERNAL):

[rajczmic@localhost:Active:Disconnected] ~ # tcpdump -i any port 1700

listening on any, link-type EN10MB (Ethernet), capture size 65535 bytes

12:38:03.477327 IP 10.16.36.212.44370 > 10.31.69.90.mps-raft: RADIUS, CoA-Request (43), id: 0x03 length: 180 in slot1/tmm0 lis=

12:38:08.480682 IP 10.16.36.212.44370 > 10.31.69.90.mps-raft: RADIUS, CoA-Request (43), id: 0x03 length: 180 in slot1/tmm0 lis=

　

　

Normal Radius communication looks looks like below. I do not know why, but it is not always assigned to Virtual servers for Radius:

ON ISE_INTERNAL side :

rajczmic@localhost:Active:Disconnected] ~ # tcpdump -i ISE_INTERNAL port 1812
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ISE_INTERNAL, link-type EN10MB (Ethernet), capture size 65535 bytes
13:42:11.764129 IP 10.16.36.210.58949 > 10.16.36.212.radius: RADIUS, Access-Request (1), id: 0x93 length: 65 out slot1/tmm1 lis=
13:42:11.782857 IP 10.16.36.212.radius > 10.16.36.210.58949: RADIUS, Access-Accept (2), id: 0x93 length: 184 in slot1/tmm1 lis=
13:42:16.358655 IP 10.31.69.90.datametrics > 10.16.36.212.radius: RADIUS, Access-Request (1), id: 0x7c length: 107 out slot1/tmm1 lis=/Common/PSN-IP-Forwarding-Inbound
13:42:16.375898 IP 10.16.36.212.radius > 10.31.69.90.datametrics: RADIUS, Access-Accept (2), id: 0x7c length: 187 in slot1/tmm1 lis=/Common/PSN-IP-Forwarding-Inbound
13:42:19.295035 IP 10.16.36.210.35142 > 10.16.36.211.radius: RADIUS, Access-Request (1), id: 0x9b length: 65 out slot1/tmm0 lis=
13:42:19.320966 IP 10.16.36.211.radius > 10.16.36.210.35142: RADIUS, Access-Accept (2), id: 0x9b length: 184 in slot1/tmm0 lis=
13:42:26.722811 IP 10.31.69.90.datametrics > 10.16.36.211.radius: RADIUS, Access-Request (1), id: 0x7e length: 107 out slot1/tmm1 lis=/Common/PSN-IP-Forwarding-Inbound
13:42:26.726770 IP 10.16.36.210.57065 > 10.16.36.212.radius: RADIUS, Access-Request (1), id: 0xa2 length: 65 out slot1/tmm1 lis=
13:42:26.744838 IP 10.16.36.212.radius > 10.16.36.210.57065: RADIUS, Access-Accept (2), id: 0xa2 length: 184 in slot1/tmm1 lis=
13:42:26.754586 IP 10.16.36.211.radius > 10.31.69.90.datametrics: RADIUS, Access-Accept (2), id: 0x7e length: 187 in slot1/tmm1 lis=/Common/PSN-IP-Forwarding-Inbound
13:42:32.054175 IP 10.31.69.90.swismgr1 > 10.16.36.212.radius: RADIUS, Access-Request (1), id: 0x7f length: 261 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:42:32.187424 IP 10.16.36.212.radius > 10.31.69.90.swismgr1: RADIUS, Access-Challenge (11), id: 0x7f length: 149 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:42:32.216883 IP 10.31.69.90.swismgr1 > 10.16.36.212.radius: RADIUS, Access-Request (1), id: 0x80 length: 631 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:42:32.245599 IP 10.16.36.212.radius > 10.31.69.90.swismgr1: RADIUS, Access-Challenge (11), id: 0x80 length: 277 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:42:32.265723 IP 10.31.69.90.swismgr1 > 10.16.36.212.radius: RADIUS, Access-Request (1), id: 0x81 length: 818 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:42:32.284533 IP 10.16.36.212.radius > 10.31.69.90.swismgr1: RADIUS, Access-Challenge (11), id: 0x81 length: 182 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:42:32.315764 IP 10.31.69.90.swismgr1 > 10.16.36.212.radius: RADIUS, Access-Request (1), id: 0x82 length: 437 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:42:32.318861 IP 10.16.36.212.radius > 10.31.69.90.swismgr1: RADIUS, Access-Challenge (11), id: 0x82 length: 198 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:42:32.349578 IP 10.31.69.90.swismgr1 > 10.16.36.212.radius: RADIUS, Access-Request (1), id: 0x83 length: 485 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:42:34.289417 IP 10.16.36.210.44778 > 10.16.36.211.radius: RADIUS, Access-Request (1), id: 0xaa length: 65 out slot1/tmm0 lis=
13:42:34.306242 IP 10.16.36.211.radius > 10.16.36.210.44778: RADIUS, Access-Accept (2), id: 0xaa length: 184 in slot1/tmm0 lis=

　

ON ISE_EXTERNAL side:

rajczmic@localhost:Active:Disconnected] ~ # tcpdump -i ISE_EXTERNAL port 1812
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ISE_EXTERNAL, link-type EN10MB (Ethernet), capture size 65535 bytes
13:46:06.692039 IP 10.31.69.90.datametrics > 10.16.36.212.radius: RADIUS, Access-Request (1), id: 0xae length: 107 in slot1/tmm1 lis=/Common/PSN-IP-Forwarding-Inbound
13:46:06.708915 IP 10.16.36.212.radius > 10.31.69.90.datametrics: RADIUS, Access-Accept (2), id: 0xae length: 187 out slot1/tmm1 lis=/Common/PSN-IP-Forwarding-Inbound
13:46:12.470534 IP 10.31.69.90.datametrics > 10.16.36.187.radius: RADIUS, Access-Request (1), id: 0xaf length: 261 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:12.478698 IP 10.16.36.187.radius > 10.31.69.90.datametrics: RADIUS, Access-Challenge (11), id: 0xaf length: 149 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:12.499967 IP 10.31.69.90.datametrics > 10.16.36.187.radius: RADIUS, Access-Request (1), id: 0xb0 length: 631 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:12.504167 IP 10.16.36.187.radius > 10.31.69.90.datametrics: RADIUS, Access-Challenge (11), id: 0xb0 length: 277 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:12.523369 IP 10.31.69.90.datametrics > 10.16.36.187.radius: RADIUS, Access-Request (1), id: 0xb1 length: 818 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:12.543380 IP 10.16.36.187.radius > 10.31.69.90.datametrics: RADIUS, Access-Challenge (11), id: 0xb1 length: 182 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:12.565159 IP 10.31.69.90.datametrics > 10.16.36.187.radius: RADIUS, Access-Request (1), id: 0xb2 length: 437 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:12.971219 IP 10.16.36.187.radius > 10.31.69.90.datametrics: RADIUS, Access-Challenge (11), id: 0xb2 length: 182 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:12.995314 IP 10.31.69.90.datametrics > 10.16.36.187.radius: RADIUS, Access-Request (1), id: 0xb3 length: 437 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:12.997937 IP 10.16.36.187.radius > 10.31.69.90.datametrics: RADIUS, Access-Challenge (11), id: 0xb3 length: 182 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:13.006733 IP 10.31.69.90.datametrics > 10.16.36.187.radius: RADIUS, Access-Request (1), id: 0xb4 length: 405 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:13.844545 IP 10.16.36.187.radius > 10.31.69.90.datametrics: RADIUS, Access-Challenge (11), id: 0xb4 length: 166 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:13.854983 IP 10.31.69.90.datametrics > 10.16.36.187.radius: RADIUS, Access-Request (1), id: 0xb5 length: 405 in slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH
13:46:13.859229 IP 10.16.36.187.radius > 10.31.69.90.datametrics: RADIUS, Access-Accept (2), id: 0xb5 length: 348 out slot1/tmm1 lis=/Common/ISE-RADIUS-AUTH

　

　

Configuration of individual Virtual Servers in the attachment

[Craig Hyps]

To be clear, the only change would be to the CoA SNAT config, not the RADIUS Auth and Accounting portion.  The RADIUS request from NAD to VIP should use Standard LB config.  Source NAT is not supported in this flow as detailed in guide and in BRKSEC-3699 (latest reference deck posted to ciscolive.com for Orlando 2018).  RADIUS auth and accounting work but CoA will fail since ISE sends CoA to LB IP address, not NAD IP address.  There is an outstanding enhancement for ISE to use NAS-IP-Address in RADIUS payload for CoA instead of the source address learned in IP header.

Recommendation to set VS to Forwarding(IP) is only for the CoA traffic initiated by PSN.  Check traffic on both sides of LTM and verify packets are being forwarded with only change being the source IP (from PSN IP to VIP IP).   The NADs must have CoA trust set for the LB VIP address (dynamic authorization config).  Also try setting "translate-address disabled" in CoA SNAT config.

[rajczmic]

I use SNAT only for COA initiated by PSN. On the INTERNAL side, I see this communication (according to the logs attached above). Unfortunately, this communication does not reach NAD - you can not see it at all on the EXTERNAL interface

[gbekmezi-DD]

Have you created this virtual server?

[rajczmic]

Yes, of course

ltm virtual ISE-RADIUS-COA-SNAT {

    destination 0.0.0.0:mps-raft

    ip-protocol udp

    mask any

    profiles {

        udp { }

    }

    source 10.16.36.208/28

    source-address-translation {

        pool Radius_COA_SnatPool

        type snat

    }

    translate-address enabled

    translate-port enabled

   vlans {

        ISE_INTERNAL

    }

    vlans-enabled

    vs-index 17

[Craig Hyps]

Again, try setting "translate-address disabled" in CoA SNAT config.

[gbekmezi-DD]

You might have better success on an F5 forum. If you do, please let us know what the solution was :-). These configurations are fairly straightforward and common, maybe you are hitting a defect?

[rajczmic]

"translate-address disabled" does not help. Now  we are testing  with another iRule. I'll let You know